# Varro eduKG Source of truth: https://varro.mentormind.com.au ## 01 The five verbs The closed command grammar: ask, show, check, run, create. ### ask One of the five command verbs: request information without mutation. - Example: Inside a workflow, `ask` retrieves the named subject so later steps can reason over it. It reads; it never writes. Compare the `ask education-project-root` line in import-year10-authorities. - Example: At the command surface the grammar is closed: ask, show, check, run, create. `ask system status` queries authoritative truth and returns it; an unknown verb like `fetch` is rejected before it reaches a source. - Check: Does the `ask` verb ever mutate state? If not, which verbs do? ### show One of the five verbs: render/display a view of state. Prerequisites: ask - Example: `show` displays a selection without changing it. The report-demonstrator-claim-boundary workflow is built entirely from `show` steps because reporting is read-only. - Example: `ask` is about obtaining the value into the conversation; `show` is about rendering it for a human or a view binding. Both are non-mutating, but `show` carries presentation intent (a table, a detail pane). - Check: Both `show` and `ask` are read-only. What distinguishes them? ### check One of the five verbs: validate an artifact against its contract. Prerequisites: ask, show - Example: `check` runs a validation and yields pass/fail diagnostics. It mutates nothing; it asserts that an artifact conforms to its declared rules before a `create` step is allowed to proceed. - Example: A common, correct pattern: validate (`check`) every governing policy, and only then `create`. If a check fails, the workflow fails closed and the create never runs. - Check: What happens in a workflow when a `check` step fails? ### run One of the five verbs: execute a governed action/workflow. Prerequisites: check - Example: `run` executes a declared action or workflow. Under preview-by-default it first describes the governed action and its authority posture; the mutation only happens when `--execute` is opted in. - Example: A `run` step inside a workflow invokes a named action contract. The surrounding `check` keeps the run honest: nothing executes until the gate passes. - Check: When you issue `run`, does the mutation happen immediately? ### create One of the five verbs: bring a new governed artifact into being. Prerequisites: run - Example: `create` materialises a new governed record. In assert-magatama-source-of-truth it runs last, after the policies have been shown and checked, so the new artifact is born already validated. - Example: `create` brings a new entity into existence (a record, a contract); `run` executes an already-declared action over existing state. Use `create` for nouns, `run` for verbs. - Check: When do you use `create` rather than `run`? ## 02 The type model Systems, types, fields and closed enums. ### system Top-level VSL declaration; a named governed system with mission, authority, domain, maturity. Prerequisites: create - Example: Every VSL file is rooted in a `system`. It carries identity (the dotted name), a mission string, one or more authority lanes, a domain, and a maturity rung. Everything else (types, enums, workflows) lives inside its braces. - Example: Beyond the header, a system can bind a `context root` (its helios:// home) and declare `compile` lowering targets. These tie the abstract system to a concrete resource address and an output backend. - Check: What must a VSL `system` declaration include in its header? ### type A named record of typed fields inside a system. Prerequisites: system - Example: A `type` names a record. Each `field` has a name, a kind (string, uri, integer, bool, a named enum, or an array like string[]), and a required/optional marker. - Example: Fields can be constrained to a declared enum. Here the trailing comment names the enum that backs the field, moving a closed value set from prose into the type system. - Check: What does a VSL `type` contain, and can it hold methods? ### field A typed member of a type: name: type [required|optional]. Prerequisites: type - Example: A field is `field : ` inside a `type` block. The obligation is part of the type, not a downstream runtime check: `required` means the parser rejects an instance missing the member; `optional` admits absence. Kinds are the closed set string/markdown/uri/integer/number/bool, arrays (`string[]`), and named enums. Unlike a struct field default in Rust, optionality here is a declared property of the schema, not a `Default` impl — there is no inferred zero value, absence is absence. - Example: Typing a field by a named enum closes its value set at the schema layer: `subject` can only be `physics` or `chemistry`, and an unlisted value fails validation before any code runs. This is the VSL idiom for lifting a prose constraint ("subject is one of...") into a checkable invariant. Evaluate it against a stringly-typed alternative (`field subject: string`): the enum form makes the illegal state unrepresentable in the spec, which is precisely the property you would otherwise have to defend with a hand-written validator and a test. - Check: In `field source_pdf_ref: uri required`, what does the `required` keyword constrain, and at what layer is it enforced? ### enum A closed set of named variant values. Prerequisites: field, type - Example: An `enum` declares a finite set of `value` variants. A field typed by this enum can only ever hold one of these names, so illegal states become unrepresentable. - Example: Using a free `string` lets any typo through. Declaring an `enum` and naming it on the field documents the legal set and lets the checker reject unknown variants. - Check: Can a field typed by an enum hold a value not declared in that enum? ## 03 Actions & workflows Governed actions, ordered workflows, and reads. ### action A governed, risk-typed operation with declared inputs. Prerequisites: enum, type - Example: An `action` declares a governed operation: its typed inputs, a risk class, and a `lowers-to` target. It is invoked by the `run` verb and is subject to preview-by-default. - Example: An `action` is a governed mutation contract with four parts: a `risk` class, a `binding` (whether a concrete lowering target is required), and typed `input`s. The action does not contain an implementation body — it declares the contract and `lowers-to` an executable target downstream. Evaluate the separation: the risk class and binding are reviewable governance metadata sitting in front of the code, so an approver reasons about blast radius from the contract alone, before any implementation exists. - Check: What does an `action` declaration carry beyond its inputs? ### workflow An ordered sequence of steps composing actions/queries. Prerequisites: action, ask - Example: A `workflow` composes the five verbs into an ordered behaviour. Read top to bottom: gather, present, validate, then create. Order matters because each step can depend on the last. - Example: A `workflow` is a staged behaviour sequence written as verb + target pairs (`inspect`, `resolve`, `check`, `render`, `emit`...). It composes the declared queries and actions into an ordered pipeline; the ordering is the contract. Note these stage verbs are workflow-internal and distinct from the five-verb command grammar (`ask/show/check/run/create`) at the conversation surface. Evaluate it as a declarative DAG-of-steps: the spec states the sequence and bindings, and lowering generates the executor, so reordering is a spec edit, not a code refactor. - Check: Do the steps of a `workflow` run in order, and why does it matter? ### query A read of state with declared output and authorities. Prerequisites: workflow - Example: A `query` in VSL is a named read contract: it declares an `output` type (here a `ParsedPaper[]`) and the `authority` it reads from. It never mutates. The declared output is part of the contract surface, so an agent can statically know the shape of what a query returns without executing it. Contrast the `ask`/`show` verbs of the five-verb command grammar: those are interactive read commands at the conversation surface, whereas a `query` is a reusable declared contract inside a `system`. - Example: Place a `query` and an `action` side by side: the query has only an `output` and an `authority` and carries no `risk` because it cannot change state; the action carries a `risk` class and a `binding` precisely because it can. Evaluate the design: putting the mutate/read split into the grammar (queries simply cannot declare a risk class) means a reviewer never has to audit a query for side effects — the absence of a risk field is a proof obligation discharged by parsing, not by reading the body. - Check: A `query` declares an output type and an authority. Can it also declare a risk class and mutate state? Why or why not? ## 04 The maturity ladder draft -> checked -> bound -> hardened. ### draft VslMaturity level: unverified intent. Prerequisites: query - Example: `maturity draft` is the lowest rung: unverified intent. At draft the checker tolerates unresolved references and inferred defaults so authoring can proceed before everything is bound. - Example: `maturity draft` is the lowest rung of the ladder `draft -> checked -> bound -> hardened`. At draft, unresolved references and inferred defaults are tolerated, and lowering diagnostics are warnings rather than errors. This corresponds to `VslMaturity::Draft`, which the lowering severity function maps to `Warning`. Evaluate it as a TODO-tolerant compile mode: the document parses and is queryable while still incomplete, so you can stand up structure before every reference resolves. - Check: List the four VSL maturity rungs in order and say what changes at `bound`. - Check: What does the `draft` maturity rung allow that stricter rungs do not? ### checked VslMaturity level: validated by the checker. Prerequisites: draft - Example: `checked` is the second rung: the document has passed the checker. References resolve and types are consistent, but it is not yet bound to a concrete contract or hardened for production. - Example: `maturity checked` is the second rung. Structure is parser-validated (`varro check vsl` passes) but lowering diagnostics remain warnings — like `Draft`, `VslMaturity::Checked` maps to `Warning` in the lowering severity function. The jump in obligation happens at `bound`, not here. Evaluate the boundary: checked guarantees the shape is well-formed and queryable, but does not yet force every reference to resolve into an executable lowering — that promise belongs to the next rung. - Check: What does the `checked` rung guarantee, and what does it not? ### bound VslMaturity level: bound to a concrete contract. Prerequisites: checked - Example: `bound` is the third rung: the spec is bound to a concrete contract, so unresolved references become checker errors rather than warnings. Promotion to bound is the point at which laxness ends. - Example: `maturity bound` is the third rung and the first with teeth: the lowering severity function escalates `VslMaturity::Bound` (and `Hardened`) to `Error`, so a missing or unresolved lowering target now fails rather than warns. This is the rung where the spec commits to being executable. Evaluate it as flipping `-Werror` on for lowering: everything that was a tolerable gap at draft/checked now blocks promotion. - Check: What is true at the `bound` rung that is not true at `checked`? ### hardened VslMaturity level: hardened/production. Prerequisites: bound - Example: `hardened` is the top rung: production-ready. Everything is bound, checked, and the strictest diagnostics apply. A hardened system should not be silently relaxed back to draft. - Example: `maturity hardened` is the top rung of the ladder. Like `bound`, `VslMaturity::Hardened` maps lowering diagnostics to `Error`; hardened is the strictest promotion state a `.varro` document declares. This maturity ladder is the document's own rung and is orthogonal to the plasma->crystal phase model: maturity is the VSL's self-declared strictness, while phase describes how far the spec has crystallised toward proved Rust. Evaluate the design: a document can be `hardened` VSL and still only sit at the Gas phase, because the two axes measure different commitments. - Check: What does the `hardened` maturity rung represent? ## 05 Crystallisation phases Plasma -> Gas -> Liquid -> Solid -> Crystal. ### Plasma Crystallisation phase: intent as prose. Prerequisites: hardened - Example: The Plasma phase of crystallisation is unstructured intent, written as prose. Nothing is typed yet; this is the raw goal before any VSL exists. - Example: At the Plasma phase a `.varro` file is essentially a Quarto markdown document: design thinking and rationale as prose, with no formal VSL declarations yet. Consistency is maintained by human memory and the cost of change is near zero. Crucially the file is already under version control, so the specification's history begins here. Evaluate it as the hottest, most malleable state — the same artefact that will later acquire `type` and `action` blocks, not a throwaway design doc that gets discarded once "real" specs start. - Check: What form does a specification take in the Plasma phase of crystallisation? ### Gas Crystallisation phase: formal VSL declarations. Prerequisites: Plasma - Example: The Gas phase is the first formal condensation of prose intent into VSL declarations: systems, types, enums, workflows. It is structured but not yet property-checked. - Example: At the Gas phase formal VSL declarations (type/workflow/action) begin to crystallise inside the same `.varro` file, mixed with the surviving prose. It is parser-validated by `varro check vsl` but has no formal properties; the spec is queryable by agents yet not semantically complete. Evaluate the key design choice: the prose is not replaced by the VSL — documentation and specification coexist in one file, which is what eliminates doc/spec drift by construction. - Check: What is produced in the Gas phase of crystallisation? ### Liquid Crystallisation phase: VSL + Lean-spec properties, consistency-checked. Prerequisites: Gas - Example: The Liquid phase pairs the VSL with Lean-spec properties and checks them for consistency. The structure of Gas is now backed by stated invariants that hold together. - Example: At the Liquid phase the VSL sits at checked maturity and is joined by authored Lean-spec properties for key invariants; an internal Lean representation of the VSL structure is consistency-checked against the `.varro` file. Authority is dual: VSL owns structure, Lean-spec owns properties. This is where the spec is most actively governed because both shape and invariants are machine-checked. Evaluate the human cost: you author properties, not proofs — the correspondence proof is generated later at Solid/Crystal. - Check: What is added in the Liquid phase of crystallisation? ### Solid Crystallisation phase: Rust generated from VSL + Lean-spec. Prerequisites: Liquid - Example: At the Solid phase Rust is generated from the joint VSL + Lean-spec authority, the compiler enforces structural consistency, and the generated code compiles and passes tests — but Lean proofs may still be partial (`sorry` permitted). The specification is executable but not yet fully proved. Critically, VSL is not deleted here: it remains the human-readable surface, and editing it triggers regeneration of the Rust. Evaluate solid as a legitimate long-term resting state: not everything needs to reach Crystal. - Example: At the Solid phase Rust is generated from the joint VSL + Lean-spec authority, the compiler enforces structural consistency, and the generated code compiles and passes tests — but Lean proofs may still be partial (`sorry` permitted). The specification is executable but not yet fully proved. Critically, VSL is not deleted here: it remains the human-readable surface, and editing it triggers regeneration of the Rust. Evaluate solid as a legitimate long-term resting state: not everything needs to reach Crystal. - Check: What is produced in the Solid phase, and how does it differ from Crystal? ### Crystal Crystallisation phase: Rust fully proved against Lean-spec (zero sorry). Prerequisites: Solid - Example: The Crystal phase is the terminal state: the generated Rust is fully proved against the Lean-spec with zero `sorry`. Intent has crystallised end to end from prose to verified code. - Example: Crystal is the coldest, most constrained phase: the generated Rust is fully proved against the Lean-spec with zero `sorry`, and the correspondence proof is generated and checked, yielding mathematical certainty for every stated property. As at Solid, VSL is not discarded — it remains the editable surface, and an edit triggers re-verification rather than a free-text change. Evaluate the endpoint: Crystal is certainty for stated properties only; it does not invent invariants you never wrote at Liquid. - Check: What condition defines the Crystal phase of crystallisation? ## 06 Surfaces & lowering compile, route, view, agent, context, runtime. ### compile A lowering target: compile -> . Prerequisites: Crystal - Example: A `compile` line is `compile -> ` at the `system` scope, parsed into a VslCompileTarget {name, target}. It does not transform source text into a binary; it names a typed artifact the lowering pass is obligated to emit. The target is drawn from a closed set — `varro` (COMPILE_TARGET_VARRO) and `helios.contracts.context-bundle` (COMPILE_TARGET_CONTEXT_BUNDLE) — so an unknown target is a spec error, not a link error. Evaluate it as a build *contract*: the pair (name, target) is the obligation, and the compiler's job is to produce a lowering plan whose target bindings discharge exactly these. - Example: One system may declare multiple `compile` lines; `compile_targets` is a Vec, so each line adds an independent obligation rather than overriding the last. Here the same typed spec lowers to two consumers: the Varro runtime artifact and the browser context-bundle contract. Contrast with a Makefile target or a Cargo binary, where the *output path* is the unit — here the unit is a named lowering *channel* whose downstream shape is fixed by the target keyword. The compiler emits a binding-report per target; a missing or unsatisfiable target surfaces as a diagnostic before any artifact is written, which is the property that makes the spec, not the build script, load-bearing. - Check: In `compile workspace-runtime -> varro`, what is `varro`, and what fails if you write `compile workspace-runtime -> binary`? ### route A named helios:// resource address. Prerequisites: compile - Example: A `route` is `route = ""`, parsed into VslRoute {name, uri}. The name (`spec.contract`) is a stable handle a workflow can `emit`; the value is a canonical platform address. Validation enforces `uri.starts_with("helios://")` — a route whose value is not a helios:// URI is rejected with `must use a canonical helios:// URI`. The query string (`?view=...&tab=...&bind=auto`) is part of the address, selecting the rendering surface and binding mode. Read it as a typed, validated symlink into the Helios resource space, resolved by the platform, not an HTTP endpoint your server handles. - Example: Both lines are VslRoute entries on the same system, but the authority segment after `helios://` (`local` vs `external`) is semantically load-bearing: `local/...` addresses the governed spec/instance space, `external/...` addresses the deployed public surface. The route does not *create* the resource — it names an address the platform resolves through the authority stack. A workflow step `emit route spec.instance` therefore publishes a handle to an authoritative location, and the resolver decides what is actually returned. Evaluate the design: by forcing every navigable target through a named, helios://-validated route, the spec makes the full reachable surface enumerable and checkable, which a free-form string URL would not. - Check: In `route public.do = "..."`, what is the validation rule on the right-hand side, and what is the consequence of violating it? ### view A render binding for a doc/query selection. Prerequisites: route - Example: A `view` is `view for uses `, parsed into VslView {name, context_selector, target}. The `for` clause is a *selector* over the resource space (`doc:varro-v1-*` — a glob over doc ids), and `uses center.detail` names the render surface the platform mounts for any match. It declares a binding, not a component: there is no JSX, no template body, no props. Read it as a routing rule in the render layer — "for any doc matching this selector, present it with the center.detail surface" — which the host evaluates when resolving a navigable address. The `uses` target is itself a named platform surface (a panel/center mode), so the view composes two pieces of the typed spec rather than inlining markup. - Example: Two views on one system show the selector dimension: `for doc:varro-v1-*` matches document resources, `for query:varro-v1-*` matches named query results, each routed to a different surface (`center.detail` vs `center.table`). The selector prefix (`doc:` / `query:`) is the kind of thing selected; the glob picks the instances. This is a declarative dispatch table over the render layer — the platform, not the spec author, walks it to decide how a resolved resource is shown. Evaluate against a SQL view: there is no stored query and no materialised result set here; `view` produces no data, it only states which presentation surface a class of already-resolved resources is rendered through. - Check: Decompose `view spec.detail for doc:varro-v1-* uses center.detail` into its named parts and say what each one binds. ### agent An agent binding for a doc/selection. Prerequisites: view - Example: An `agent` line is `agent for -> `, parsed into VslAgentBinding {kind, context_selector, profile} where kind is the closed enum `default | alternate`. It declares which agent profile (`agent:software.architect`) the platform attaches when a resource matching `doc:varro-v1-*` is acted on. It is a binding in the spec, not a running process: nothing is spawned by this line. Read it as registering a capability assignment — "this class of docs is, by default, served by this architect profile" — that the host resolves on demand, much like a strategy registered against a type rather than a daemon you start. - Example: The kind keyword is constrained to `default` or `alternate` (any other token is `invalid_agent_kind`). The same selector can carry both: `default` names the primary profile the platform reaches for, `alternate` names a second profile — here an independent judge — available for review/escalation. This encodes a separation-of-authority posture directly in the spec: the doer and the reviewer are distinct, declared bindings rather than ad-hoc convention. Evaluate it as typed dependency injection with two registered implementations keyed by role, where the host chooses which to activate per task; no concurrency or process lifecycle is implied by the declaration. - Check: In `agent default for doc:varro-v1-* -> agent:software.architect`, which token set is `default` drawn from, and what does the `->` bind to? ### context A context root binding for a system. Prerequisites: agent - Example: `context root = ""` is parsed into a VslContextBinding {name: "root", value} and is *required* — a system missing `context root = ...` fails validation. It establishes the canonical address the system resolves relative to: the default view (`view=detail`), tab (`tab=contract`), and binding mode (`bind=auto`) under which the system presents when opened with no further selection. Read it as the system's base href / anchor in the Helios resource space — the one absolute point from which routes and views are interpreted — not as a runtime-scoped value passed down a call tree. - Example: The validator emits `system is missing context root = ...` when the binding is absent, so `context` is not optional decoration — it is the system's mandatory anchor. Because routes must be `helios://` and views/agents are interpreted against this root, the context binding is the fixed point that makes the rest of the navigable surface well-defined. Evaluate the constraint: requiring exactly one canonical root per system removes ambiguity about where the system 'is' in the resource space, which is the same discipline as requiring an absolute base URL before any relative reference can be resolved. - Check: What happens if a `system` block omits `context root = ...`, and what does that binding establish? ### runtime The runtime specification block (host, commit-mode). Prerequisites: context - Example: A `runtime { ... }` block is parsed into VslRuntimeBlock {name, settings} where each interior line becomes a VslSetting {key, value}. Here `host governed` and `commit-mode host-only` are two key/value settings, not statements that execute. `host = governed` declares the system runs under governed authority (the default host mode); `commit-mode = host-only` declares mutations may be committed only by the host, not by callers — encoding preview-by-default at the runtime layer. Read it as a typed deployment/authority manifest the lowering pass reads, analogous to a declarative service descriptor, not a language runtime or VM that the spec boots. - Example: The lowering layer reads settings by key: `runtime_setting(runtime, "host")` and `runtime_setting(runtime, "commit-mode")`, with `host` defaulting to `governed` when omitted. So the block is a key->value bag with known keys, and an absent key is filled by a declared default rather than being undefined. Evaluate the authority semantics encoded here: `host-only` commit-mode is what makes Varro preview-by-default — a caller can describe and review a mutation, but only the host may actually commit it. The runtime block is therefore where the spec pins its governance posture, expressed as data the compiler consumes, not as runtime behaviour the block itself performs. - Check: In `runtime specification { host governed; commit-mode host-only }`, what is `commit-mode` and what governance property does `host-only` establish? ## 07 Governance & principles Authority stack, preview-by-default, VSL, Varro. ### Authority Stack The layered authority model governing who may do what. Prerequisites: runtime - Example: The Authority Stack is a strict three-layer ordering. Authoritative sources (the Rust model, governance contract, policy engine, knowledge graph) hold truth; Varro is only a window onto them; callers sit above Varro. The load-bearing invariant is the tiebreak rule: on disagreement the source wins and Varro is by definition wrong. Evaluate the consequence — Varro holds no independent state of record, so it can be rebuilt or replaced without data loss, and you never reconcile "what Varro thinks" against "what the model thinks." - Example: At the source layer, authority is declared as named lanes inside a `system`: an operator lane, an agent lane, a reviewer lane. An action binds to a lane, so "who may do what" is data in the spec rather than scattered if-checks in code. Evaluate this against RBAC bolted on at the API edge: here the authority binding travels with the action contract through every phase of crystallisation, so the policy and the operation are co-located and co-versioned, and an unauthorised lane is a parse/governance failure, not a 403 discovered at runtime. - Check: Varro reports one value; the underlying Rust model reports another. Per the Authority Stack, which is authoritative, and what does that imply about where state of record lives? ### preview-by-default Default-safe principle: actions preview before they commit. Prerequisites: Authority Stack - Example: Preview-by-default means a mutating command (`run`, `create`) first renders the intended action, its risk class, and its authority posture, and commits nothing; the write happens only when `--execute` is supplied. This is the inverse of the usual CLI default where the command runs and `--dry-run` is opt-in. Evaluate the safety property: the safe path is the default path, so an agent or human cannot mutate by forgetting a flag — they can only mutate by adding one. - Example: Preview-by-default applies only to the mutating half of the five-verb grammar. `ask`/`show`/`check` are read-only and return immediately; `run`/`create` describe the governed action and its review/authority posture before committing. The asymmetry is deliberate: the gate is on state change, not on interaction. Compare a transactional DB shell where every statement is in an implicit transaction until COMMIT — here the COMMIT (`--execute`) is explicit and per-command, and reads are never in scope for it. - Check: You issue `varro create thing x` with no extra flags. What does the system do, and what flag changes that? ### VSL Varro Specification Language: the typed contract language. Prerequisites: preview-by-default - Example: VSL (Varro Specification Language) is a declarative layer for the checkable structure of a system (its types, enums, workflows, views, and bootstrap descriptors) — explicitly distinct from the five-verb interaction grammar (`ask`, `show`, `check`, `run`, `create`). A `system` block is the top-level VSL unit, carrying identity, mission, authority, domain, and compile targets. There are no statements that execute; every line is a typed declaration the parser turns into a VslSystem with vecs of types/routes/views/agents/contexts/compile_targets/runtimes. Read VSL as a schema-and-contract language whose 'output' is a checked, lowerable specification, not an imperative program. - Example: Every VSL document carries a maturity rung from the closed ladder `draft -> checked -> bound -> hardened` (VslMaturity::{Draft, Checked, Bound, Hardened}). The rung is part of the contract, not metadata: `draft` permits unresolved references and inferred defaults, while higher rungs progressively forbid them. This makes VSL a language with a built-in soundness dial — the same source is held to a stricter standard as it climbs. Evaluate the consequence for tooling: a derived knowledge graph can be *capped* at the source's VslMaturity, so a claim can never be presented as more settled than the spec it came from. The maturity keyword is thus a first-class typing of confidence, native to the language. - Check: VSL and the five-verb grammar (`ask`, `show`, `check`, `run`, `create`) are both 'Varro languages'. What does each do, and why are they distinct? ### Varro The specification system whose language is VSL. Prerequisites: VSL - Example: Varro is a governed query and control surface over the Helios platform — a system object with a conversational interface, not a chatbot or a database. The authority stack has three layers: authoritative sources (Rust model, governance contract, policy engine, knowledge graph) sit above Varro, which is the window, which sits above callers. The invariant is directional: if Varro and a source disagree, Varro is wrong by definition. Read this as a deliberate inversion of trust — Varro holds no ground truth, it only presents what the authoritative layer asserts. For a senior engineer, evaluate it as a strict read-through facade with no authoritative cache: correctness is defined by the sources, and Varro's job is faithful projection plus governed control, never substitution of its own state. - Example: Preview-by-default is Varro's mutation discipline: it first describes the intended governed action and its review/authority posture, and performs no mutation until `--execute` is explicitly opted in. This pairs with the runtime `commit-mode host-only` setting — the surface can plan and present a mutation, but commit authority is reserved. Evaluate the safety property: the default code path is observation, and side effects require a distinct, explicit act, which makes accidental or implicit mutation structurally impossible rather than merely discouraged. Contrast with a typical CLI/API where the call *is* the effect; here describe-then-(maybe)-execute is the built-in two-phase contract. - Check: In the Varro authority stack, what are the three layers and what is the rule when Varro and an authoritative source disagree?