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).

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