How It Works¶
Aevum is a replay-first, policy-governed context kernel. This page explains the data flow from raw input to governed output.
The big picture¶
Every piece of data entering Aevum passes through the same path:
Your data source
↓
governed membrane ← Barriers 3 (consent) and 5 (provenance) checked here
↓
knowledge graph ← urn:aevum:knowledge (working data)
↓
episodic ledger ← urn:aevum:provenance (immutable audit, sigchain)
↓
consent ledger ← urn:aevum:consent (OR-Set grants)
When an agent queries context, traversal goes through the same governed path in reverse — consent is checked before any graph traversal begins.
The three named graphs¶
Aevum maintains exactly three named graphs. These URIs are frozen invariants.
| Graph URI | Contents | Mutable? |
|---|---|---|
urn:aevum:knowledge |
Working data — entities, relationships | Yes (via ingest) |
urn:aevum:provenance |
Every audit event, sigchain | Never (append-only) |
urn:aevum:consent |
Consent grants and revocations | Append-only |
Step-by-step data flow¶
1. Ingest¶
An agent calls engine.ingest() with data, provenance, a purpose, and a subject ID.
Before anything is written:
- Barrier 5 (Provenance) —
provenance.source_idmust be present. If missing → error. - Barrier 3 (Consent) — the
grantee_idmust hold an active grant foringestonsubject_id. If not → error. - Barrier 1 (Crisis) — the payload text is scanned for crisis keywords. If found → crisis envelope, operation halted.
- Barrier 2 (Classification Ceiling) — enforced at query time (see below).
If all checks pass:
- Data is written to urn:aevum:knowledge
- An AuditEvent is created, signed with Ed25519, chained with SHA3-256, and appended to urn:aevum:provenance
- An OutputEnvelope with status="ok" and an audit_id (URN) is returned
2. Query¶
An agent calls engine.query() with a purpose, list of subject IDs, and an actor.
- Barrier 3 (Consent) — checked for each
subject_idin the list - Barrier 2 (Classification Ceiling) — results above
classification_maxare redacted, not errored
The result is an OutputEnvelope whose data["results"] is a dict keyed by subject ID.
Query Witness¶
Every query() call captures a Witness: the current sigchain
sequence number for the queried subjects and a digest of the
result set. The witness is returned in the OutputEnvelope and
should be stored by the caller.
When a commit() follows a human review gate — meaning time passes
between the query and the commit — pass the witness to commit().
If any new ingest events have arrived for the queried subjects,
or if the result set has changed, commit() returns stale_context
and logs a context.stale event to the sigchain. The operation
restarts from query() with fresh context.
This closes the TOCTOU window: the audit trail now proves not just what the agent decided, but that the state the decision was based on was still current when the commit fired.
3. Review¶
An agent calls engine.review() when it needs human approval for an action.
The call creates a pending review record. A human later calls engine.review(action="approve") or engine.review(action="veto").
The default is veto. If the deadline passes without a human decision, the action is blocked.
4. Commit¶
An agent calls engine.commit() to record a named event in the episodic ledger.
This is a write-only operation — it appends to urn:aevum:provenance.
Use commit to record business events: "credit issued", "policy approved", "document signed".
5. Replay¶
An agent calls engine.replay(audit_id=...) to retrieve and verify the exact
signed record of any past ledger entry. The payload is retrieved from
urn:aevum:provenance and returned in data["replayed_payload"].
Replay requires a consent grant with "replay" in the operations list.
The OutputEnvelope¶
Every function returns exactly one OutputEnvelope. No exceptions.
result.status # "ok" | "error" | "pending_review" | "degraded" | "crisis"
result.audit_id # "urn:aevum:audit:<uuid7>"
result.data # function-specific payload
result.confidence # float [0.0, 1.0]
result.provenance # ProvenanceRecord
result.warnings # list[str]
Always check result.status before accessing result.data.
What Aevum does NOT do¶
- Does not move data between your systems (that is your integration layer)
- Does not run agents (agents are external; they call the five functions)
- Does not orchestrate prompts or chains (use LangChain, LlamaIndex, etc. for that)
- Does not generate compliance reports (the episodic ledger is evidence, not a report)
- Does not expose a general graph query endpoint (graph access is through
queryonly)
See NON-GOALS for the full normative list.