.epi artifact format for portable compliance evidence output

[mohdibrahimaiml]

Your governance toolkit does runtime compliance checking with Ed25519 signing — really impressive work.
One gap I see: after the toolkit grades an agent's compliance, where does that evidence go? Right now it's in-memory or in logs. There's no portable, verifiable artifact a regulator can independently inspect.
I maintain EPI Recorder (pypi.org/project/epi-recorder, 16K+ installs) — it packages AI agent execution into signed .epi artifacts that contain the full decision trail, policy evaluation, and human review. Already integrates with LangChain callbacks, which your toolkit also uses.
Would the team be open to exploring .epi as an output format for compliance evidence? Happy to prototype the integration.
mohdibrahim@epilabs.org
Spec: epilabs.org

[imran-siddique]

Interesting proposal @mohdibrahimaiml. You have identified a real gap — our compliance evidence currently lives in-memory or in SQLite audit logs.

We recently added an Annex IV technical documentation exporter (#782) that aggregates ComplianceReport, PolicyDocument, audit logs, and SLO data into structured Markdown/JSON. This could be extended to produce a portable .epi-style artifact.

The key question is whether to define a new format or align with existing standards (CycloneDX attestations, SLSA provenance, Sigstore bundles). Would you be interested in drafting a proposal that maps AGT evidence types to a portable format? Could be a great contribution.

[mohdibrahimaiml]

@imran-siddique

Quick update — I drafted the RFC discussed above:

mohdibrahimaiml/epi-recorder#11

https://github.com/mohdibrahimaiml/epi-recorder/blob/rfc/agt-portable-evidence-mapping/docs/rfcs/agt-portable-evidence-mapping.md

The RFC focuses specifically on how AGT governance evidence maps into a portable, signed evidence envelope without requiring AGT runtime changes or altering AGT semantics.

Main areas covered

• field-level mapping of AGT evidence types
• preservation vs normalization semantics
• replayability and offline verification
• threat model and integrity guarantees
• standards-alignment boundaries (in-toto, SLSA, CycloneDX, SCITT, Sigstore)
• explicit non-goals to avoid overclaiming

The intent is not to position .epi as an AGT replacement or official standard, but as an optional external evidence/export layer for portability and long-term audit workflows.

Areas where feedback would be especially valuable

1. whether the field-level mappings preserve the right AGT semantics
2. whether the normalization-loss disclosures are sufficient
3. whether the standards-alignment boundaries are drawn correctly
4. whether this should remain purely external vs adapter-level interop

Inline comments on the RFC are welcome.

[musaabhasan]

A portable evidence artifact is worth pursuing, but I would keep the format close to existing assurance patterns rather than inventing a completely separate compliance container.

A practical evidence package could have:

• manifest: artifact id, generator, timestamp, subject system, environment, schema version,
• control map: framework, requirement id, control id, coverage status,
• evidence references: policy document, audit event, test result, SLO report, incident record, approval record,
• integrity: content hashes for every included artifact,
• redaction metadata: what was omitted and why,
• signatures/attestations: who produced and approved the package,
• and verification instructions.

The useful boundary is that the package should not claim compliance by itself. It should preserve evidence in a portable, replayable way so another system or assessor can verify coverage. Alignment with in-toto attestations, CycloneDX-style evidence references, or SCITT-style transparency patterns may make adoption easier than a fully new .epi format.

[mohdibrahimaiml]

@musaabhasan

Following up on your earlier comment around keeping the package close to existing assurance patterns rather than inventing a standalone compliance container — I incorporated that framing heavily into the RFC:

mohdibrahimaiml/epi-recorder#11

https://github.com/mohdibrahimaiml/epi-recorder/blob/rfc/agt-portable-evidence-mapping/docs/rfcs/agt-portable-evidence-mapping.md

In particular, the current draft explicitly separates:

• integrity vs compliance claims,
• raw preservation vs synthesized analysis,
• portable evidence packaging vs policy evaluation,
• and standards alignment vs standards replacement.

The RFC now includes:

• field-level mapping tables for AGT evidence types
• preservation/loss semantics during normalization
• explicit non-goals to avoid overclaiming
• standards-boundary sections for in-toto, CycloneDX, SLSA, Sigstore, and SCITT
• threat-model and replayability assumptions
• redaction metadata and verification guidance

The overall direction is intentionally:
“portable, replayable evidence envelope carrying standards-native artifacts”
rather than
“new compliance framework replacing existing standards.”

Would especially value your feedback on whether the standards-alignment boundaries and evidence-preservation model are drawn correctly from an assessor/audit perspective.

[mohdibrahimaiml]

@imran-siddique

Quick update — I drafted the RFC discussed above:

mohdibrahimaiml/epi-recorder#11

https://github.com/mohdibrahimaiml/epi-recorder/blob/rfc/agt-portable-evidence-mapping/docs/rfcs/agt-portable-evidence-mapping.md

The RFC focuses specifically on how AGT governance evidence maps into a portable, signed evidence envelope without requiring AGT runtime changes or altering AGT semantics.

Main areas covered

• field-level mapping of AGT evidence types
• preservation vs normalization semantics
• replayability and offline verification
• threat model and integrity guarantees
• standards-alignment boundaries (in-toto, SLSA, CycloneDX, SCITT, Sigstore)
• explicit non-goals to avoid overclaiming

The intent is not to position .epi as an AGT replacement or official standard, but as an optional external evidence/export layer for portability and long-term audit workflows.

Areas where feedback would be especially valuable

1. whether the field-level mappings preserve the right AGT semantics
2. whether the normalization-loss disclosures are sufficient
3. whether the standards-alignment boundaries are drawn correctly
4. whether this should remain purely external vs adapter-level interop

Inline comments on the RFC are welcome.

[ElamOlame31]

The key distinction we kept hitting: the audit record needs to be sealed before execution fires, not after — otherwise it's a log, not evidence. AgentGate generates a Merkle-chained entry (SHA-256, append-only, O(log n) inclusion proofs) before the action executes.

Has .epi addressed this pre-execution sealing requirement? Would love to explore interop.

https://github.com/ElamOlame31/agentgate-public
https://www.tryagentgate.com/

[mohdibrahimaiml]

@ElamOlame31 Good point. You're right that pre-execution sealing (intent commitment) has value — especially for governance intent ("did someone authorize this?"). AgentGate's Merkle-chain approach solves that elegantly.

But for compliance evidence under Article 12, regulators ask a different question: "What actually happened?" That requires post-execution sealing of the complete trail (inputs, outputs, decisions, policy checks, errors, human review). Pre-execution commitment proves you intended an action; it doesn't prove the action was safe or compliant after execution.

EPI captures the full execution outcome. The steps.jsonl is itself cryptographically chained (prev_hash binding each step to its predecessor), plus manifest Ed25519 signature, plus optional SCITT anchoring. Different sealing point, not weaker — just answering the auditor's question instead of the governance question.

@imran-siddique @musaabhasan — this exchange is clarifying: AGT needs to decide whether Annex IV evidence should capture execution outcome (what actually happened) or just preserve raw artifacts for assessors to reconstruct. Outcome sealing is what regulators expect for compliance evidence.

[ElamOlame31]

You're right that Article 12 asks "what actually happened" — EPI's post-execution chain with Ed25519 + SCITT anchoring is the correct answer to that question.

But the two layers answer different regulatory questions. Pre-execution sealing proves the authorization decision existed before consequence — the evidence regulators use to answer "was this action approved, under which policy, at which point?" A post-execution record without a pre-execution commitment can be constructed retroactively. The combination is what makes the evidence chain unforgeable.

Full Annex IV compliance likely needs both: AgentGate seals the authorization receipt before execution fires, EPI seals the execution outcome after. Sequential layers of the same chain, not competing answers to the same question.

Would love your read on the pre-execution layer in practice: https://www.tryagentgate.com/playground

[mohdibrahimaiml]

@ElamOlame31 You're absolutely right, and I've confirmed it against the codebase.

EPI seals post-execution — steps are recorded during the run, the signature applied in exit after
completion. There's no pre-execution commitment mechanism. EPI answers "what actually happened," not
"was this approved before it happened."

Your architecture is sound: AgentGate seals the authorization decision before consequence, EPI seals
the execution outcome after. Sequential layers, not competing answers. The combination makes forgery
impossible in either direction.

@imran-siddique @musaabhasan — this clarifies what Annex IV should include:

1. Pre-execution authorization receipt (sealed before execution fires)
2. Post-execution evidence trail (sealed after execution completes)
3. Policy evaluation binding both layers

EPI's role is layer 2. That's where we fit in AGT's compliance architecture.

[chopmob-cloud]

The gap you're describing is exactly what compliance-receipt-v1 (IETF Internet-Draft, live on datatracker) addresses -- a portable, verifiable artefact a regulator can independently verify without trusting any runtime or intermediary.

The shape we landed on after production deployments:

Artefact structure:

• claim_type: compliance_receipt with a closed categorical enum (COMPLIANT / NON_COMPLIANT / PENDING_REVIEW)
• frame_id: SHA-256 over JCS RFC 8785 canonical preimage -- the content-addressable identity of the receipt, independent of transport
• receipt_hash: Ed25519 JWS over the JCS-canonical receipt body, using the issuer's published JWKS
• evidence_refs[]: references to the specific evidence sources the determination was grounded in (sanctions check, AML screen, KYC tier, settlement history)

What this gives a regulator:

1. Independent re-derivation: same frame_id from the same input bytes, regardless of who runs the canonicaliser
2. Independent signature verification: JWKS is public, verification is stateless -- no runtime required
3. 7-year retention: artefacts are anchored to B2 Object Lock (COMPLIANCE mode) so the operator cannot silently rewrite the history after the fact (UK MLR 2017 Reg 40(3))

The .epi format in mohdibrahimaiml's RFC is converging on the same shape. The load-bearing question is canonicalisation: if two independent implementations can produce byte-identical artefacts from the same input, the frame_id can be cited cross-system. That's the JCS RFC 8785 property -- the canonicaliser is deterministic, so the artefact is independently reproducible.

Companion IETF I-D draft-hopley-x402-settlement-attestation covers the post-settlement outcome side (SETTLED / PENDING_FINALITY / REVERSED) under the same canonicalisation pin. The two compose: compliance receipt covers "was this agent/payment eligible", settlement attestation covers "did the payment actually clear".

AlgoVoi (chopmob-cloud) -- Acquisition enquiries: https://docs.algovoi.co.uk/acquisition

[chopmob-cloud]

Started on the shared fixture and ran your canonical_hash_vectors.json through our RFC 8785 canonicaliser, the same one that generates our published conformance corpus, so these are independently recomputed values rather than a read of your file.

Canonical form, byte-for-byte. For all three vectors that publish a canonical_json (ManifestModel_basic, StepModel_source_type_excluded, Unicode_ensure_ascii), our canonical bytes are identical to yours, including the Müller non-ASCII case, key ordering and null handling. That is the hard part, and it agrees.

Hashes: five of the eight reconcile end-to-end, where our independent SHA-256 over the input equals your expected_hash (ManifestModel_basic, Unicode_ensure_ascii, Empty_file_manifest, Long_string_value, Minimal_manifest). Unicode_ensure_ascii is fully consistent: your expected_hash, our hash of the input, and SHA-256 of your own canonical_json are all 8b2a33c2..., so the ensure_ascii path is solid.

Three need a quick reconcile, and they look like two different things rather than a canonicalisation gap:

• StepModel_source_type_excluded is a column mismatch you can reproduce in one line: SHA-256 of your published canonical_json is 58ebce7439cb..., which is also what our independent hash of the input produces, but the listed expected_hash is d324120ef801.... The two columns are over different bytes. Which one is authoritative, so I seed the right value?
• Nested_deep_content and Empty_collections_in_step do not publish a canonical_json, so there is no canonical string on your side for me to hash, and I cannot reproduce their expected_hash independently. If you publish canonical_json for those two, I will reconcile them the same way.

On our side: the five that already reconcile I will seed into the conformance-vectors corpus now, in the {id, input, canonical_preimage_spec, frame_id, timestamp_encoding} shape so the frame_id is citable to draft-hopley-x402-canonicalisation-jcs-v1 rather than either repo's HEAD. The other three I will fold in once we agree which bytes their hash is over.

Net: canonicalisation agrees byte-for-byte everywhere it is checkable, verified independently on our side against the same canonicaliser behind our published corpus. The only open items are the authoritative column on StepModel_source_type_excluded, and a canonical_json for the two that omit it.

AlgoVoi (Christopher Hopley) -- Adopt the Substrate: github.com/chopmob-cloud

[mohdibrahimaiml]

@chopmob-cloud

Tracked it down.

The StepModel discrepancy was a legacy implementation bug rather than a canonicalization disagreement. StepModel has no spec_version field, so it was incorrectly falling through to the CBOR path, while the published specification, vectors, and interoperability documentation all treated StepModel as JCS-canonicalized JSON.

I've corrected the implementation, regenerated the affected vectors, and verified that SHA-256(canonical_json) == expected_hash for all 8 published vectors. The three StepModel-based vectors now reconcile against the same JSON/JCS preimage, and all vectors publish canonical_json so they can be independently reproduced and verified.

The docs, tests, and golden vectors have been updated and pushed.

Thanks again for running the corpus through an independent implementation and catching the inconsistency — that cross-check did exactly what a shared conformance fixture is supposed to do.

[chopmob-cloud]

@mohdibrahimaiml Confirmed the StepModel fix independently. I re-ran your updated tests/compatibility/golden/canonical_hash_vectors.json (byte-locked at sha256:78227cad...) through three independent RFC 8785 implementations, rfc8785 (Python), canonicalize (JS), and gowebpki/jcs (Go), and all 8 reconcile: canonical bytes byte-for-byte and SHA-256(canonical_json) == expected_hash, including the non-ASCII umlaut case. The CBOR-fallthrough diagnosis matches what we saw here, the 3 StepModel-based vectors were the only divergence.

The first batch is already live, so you can PR against it whenever you are ready. epi_interop_v0 (5 vectors) is in the corpus:
https://github.com/chopmob-cloud/algovoi-jcs-conformance-vectors/tree/main/vectors/epi_interop_v0

It carries the 5 that reconciled at seed time, each anchored_to draft-hopley-x402-canonicalisation-jcs-v1, with your source file SHA pinned. One framing note baked into the set: it is a 2-impl interop set (AlgoVoi + EPI), held in a separate interop_sets block and deliberately not folded into the 8-implementation conformance totals. The fixtures pin the JCS RFC 8785 + SHA-256 method over the literal input bytes; they are not substrate-timestamp-compliant (EPI ISO-8601 strings vs the substrate integer-millisecond rule), and each vector declares its timestamp_encoding so that boundary stays testable.

Now that the 3 StepModel-based vectors reconcile, the clean next step is to bring the set to the full 8. Either we fold StepModel_source_type_excluded, Nested_deep_content, and Empty_collections_in_step into an epi_interop_v0 update, or you carry them in your PR, whichever you prefer. Happy to take the update on our side if that is simpler.

[mohdibrahimaiml]

@chopmob-cloud

Perfect.

Since the remaining three vectors now reconcile and you've independently verified the updated corpus across multiple RFC 8785 implementations, I'm happy for you to fold them into epi_interop_v0 on your side.

The authoritative values are the updated JSON/JCS-derived hashes from the latest corpus, and all 8 vectors now satisfy SHA-256(canonical_json) == expected_hash.

Thanks again for the verification work and for setting up the shared fixture.

[chopmob-cloud]

Thanks for driving this.

One gap stands out for the long-term audit .epi is built for: artefacts are sealed with Ed25519. That's fine today, but evidence meant to stay verifiable for decades needs a signature -- and a key -- that survive the post-quantum migration.

Proposing a small, optional extension (the default doesn't change):

1. A post-quantum signature suite -- one more signature_suite: signature: "falcon1024:<kid>:<b64url-sig>" (Falcon-1024 over the JCS bytes of the manifest). Ed25519 stays the default; this is opt-in.

2. Key-lineage -- a cross-signed rotation block (old key authorises the new key, new key counter-signs) so a verifier can validate an artefact whose signing key was retired years earlier.

Published as a runnable fixture -- epi_pqc_v0: https://github.com/chopmob-cloud/algovoi-jcs-conformance-vectors/tree/main/vectors/epi_pqc_v0 (4 JCS canon vectors + a falcon1024 signature anchor + a 2-step key-lineage; standalone runner, rfc8785 + pqcrypto, zero other deps). Marked proposed / optional, kept out of the cross-validated totals.