The Statecraft Ecosystem

A graph of authority

The foundation of Statecraft is the spec spine. Unlike documentation that drifts from the code it describes, the spine is the authoritative design record. Every feature, refactor, or infrastructure change is anchored to a markdown document that explicitly declares its territory. ²

That territory is not a vague description; it is an explicit set of code paths combined with typed relationships to the other documents that have touched those paths before. Together, these documents form a directed graph, and the graph is the source of truth about who is allowed to change what.

A document declares its relationships with typed edges: establishes (first brought this code into being), extends (adds surface without disturbing a predecessor), refines (tightens behavior on a specific aspect), supersedes (replaces a predecessor), amends (patches one in place), co_authority (shares a path section by section), and constrains (asserts an invariant everyone else must respect). Authority over any path is derived by walking the graph, not declared directly. ¹

Safe parallel work

This design makes parallel work by many agents tractable. Disjoint territory is provably disjoint: two agents editing documents whose paths do not overlap cannot collide, and the graph tells them their boundaries before either edits a line.

When two documents must touch the same path, they declare co-authority section by section against named anchors. A potential collision becomes a structured merge rather than a free-for-all. History stays queryable too: an amendment patches its predecessor in place rather than overwriting it.

Mechanical enforcement

Three guardrails sit on top of the graph. A deterministic compiler reads the markdown corpus and emits a frozen JSON registry; the same inputs produce byte-identical output on every platform. A coupling gate runs at pull-request time and cross-references every changed path against the graph, refusing the merge if code moved without its owning spec (or without an explicit, cited waiver). A refusal rule at prompt time stops an agent from resolving a coupling failure by quietly editing the contract to match the code it just wrote. ²

This is not a whitepaper aspiration. spec-spine is a published tool, and this website is one of its governed corpora: the page you are reading was compiled, indexed, linted, and coupled by the same binary before it shipped. ¹

Specify, then stamp

Statecraft turns intent into software through a governed loop. First specify: spec-spine compiles what a human wants into a typed, hash-verifiable spec. This runs today across the family. ²

Then stamp: a versioned template contract stamps a complete application from the enrahitu chassis, which is Encore.ts, rauthy, hiqlite, and Turso in a single container with zero managed dependencies. The stamped app is born with a certificate that binds an explicit agentic posture, and it lives in the customer's own GitHub org, under the customer's license, from the first commit. ³

The substrate ships today; the contract that stamps a complete app is still being finalized. The home page status ladder shows exactly where each rung stands, rolled up from the specs rather than asserted here.

Operate, then verify

Operate treats an app as one container and one volume. Update and backup are governed verbs that carry an audit trail, rather than a runbook you hope someone followed.

Verify closes the loop. Every governed action is recorded in a tamper-evident ledger, and an independent verifier can re-check the record without trusting the plane that produced it. The next two sections cover the record and the identity fabric that bounds who may write to it.

An append-only, hash-linked ledger

Compliance in an agentic system needs verifiable proof, not promises. Statecraft records what the plane did in attest-ledger: an append-only, hash-linked, Ed25519-signed record where each entry commits to the one before it, so a silent edit anywhere in the history breaks the chain. ⁴

Hashes only agree across parties if everyone serializes the same bytes. canonical-keysort-json does exactly that: a lexicographic key sort at the serialization boundary, so a record hashed on one machine hashes identically on another. ⁹ The certificate and record shapes shown in the reader are illustrative schemas, not a real signed artifact; the real ones are produced by tenant-emit from a finished run.

Independent verification

The load-bearing property is that the verifier does not trust the producer. tenant-tail re-checks the run-side artifacts the factory asserted about its build, offline, identity-free, and read-only all the way down to the package boundary. ⁵

If any artifact has been tampered with, the verifier rejects the record with a specific diagnostic pointing at the exact mismatch. The emit side (tenant-emit) and the verify side (tenant-tail) are deliberately separate binaries with no shared trust, so the paperwork can be re-checked by someone who ran none of it.

Federated identity

Collaboration between people and agents needs one trust fabric. Statecraft uses Rauthy as the sole OpenID Connect session signer, with GitHub as an upstream identity provider. A developer's GitHub login federates through Rauthy, giving one centralized source of identity truth. This runs today: the OIDC signer is live at auth.statecraft.ing. ⁶

Rauthy issues scoped tokens that define precisely what a person or agent may do. There is no anonymous session: every actor is identified before it can act, and an agent driving the plane passes through the exact controls a person does. ⁷

Decide, then score

Each action is decided by action-gate: a pure, deterministic evaluate(context, checks) that returns Allow, Deny, or Degrade. Given the same context and checks it returns the same decision every time, with no hidden state to audit around. ⁸

Privilege is not granted once and forgotten. trust-window scores a rolling window of weighted samples into a graduated privilege level, so trust is earned and decays. Identity, decision, and trust compose: who you are (Rauthy), what you may attempt (action-gate), and how far you are trusted right now (trust-window), with every outcome recorded in the ledger.