Federal AI/Engineering reference · v1.0 · August 2026

The Evidence Ledger.

Every governed Federal AI workflow writes one append-only, hash-chained record of everything consequential it does. This page documents that record, the structure that answers who asked, who approved, and what changed for any output the system has ever released, and publishes the reference schema so your engineers and assessors can hold ours to it.

Free to reference with attribution · Published under the Cleared FDE Standard §2.4

Why a ledger, not a log

Logs describe the system. The ledger answers for it.

A log is whatever the developers happened to print. A ledger is a commitment: every consequential step, assignment, ingest, model call, recommendation, hold, approval, release, rollback, is one event in an append-only chain, and each event carries the digest of the one before it. Remove an event and the chain breaks. Reorder events and the chain breaks. That is the property a review board actually needs: not "we have logs," but "nothing happened outside this record, and the record cannot be quietly edited."

01 / Who asked

Every chain starts with an assignment event naming the mission question, the owner, and the acceptance test. Every later event traces back to it through on_behalf_of.

02 / Who approved

Write-scope events must reference an approval event recorded earlier in the chain, made by a named human. Services and models never approve their own actions.

03 / What changed

Inputs and outputs carry content digests, so any released artifact can be diffed against exactly the source records it was built from, at the age they were read.

04 / Fail closed

v1.0 admits only fail-closed workflows: when authority is ambiguous, the action holds and the hold itself is recorded. Silence is not approval.

The record

One event, five blocks.

An event is a small JSON object with five blocks: ledger (chain bookkeeping), event (what happened, in the vocabulary of the operating loop), actor (who did it), authority (under what permission), and optional inputs / outputs / model blocks binding the step to its sources and artifacts. Digests are SHA-256 over canonical JSON (RFC 8785). This example is synthetic and abbreviated:

{
  "ledger": {
    "chain_id": "wf-readiness-demo",
    "seq": 7,
    "prev_digest": "e3a654c9…1af8",
    "digest": "758f0d72…23cf",
    "recorded_at": "2026-08-24T14:02:11Z",
    "hash_alg": "sha-256"
  },
  "event": {
    "type": "recommendation",
    "workflow_id": "wf-readiness-demo",
    "summary": "Recommended schedule recovery for the highest-risk aircraft."
  },
  "actor": {
    "kind": "model",
    "id": "route:local-primary",
    "on_behalf_of": "wf-readiness-demo#1"
  },
  "authority": {
    "scope": "recommend",
    "basis": "assignment wf-readiness-demo#1",
    "fail_state": "closed"
  },
  "inputs": [
    { "system": "maintenance-data", "record_ref": "mx-047-1", "digest": "43cf5474…760b", "age_seconds": 111600 },
    { "system": "flight-scheduling", "record_ref": "sch-047", "digest": "c07c1ed1…1da6", "age_seconds": 540 }
  ],
  "outputs": [
    { "kind": "recommendation", "digest": "945708a1…be13", "location_ref": "evidence://wf-readiness-demo/rec-7" }
  ],
  "model": {
    "route": "local-primary",
    "model_id": "approved-local-model",
    "params_digest": "2ba4893c…75b0",
    "eval_ref": "evalset://wf-readiness-demo/v3"
  }
}

Three rules give the structure its force. Rule one: consequential events (release, config_change, rollback) are invalid without an authority.approval_ref pointing at a human approval earlier in the chain, conforming implementations refuse to append them. Rule two: inputs are references and digests, never copies, so the ledger itself stays free of controlled data and can live at a lower sensitivity than its sources. Rule three: the chain is verified as a whole, an integrity_check event records each verification, so "when did you last prove the ledger intact" is itself answerable from the ledger.

Using the schema

Written to be held against us.

The reference schema is a JSON Schema (draft 2020-12) you can drop into a validator today. Use it three ways: as an evaluation instrument, ask any vendor claiming "auditable AI," including Federal AI, to show you events that validate against a published schema; as a design baseline, adapt the blocks to your own governed workflows, with attribution; or as an acceptance artifact, the Cleared FDE Standard's §4.3 ("every consequential action shows a named human approval, and no action exists outside the ledger") is testable directly against this structure.

Scope and versioning

v1.0, August 2026. The schema is a public reference: deployed implementations extend it per customer environment, and those extensions are documented in the customer's own acceptance materials, not here. Revisions are versioned and dated on this page. Feedback: lc@federal.ai.

See it running

The cockpit demo writes this ledger live.

The Mission Cockpit demonstration runs a synthetic readiness workflow through the full loop, every evidence row you see carries the digest that binds it to the chain.