EVIDE EAR
EVIDE has always preserved the original intake exactly as submitted - the canonical JSON record, hashed, timestamped, tamper-evident. That answers one question: what was declared, and when.
The canonical intake preserves what was submitted. The EAR separately projects that preserved material into a human-readable record, and also includes evidentiary states or signals subsequently computed by EVIDE, such as FCC, DWC, FAC and, where applicable, the state of an Epistemic Stabilization Buffer. Declared execution context, Evidence References and Declarations remain supplied components of the canonical intake - the EAR does not create or infer them.
The EAR provides a human-readable projection of that preserved state, together with evidentiary states subsequently derived by EVIDE.
The gap this closes is concrete, not theoretical: during end-to-end validation of MCP v1.4.0's expanded execution_identity, the field was confirmed present in the canonical payload and correctly rendered in the admin request view - but absent from the EAR. The EAR is generated by a separate service, reading the same canonical payload independently; a field can exist in one output and not yet be projected into the other. That specific gap is now closed - see Section 5 - and the same principle applies to anything preserved elsewhere in the record: the EAR is only ever a projection of it, never a separate source of truth.
Every intake now produces two artifacts, available for download from the same request view.
Neither replaces the other. The canonical JSON is the object of record for anything that reads or re-verifies the intake programmatically. The EAR is the object of record for a human reviewing what the evidentiary infrastructure represented at a specific point in time - readable without parsing JSON, and independently hash-verifiable in its own right.
Two automatic lifecycle triggers generate an EAR during normal operation. A third, exceptional administrative regeneration path creates a new version and requires an explicit reason.
| Trigger | When it fires |
|---|---|
| Intake finalized | The moment a decision record reaches its finalized status - the first EAR version for that request. |
| ESB reached final state | When an open Epistemic Stabilization Buffer closes (stable, unstable, or deferred) - a new EAR version, reflecting the buffer's settled state. |
| Admin regenerate | Exceptional, manual, admin-only - requires an explicit reason on every use. Not part of the normal automatic lifecycle. |
Once generated, a specific EAR version is preserved and tamper-evident: downloading it again always returns identical content and hash. If the canonical evidentiary state changes again - most commonly because an ESB that was open at intake time later closes - a new version is generated automatically. The previous version is never modified, never deleted, never regenerated in place.
The previous version is never edited.
This is what "tamper-evident" means for an EAR specifically: not that the underlying evidentiary state can never change - it can, deliberately, when an ESB settles - but that a given version, once published, cannot be altered without that alteration being detectable by comparison with the SHA-256 hash separately recorded by the platform for that EAR ID and version.
The EAR is composed of dynamically numbered sections. Which sections appear depends on the intake type and the evidentiary state available at generation time. The numbering adjusts automatically; there is never a gap or a duplicate number.
| Section | Preserves | Present when |
|---|---|---|
| Intake Detail | Title, request identifier, evidence type, intake channel, source system, intake hash | Always |
| Received Artifact | Original or materialized file name, file size, MIME type | A received file/artifact is associated with the intake |
| Structured Declaration | Declared decision type, declaring authority, decision closure time | STRUCTURED evidence type with a declared decision type present |
| Execution Identity | Declared agent, system, model, deployment, session, run, accountability model | execution_identity present with at least one meaningful field |
| Evidentiary Profile | Declared classification/threshold/boundary readiness, plus the inferred FCC / DWC / FAC signals | An evidentiary profile is available for the record |
| ESB - Epistemic Stabilization Buffer | Status, verdict, causal persistence, stability trend, continuity state, closure trigger | A buffer is associated with the intake |
| Evidence References | Each declared external artifact - type, pointer, declared origin, declared hash if provided - or an explicit statement that none were declared | STRUCTURED evidence type - the section itself always appears, showing declared artifacts or their explicit absence |
| Declarations (EVIDE ANCHOR) | Each declared perimeter statement - type, value, declarant, timestamp, attribution status - or an explicit statement that none were declared | STRUCTURED evidence type - the section itself always appears, showing declarations or their explicit absence |
Every field in every section follows the same rule already established for execution_identity and for Declarations: an optional value is printed only when it is actually present in the canonical payload. Absence is never filled with a placeholder, never inferred from a neighboring field, never derived from source_system or authority or anything else. A record missing a field shows a shorter section - never a fabricated one.
execution_identity, evidence_references, and declarations together in a single intake. Section numbering, field omission, and the boundary text all held correctly across every combination.
Every EAR is made available to the record owner together with its own SHA-256 hash, independently of the intake hash discussed inside it. Verification means computing the hash of the complete downloaded file, exactly as downloaded, and comparing it against the value recorded on the EVIDE platform for that specific EAR ID and version - never a hash value that may appear inside a copy of the file itself, only the one held independently by the platform. The EAR and its hash are not part of the public registry.
Intake hash (SHA-256) printed inside Section 1 belongs to the canonical intake payload. The EAR's own SHA-256, available alongside the download, belongs to the EAR document itself. Confirming one says nothing about the other - each is verified against its own recorded value.
This distinction matters enough to state plainly, not only to imply through wording elsewhere on this page.
An intake with fedis_requested: false - the default, and the case for every example on this page - has an EAR but no FEDIS document. The EAR is a preserved, tamper-evident summary produced by EVIDE itself. It is not, and does not claim to be, a certification in the sense FEDIS provides.
- Does not verify that any declared hash matches the artifact it describes - a hash inside Evidence References is anchored exactly as declared by the submitter
- Does not verify the identity, authenticity, provenance, or control of any agent, model, session, or run named in Execution Identity
- Does not enforce, apply, or check compliance with any declared operational perimeter in Declarations (EVIDE ANCHOR)
- Does not determine legal responsibility, fault, or compliance - the Evidentiary Profile's inferred signals describe how settled the declared conditions were, not whether the underlying decision was correct
- Does not substitute for FEDIS - see Section 7
- Does not exist as a source of truth independent of the canonical intake it summarizes - if the two ever appear to disagree, the canonical intake payload is authoritative
It does not verify, enforce, or determine.
The EAR does not compute these evidentiary mechanisms itself. It projects a human-readable summary from the canonical intake and from the evidentiary states available to the EAR generator at that specific point in time, including the states and signals produced by other EVIDE mechanisms.
| Mechanism | What it produces | Where it appears in the EAR |
|---|---|---|
| execution_identity | Declared execution context | Execution Identity section, when present |
| FCC / DWC / FAC | Inferred continuity signals | Evidentiary Profile section |
| evidence_references | Declared external artifacts | Evidence References section |
| EVIDE ANCHOR (declarations) | Declared operational perimeter | Declarations (EVIDE ANCHOR) section |
| Epistemic Stabilization Buffer | Settled state over an observation window | ESB section, when present - closure also triggers a new EAR version |
EVIDE MCP Server: MCP Server documentation
EVIDE ANCHOR: Declared operational perimeter
Forensic Cross-Check (FCC): Related evidentiary construct
Decision Wave Compression (DWC / FAC): Related evidentiary construct
EVIDE Intake Schema Documentation: Intake schema reference
EVIDE vs. Execution Certification: Architectural distinction
The original submission preserves what was declared.
The EAR provides a human-readable projection of that preserved state, together with evidentiary states subsequently derived by EVIDE.
Generated automatically. Never edited in place. Not a FEDIS certification.
"EVIDE preserves the original submission and separately provides a human-readable projection of it, together with the evidentiary states EVIDE subsequently derives."
Contact: info@certifywebcontent.com