Skip to content

Glossary ​

Each word here has one meaning, the same in these docs, in yg prime, in yg knowledge, in the CLI output and in the portal. Where an older word meant the same thing, it is listed as not used, so you can map it when you meet it in an old note.

The graph ​

node (component) ​

A component of your system as the graph records it: a directory under .yggdrasil/model/ whose mapping lists the files it owns. Prose says component; the CLI says node.

More: Nodes.

mapping ​

The list of paths a node owns. A file in some node’s mapping is node-owned.

More: Nodes.

architecture type ​

A kind of node declared in yg-architecture.yaml. A type with a when: predicate is a classifying type: it can claim files by path or content.

More: Nodes.

relation ​

A declared dependency between two nodes (calls / uses / …). Every real code dependency must be declared; a declared relation needs no code behind it.

More: Relations, Flows & Ports.

flow ​

A business process that spans several nodes — “place an order”. A rule attached to a flow reaches every node in it.

More: Relations, Flows & Ports.

port (graph element) ​

A named entry to a node, declared under ports: with the rules it carries; a relation that names it in portNames: enters through it and takes those rules on. Every node also has the implicit default port. yg structure says a dependency goes through a named port when a relation between the two names one other than default.

More: Relations, Flows & Ports.

Rules ​

aspect (rule) ​

A rule the code must satisfy — e.g. “UI must not import the database”. Prose says rule; the graph and the CLI say aspect.

More: Aspects.

rule kind ​

How a rule is checked. There are three kinds: a reviewer rule, a script rule and a bundle. The files in the rule’s directory decide the kind; no field sets it.

Not called: reviewer kind. More: Aspects.

reviewer rule ​

A rule written as prose (content.md) that the reviewer reads and judges the code against — judgment, and it may cost.

Machine token: llm — reviewer.type in yg-aspect.yaml, kind in the JSON output. Not called: LLM aspect, judgment rule. More: Reviewers.

script rule ​

A rule written as a script (check.mjs) that runs on your machine — mechanical, repeatable and free. A script rule has no reviewer.

Machine token: deterministic — reviewer.type in yg-aspect.yaml, the --only-deterministic flag, kind and reviewer in the JSON output. Not called: deterministic aspect, deterministic reviewer. More: Reviewers.

bundle ​

A rule with no content.md and no check.mjs, only implies:. It brings in the rules it implies and records no verdict of its own.

Machine token: aggregate — kind in the JSON output. Not called: aggregating reviewer. More: Aspects.

status ​

How much the refusals of a rule count: draft, advisory or enforced. Set by status: on the rule, and raisable — never lowerable — at any site that attaches it; the effective status is the highest.

Not called: standing, enforcement level. More: Aspect Status.

draft ​

A rule parked as not-ready — it is removed from the expected set and verifies nothing.

More: Aspect Status.

advisory ​

A rule whose refusals show as warnings. They never block — except a pair whose prompt is too large to judge (prompt-too-large), an error at any status.

More: Aspect Status.

enforced ​

A rule whose refusals are errors: they fail yg check and block CI. The default status.

More: Aspect Status.

when-filtered ​

A rule was deliberately filtered out here — it does not apply to this node.

More: Conditional Aspects.

attach channel ​

One of the seven ways a rule reaches a node: its own list, an ancestor, its type, an ancestor’s type, a flow, a port, or another rule’s implies.

More: Aspects.

own ​

This rule is set directly on this component.

ancestor ​

This rule is inherited from a parent component.

own type ​

This rule applies to every component of this type.

ancestor type ​

Inherited from a parent component's type.

port ​

This rule crosses in from a port this component enters through a relation — a named one, or the target’s implicit default port.

implied ​

Pulled in by another rule that includes this one.

Judging ​

reviewer ​

The model configured in the reviewer: section of yg-config.yaml. It judges reviewer rules, and only those; nothing else is called the reviewer.

Not called: judge. More: Reviewers.

tier ​

The named reviewer setting an aspect uses — which model judges it, and how strictly. Tier means this and nothing else.

More: Configuration.

consensus ​

How many times the reviewer voted on a rule — more votes, more confidence in the verdict.

More: Configuration.

cost ​

A script rule costs nothing; the reviewer may cost a paid API call each time it judges.

pair ​

One rule checked against one unit — the thing a verdict is recorded for.

More: The Lock.

unit ​

What one check covers: a node’s files together for a per: node rule, a single file for a per: file rule.

More: The Lock.

verdict ​

What a check of one pair concluded — passed or refused — bound by hash to the exact inputs it saw.

More: The Lock.

fill ​

The run that records verdicts: yg check --approve. Script rules run for free; reviewer rules go to the reviewer.

Not called: approving run, recording run. More: CLI Reference.

passed ​

The verdict when the code satisfies the rule.

Machine token: approved — verdict in the JSON output and in the lock.

refused ​

The code broke the rule — with a reason you can read. Under an enforced rule it is an error; under an advisory one, a warning.

verified ​

The rule was checked against the current code and it passed. The only green.

unverified ​

No verdict matches the current code yet — it changed, or it was never checked. Not a pass — just “we don’t know”.

stale ​

An unverified pair that has a verdict, recorded over inputs that have since changed. The report calls it unverified, with cause stale; the JSON counts it apart from the pairs never judged, so the unverified pairs are totals.verdicts.unverified plus totals.verdicts.stale.

Machine token: stale — verdict in the JSON pairs[] and totals.verdicts, cause on an unverified finding.

finding ​

One thing a check reports — about a node, a pair, a file or a repository fact. The error and warning counts on the verdict line count findings, as totals in the JSON does.

More: CLI Reference.

block ​

Findings the report prints together, under one heading with one why: and one fix:. Where the two numbers differ, the verdict line says how many blocks hold the findings (5 errors in 2 blocks).

More: CLI Reference.

warning ​

An advisory rule flagged this. It does not block — it is signal worth a look, not a failure.

not applicable ​

A rule was filtered out here on purpose — an empty cell, distinct from unverified.

approval ​

A person’s sign-off — on a waiver’s reason, an advise item, the choice of a reviewer. The --approve flag runs a fill; it is not an approval, and running one needs none — a paid fill included, whose cost is always stated with it.

drill ​

yg drill: replay a rule’s case corpus to prove it catches what it should. Drilling a reviewer rule calls the reviewer. To focus on one rule’s findings instead, run yg check --aspect.

Not called: drill into (for yg check --aspect). More: CLI Reference.

Coverage ​

covered ​

A node or a type answers for the file: it is node-owned or type-covered. yg check counts covered files out of the files not excluded, and names the excluded ones beside them (3/5 files covered · 4 excluded); the JSON field coverage.covered keeps an older, wider count that adds the excluded files. Covered says nothing about whether a rule checks it.

More: Configuration.

node-owned ​

A file some node’s mapping lists.

More: Configuration.

type-covered file ​

A file no node owns that exactly one non-strict classifying type claims, and no strict type does. That type’s per: file rules enforce it.

Not called: type-level lattice, type tier, component-free file. More: Configuration.

type-level coverage ​

The feature that makes type-covered files, switched by coverage.type_level.

More: Configuration.

excluded ​

A file under a coverage.excluded root. Yggdrasil ignores it everywhere.

More: Configuration.

unmapped / uncovered ​

A file the graph does not account for. Under a coverage.required root it is an unmapped error; elsewhere an uncovered warning that never blocks.

More: Configuration.

unguarded ​

Nothing is checking this part. Not broken — just unguarded. Absence of red is not a pass.

The lock and waivers ​

lock ​

The committed record of reviewer verdicts (yg-lock.nondeterministic.json) and of each component’s log baseline and source fingerprint (yg-lock.logs.json; a node type’s decision-log baselines sit in yg-lock.types.json), beside a local, gitignored cache of script verdicts. CI re-proves it without a key.

More: The Lock.

log entry ​

Why a component’s own code changed, written with yg log add. A component whose type sets log_required owes one for each change to its own source — never for a rule, relation, lock or verdict change — and a fill stops before recording anything over a component it would fill that owes one.

More: The Lock.

positive closure ​

The moment a full yg check --approve ends with every enforced pair of a component settled: the fill records the component’s source fingerprint and its log baseline, and the next change to its own source owes a new log entry. --only-deterministic never records it.

More: The Lock.

line-scoped waiver ​

A yg-suppress marker with a reason. It waives the rules it names — one, a comma-separated list, or every rule with * — on the lines it covers: a single line, a bracketed range, or the whole file (the kind yg suppressions lists as file-level). It needs the user’s sign-off.

More: Reviewers.

waived ​

Someone waived a rule here, on purpose, with a reason. Not the same as verified.

suppressed ​

A waiver skips a rule on specific lines, with a reason. Waived is not verified.

live boundary ​

An undeclared code dependency, recomputed live right now — never read from the stored lock.

Packages ​

package ​

A set of rules published by one repository for others to install with yg pack add. The consumer gets a verbatim copy under .yggdrasil/aspects/packages/<owner>/<repo>/<package>/ and never edits it; it tunes the rules through adaptations.

More: Packages.

marketplace ​

A repository (or directory) that publishes packages: yg-marketplace.yaml at its root names each one, and a git tag pack/<name>@<version> publishes each version. yg marketplace check asks it everything an install would refuse.

More: Packages.

adaptation ​

The consumer’s own yg-aspect.adapt.yaml beside an installed rule: the settings (config) and the adaptable keys (status, scope, reviewer, review_by, references, companion) it sets for this repository. It survives updates; the rule’s history beside it is yg-aspect.adapt.log.md.

More: Packages.

package record ​

.yggdrasil/yg-packages.yaml, committed: what is installed, from where, at which version, tag and commit, and the hash of every copied file. yg check blocks any copy that no longer matches it (package-file-modified).

Not called: package lock (it records installs; it holds no verdicts). More: Packages.

The family ​

family ​

The Yggdrasil tool family: the tools released beside Yggdrasil that build on its graph, each doing one job; Family contracts lists them and the documents they exchange. A group of look-alike files is not a family.

More: Family Contracts.

law ​

The family’s word for the rules in the graph and the rails that hold every change to them. It is not a separate concept.