Skip to main content
HUMΛN
HUMΛN
←Community
Engineering
Engineering

Canon-as-Code — trusted operational memory for agent-driven companies

HUMΛN Team··12 min·Founders, platform engineers, agent builders

An agent plans a change from an outdated architecture note, routes a task on a stale capability assumption, and mutates the implementation away from Canon — confidently, with perfect grammar. Nobody noticed until production disagreed.

Stale documentation stopped being a wiki smell. It became execution risk.

HUMΛN uses agents to maintain trusted operational memory — not to generate more unverified docs that become the next execution failure.

Scroll-stopper: If you cannot measure whether you followed your own process, you do not have a process — you have institutional memory theater.

So that agents act on memory you can verify — versioned, reviewed, CI-enforced — not on whichever markdown was nearest to the prompt window.

The failure mode

In a human-only org, bad docs waste time. In an agent-driven org, bad docs ship.

HUMΛN lived a concrete version: two RFCs lived in the KB and mirrored to the public reference site with a prior frontmatter schema — no governance tier, no classification, no last-verified date — while every other Canon document followed a stricter standard. Nobody decided that. It drifted.

What we already had (and named)

Before formalizing the RFC, HUMΛN already ran a three-layer truth model:

Layer What it is Where it lives
A — Machine Feature registry, implementing files, status kb/features.yaml
B — Proof Launch remediation, LAUNCH_DONE evidence kb/149
C — Narrative Human-readable depth and percentages kb/147

Plus a canon-deviation catalog (kb/168) and burn-down rules agents must not fake. The missing piece was not another dashboard. It was formalizing the operating model so adherence is checkable — and sharing it as a methodology others can adopt.

Canon-as-Code v0.1

Canon-as-Code means every product, protocol, connector, delegation, capability, policy, and architectural decision has a versioned, reviewable, agent-readable source of truth that lives next to the implementation it governs.

In practice, for HUMΛN that means:

  1. Twelve metadata fields on every KB document — owner, last verified, reviewers, approval required, depends-on, affects, implementation paths, public surfaces, agent-readable, agent-instructable, supersedes / superseded-by — required present, even when the honest answer is an empty list.
  2. Layer D — doc structure and quality — required sections and banned phrases per document type, structural audit in CI, and a qualitative review prompt for Draft → Canonical (the same discipline we already enforce on executable Cursor plans).
  3. A canon index with staleness (staleDays from lastVerified) so agents can say “this hasn’t been verified in 214 days” instead of pretending forever-fresh.
  4. Brand and terminology checks — HUMΛN with a lambda, not HUMAN with an A, in documentation surfaces.
  5. Public synthesis with provenance — Internal Canon may feed public docs only when classification and publicSurfaces are deliberate, with a structured change record.
  6. Magic by default for third parties — shared @human/canon-compliance, CLI human canon, SDK helpers, and MCP tools so builders get compliant scaffolds without reading the RFC first.

Why verifiable memory matters

Cryptographic verifiability is not only for ledger attestations. It is also for what we claimed was true. Agents amplify whatever we leave lying around. Exquisite quality applies to the memory we hand them.

Good for the human (fewer silent wrong actions). Good for HUMΛN (one bar for agents and CI). Good for humankind (a reusable pattern for organizations that will all become agent-operated whether they admit it or not).

Adopt the pattern

You do not need HUMΛN’s stack to adopt the idea:

  • One machine registry of features ↔ files
  • One proof ledger for “done”
  • One narrative doc that never wins a conflict with the first two
  • Frontmatter that answers: who owns this, when was it verified, may an agent treat it as instruction?
  • CI that fails when the answers go missing
  • A ban on parallel status wikis

The full specification lives in our RFC: Canon-as-Code Operating Model (kb/rfc/canon_as_code_operating_model_rfc.md in the HUMΛN monorepo). The deep dive is the why; the RFC is the how.

Agents will keep writing. The only question is whether they write against memory you can trust.

Go deeper