Appendix E · Glossary v0.1

Glossary and Schema References

Report terminology · liability-receipt/v1 · aegis/1

Canonical definitions for The Prove Gap Report and the Aevesa Prove layer. Schemas are open, verifier-neutral, and intended for offline audit workflows.

Core terms

Prove Gap: Distance between having agent policies and proving what agents did, under which authority, in a format auditors verify offline without vendor login.
Evidence Gap: Vendor-scoped logs vs portable cryptographic proof. Closed by Prove + Verify layers. 90s demo.
Agentic Evidence Infrastructure: Runtime governance category: intercept, decide, prove. Aevesa positioning.
HITL: Human-in-the-loop approval bound to evidence (not a disconnected chat thread). EU AI Act Art. 14 alignment.
DENIED receipt: session.outcome: blocked on liability-receipt/v1. Block paths need proof too.
Hidden buyer: Legal, audit, procurement, or finance stakeholder who stalls agent sign-off without being the primary user.

Prove Gap and PMM

PMM	Name	Gate
0	Ad hoc	Chat only; no inventory
1	Documented	Policies; no runtime enforcement
2	Routed	Gateway or guardrails; vendor logs
3	Enforced	Pre-execution intercept (Prove Gap often remains)
4	Proven	Receipts + offline verify tested
5	Assured	Drift monitoring + audit export packs

Take the PMM self-assessment

Stack layers (Route → Classify → Prove → Verify)

Layer	Question	Example
Route	How does traffic flow?	LLM gateway, MCP proxy
Classify	What data/risk class?	AI-SPM, guardrails, DLP
Prove	What executed, under what authority?	`liability-receipt/v1`, Aevesa Ledger
Verify	Can a third party confirm offline?	verify.aevesa.com, `@aevesa/verify`

Invariant: Intercept · Decide · Prove

Schema: liability-receipt/v1

Portable accountability document for one governed agent outcome (Verified Autonomous Session).

Canonical URI: aevesa.com/schemas/liability-receipt/v1
Verifier: verify.aevesa.com · @aevesa/verify

Five accountability pillars

Pillar	Audit question
I Identity	Who acted, under what authority?
II Policy	What rule was in force at decision time?
III HITL	Was human release explicit and one-shot?
IV Side effects	What material outcome occurred?
V Proof	Can integrity be recomputed without vendor UI?

Required fields (top level)

schema, receipt_id, issued_at, issuer, session, identity, policy, hitl, side_effects, proof, integrity, diligence_summary

Session outcomes

permitted · blocked · pending_human_release · released_after_hitl

Schema: aegis/1

Hash-chained ledger preimage spec. Each row has entryHash = SHA256(serialized preimage). aegis/1 is Aevesa’s internal identifier and is unrelated to Project Aegis or other products named Aegis.

Preimage field order (normative)

agentId
eventType
severity
payload
timestamp
prevHash (or GENESIS)
contextHash
governanceBinding

Bound on receipt via proof.ledger_spec: "aegis/1" and proof.anchors[].entry_hash.

entryHash = SHA256( serializeEntryHashInput(preimage) )

Offline verification (Tier A)

Validate structure against liability-receipt/v1
Recompute integrity.receipt_digest
Confirm proof.ledger_spec === "aegis/1"
Optionally recompute entryHash from ledger export
Validate HITL fields for high-risk profiles

Developer verifier guide · Trust Bundle · Conformance lab · Open Evidence API