A Rust struct annotated #[derive(Facet)] is the storage schema. facet-git-tree maps struct ↔ Git tree directly; no serialization format exists to version.

Changing a struct is a storage migration, not a refactor — and a migration is itself a signed commit: rewrite the tree under the new struct, commit on the ref’s old tip. History keeps the old encoding as archive. Trees stay pure struct representations — no version marker entry.

Ref-level metadata that is not entity content — who, when, the signature — lives in the commit header, because the commit is already the storage unit; no reserved trailer exists. Refname binding needs no stored metadata at all: the refname is a total function of signed content, recomputed at verification (see 3).

Tip invariant: the tip of a meta-ref is always readable by the binary that owns the entity type; a non-owning binary treats the tree as opaque and degrades to generic display (git store show); history is archival. (Redacted entries are the one qualification: readers surface a withheld object as a redaction marker, never an error — see Derived.)

A Binding, homed in the anchor crate (ents-anchor), is the single typed-reference vocabulary into the object graph. Exactly five variants, each named by what it is bound to:

Reachability witness rule: every binding carries at least one witness commit, and the ledger commit that stores the binding links each witness as a second parent — ordinary git reachability then keeps the bound objects alive. Content-typed bindings (Tree, Delta) need a witness because a subtree is reachable only through some commit; the rule generalizes the review pin (model.review-pin). The two retention mechanisms coexist without contradiction: embedding preserves a Position’s content inside the binding’s own tree; witness parents keep bound objects reachable from the ledger commit that stores the binding. Witness is provenance, not identity: two claims binding the same Tree oid via different witnesses bind the same target.

Validity: revalidate(binding, state) → Valid | Stale | Unknown, judged per variant:

Bindings are independent of any consumer; comments use Position, claims bind any variant.

A ref under refs/meta/* is simultaneously the unit of:

Granularity rule: one ref per independently-authored entity (refs/meta/member/*, refs/meta/issues/*, refs/meta/comments/*, refs/meta/effects/*, refs/meta/results/*); one ref for repo-global state (refs/meta/account, refs/meta/config). Entities that different actors write concurrently must not share a ref. Writes stay conflict-free; reads aggregate refs into views.

Two namespaces are consequences of the granularity rule plus the gate (5):

Both hold the same typed trees as their canonical counterparts; only the refname rule differs.

Every meta-ref mutation is an author-signed commit. Which artifact carries the authorization evidence is a carrier question internal to the ledger, not an abstraction of its own — and the answer is the commit signature: a data artifact, not a transport artifact. It replicates with the repo and verifies offline in every clone, so verification evidence is itself repository state. Push certificates are demoted to transport concerns; they carry no meta-ref semantics.

A commit signature proves authorship; it does not prove placement. The difference is recovered explicitly:

Tip invariant: the tip of a meta-ref is signed by a member authorized for that refname. This is checkable after the fact by anyone with a clone, not only by whoever ran the server.

Adoption, never rewrite: when author and placer differ — an inbox entity accepted by an admin, a user-run result accepted by a maintainer — the authorized member merges the contributor’s commit onto the canonical ref. The merge commit satisfies the tip invariant; the contributor’s signed commit sits in ancestry with attribution cryptographically intact. Cherry-picking creates a new commit object and destroys the author’s signature; it is forbidden as an adoption mechanism. Fast-forwarding directly to a contributor’s commit would put an unauthorized signature at the tip; adoption is always a merge, even a trivial one.

The same merge covers a member’s own divergence: two of your machines can race your single-writer ref, and sync resolves it by merging your own heads rather than erroring. Author and placer are both you, the merge tip descends from the old tip, and the tip invariant holds as written; typed trees merge schema-aware, not textually.

The principled split: content signatures carry authorization only where mutations are author-signed single-writer appends — which the granularity rule guarantees for meta-refs. On refs/heads/*, pushing commits you did not author is legitimate, so branch refs keep transport-level auth. "Signed push is the only write path" is therefore retired; the invariant is the tip invariant above, which is strictly stronger where it applies.

Recorded, never erased: ledger history is never rewritten; a state change is recorded as new state, never erased from old — revocation, for instance, is a state on the member entity, not a deletion (see Command surface). Redaction (see Derived) is the sole deliberate exception.

A claim is a kernel ledger entity: signer × binding × verdict, the verdict a small closed enum — affirm, deny, note — plus an opaque kind the kernel never interprets. Kind vocabularies (review, ci, …) are package policy, never kernel enumeration.

Storage is one ref per claim under refs/meta/claims/<id>, where the id is the genesis commit’s own oid — the standard sign-then-name envelope — honoring the granularity law: claims by different signers never share a ref. Authorship is the standard signed-commit path; no privileged writers.

The claim’s ledger commit carries its binding’s witness commit(s) as extra parents — the binding reachability rule (2) — reusing the review-pin retention mechanism.

Open question, deliberately unresolved: whether claims subsume effect results. The results()/meta() query atoms and the result taxonomy (6) are unchanged pending that decision.

(Gap: no shipped feature consumes claims yet; reviews-over-claims is follow-up work.)

Verification is a pure function over ref-store reads:

Because members and refname rules live under refs/meta/*, the policy is repository state: any frontend evaluates the actual policy, offline, staleness bounded by last fetch.

Verification epoch: the gate applies the tip invariant from an epoch recorded in refs/meta/config; history before the epoch is archival — the typed-tree stance, applied to verification. The epoch-setting commit is the first gated tip of the config ref, which resolves the bootstrap circularity of reading the epoch from the very ref the gate verifies.

The gate is a property of the store, not of writing:

Enforcing the gate locally would destroy offline-first: you could not author while unenrolled or work against an unfetched member list. You can always write locally what hosted will never accept; the moment a verdict predicts rejection — at commit time in the local UI, or at push pre-flight — sync offers to route the commit to your inbox ref instead, not only after an actual rejection.

Three call sites, one function: hosted CAS, local UI verdict, push pre-flight. A verdict is never a bare pass/fail: on failure it carries which rule failed and for which refname, so the local UI and pre-flight can render an actionable reason — "your signing key is not authorized for refs/heads/main" — instead of an opaque no. The hosted server is not where policy lives; it is the one place where the verdict has teeth.

The local web UI signs as the user, with the user’s own member key, indistinguishable from CLI-authored commits. Server-key signing of UI edits is a hosted necessity only (a browser cannot hold the git signing key) and must not be imported locally, where it would be strictly worse provenance.

An effect is a declarative, content-addressed subscription to a commit-set query, whose execution is sandboxed and whose output re-enters the repository as verified data. It is repository data under refs/meta/effects/<name>:

Results location is derived by convention, never declared by the effect: an effect cannot choose where its verdicts land.

Trigger semantics: the trigger denotes a set of commits; the effect fires once per commit that enters the set. The query algebra is deliberately tiny:

RefPattern survives as the degenerate query rev(<glob>); nothing shipped changes meaning. (Gap: CommitQuery beyond the degenerate case is design, not code.)

Monotone, entry-only: a force-push can shrink a set, but a commit leaving the set retracts nothing — results are immutable history; the commit merely stops being an obligation. Monotone semantics is what makes distributed evaluation safe with no coordination beyond the existing CAS.

No pipeline state: the work set is trigger − results(self, any) — the results ref is the materialization marker. The dedup key (effect, oid) over an at-least-once queue yields exactly-once outcomes with zero state outside the repository.

Result taxonomy: a result is pass, fail, or error. Command exit status is always a result — pass or fail means the effect ran. Infrastructure failure is not a result: it is a queue concern with bounded retry, and only retry exhaustion writes a terminal error result, signed by the worker’s member key like any other. Retry bounds are deployment configuration, like executor choice — never effect data. This keeps the work set correct in both directions: a transient outage can neither retry forever nor permanently discharge an obligation.

Recursion is structure, not a rule: downstream-of-effects is syntactically visible — a query names results(…​) or it does not. Closure is opted into by writing the query you mean; because rev() and meta() cannot name an effect-written ref, the accidental fork bomb is unreachable by construction.

Pipeline invariants:

Identity discipline: the runner is a member, not an ambient authority. A result signature proves who pushed the result, not that the run was faithful; official results are official because canonical results refs are writable only by designated worker keys — a refname rule, not a runtime property. Any member may run any effect on their own executor and account; their results land in refs/meta/self/<member>/* or the inbox, adoptable by merge like everything else, with the trust decision explicit in the adoption. Anyone can run CI; nobody can impersonate the verdict.

Where the line holds: no content predicates beyond results(…, status), no time atoms, no external-event atoms. A query language that reads file contents is a build system’s dependency scanner in the trigger layer; that work belongs inside effects, not around them. The bet, stated as a bet: DAG membership plus results membership is a sufficient trigger basis, and composition happens in the repository, not in a workflow language.

The sandbox bounds the runtime blast radius; the admin-only write rule on refs/meta/effects/* bounds who can schedule execution on canonical infrastructure at all. Hosted mode requires both.

''