EVIDE Minimum Intake JSON version 2.1 : universal boundary-ready schema

What is the structured JSON format

The JSON type allows you to deposit a structured decision object directly into the EVIDE External Evidentiary Deposit. Unlike FILE, ZIP, URL and TEXT, JSON is not generic content: it is a minimum contract between the system that produced the decision and the evidentiary layer that anchors it in time. The payload is canonicalised (keys sorted alphabetically, minified) and hashed deterministically before deposit.

Why a structured format

Any system - AI, business workflow, governance platform - produces decisions. These decisions often exist only as internal logs, difficult to extract and impossible to defend outside the system that produced them. The EVIDE Minimum Intake Schema solves this: it does not standardise the workflow, it standardises the object entering the evidentiary layer.

Versioning: public specification vs schema

The public specification version (v0.1) and the evide_schema field version in the payload (2.1) are two distinct things. The public specification describes the format and may evolve with new fields or clarifications. The evide_schema field identifies the data contract version: two systems speaking the same evide_schema are compatible regardless of the public documentation version.

Public specification

v0.1

Documentation and format

evide_schema field

"2.1"

Data contract in the payload

Earlier values (1.8, 1.9, 2.0) are historical and no longer accepted.

Schema fields

Field	Description	Status
evide_schema	EVIDE schema version. Must be "2.1" — the current and only value accepted by the API. Earlier values (1.8, 1.9, 2.0) are historical and no longer accepted; see the Schema Evolution section for what each one added.	Required
source_system	Name of the system that produced the decision. E.g. "Example Governance Systems Ltd", "HR_AI_Screening_v2".	Required
source_reference	Unique identifier of the decision in the source system. E.g. "CDR-2026-00421".	Required
source_timestamp_utc	UTC timestamp of when the decision was produced by the source system.	Required
decision .type .status .closure_timestamp_utc .summary	Object describing the decision: type, status, closure timestamp and summary. .type - Decision category. E.g. "candidate_evaluation", "policy_enforcement". .status - Final state. Use "finalized" for closed decisions. .closure_timestamp_utc - UTC closure timestamp of the decision. .summary - Short description in natural language.	Required
authority .id .role .verification	Authority that issued or validated the decision. .id - Authority identifier in the source system. .role - Authority role. E.g. "HR Reviewer", "DPO". .verification - Declared DAPI reference if the authority intends to link to a DAPI identity. Not validated server-side: generates "claimed" status, not "verified".	Required .verification Optional
intervention .type .rationale .trace.reference .trace.access	Describes the human intervention on the decision, if any. .type - Intervention type. E.g. "override", "approval", "rejection". .rationale - Rationale of the intervention in natural language. .trace - Reference to the log or audit trail of the source system.	Optional
human_oversight .is_declared .declared_level	Explicit declaration of human oversight. EVIDE does not verify: it records the declaration. .is_declared - true if human oversight has been declared. .declared_level - HOE level: L1 (Declarative), L2 (Verifiable), L3 (Forensic).	Optional
chain .parent_evide_id .chain_type	Links this intake to a previous one, forming a verifiable evidentiary chain. Validation is strict — see the Evidentiary Continuity section below. Null for the first deposit.	Optional

Schema evolution — v1.1 Historical · v1.1

Field	Description	Status
created_at_utc	UTC timestamp of EVIDE package creation. Separate from source_timestamp_utc: data may originate earlier and be deposited later.	Optional
object_class	Class of the deposited object. Allows distinguishing different types without changing the core schema. Suggested values: decision_record, review_record, risk_assessment, policy_exception. Suggested values: `decision_record` · `review_record` · `compliance_event` · `oversight_event`	Optional
content_hash .algorithm .value	Hash of the canonicalised payload, declared within the record itself. Makes the record autonomous and verifiable outside the platform.	Optional

Schema evolution — v1.2 Historical · v1.2

Field	Description	Status
intervention .rationale_type	Classifies the type of rationale without replacing free text. Allows categorization, search, and comparison across records without compressing the interpretive content. Suggested values: `misclassification_correction` · `policy_override` · `human_judgment` · `context_correction`	Optional

Schema evolution — v1.3 Historical · v1.3

Classification Replay (Deterministic Audit Context)

Each EVIDE record references the exact taxonomy version that was valid at the moment of recording. Under audit, a decision can be re-examined not only for its content, but against the exact classification context in which it was originally produced.

Field	Description	Status
intervention .taxonomy_version	Version of the taxonomy used for the rationale_type field. Enables classification replay under audit conditions. Example: "rationale-types-v1.0"	Optional

Schema evolution — v1.4 Historical · v1.4

FEDIS on request

The fedis_requested field indicates whether the EVIDE deposit should be accompanied by FEDIS - Forensic Evidence Declaration and Integrity Statement. If true, the record enters manual processing for the production of the signed forensic declaration. Default: false.

Field	Description	Status
fedis_requested	Request for FEDIS production alongside the deposit. If true, the record is taken in charge for manual forensic processing. Values: true \| false. Default: false.	Optional

Schema evolution — v1.5 — Computed response attributes Historical · v1.5

Authority Verification Status

From version 1.5, the system automatically computes the authority_verification_status field and returns it in the API response. This field formalises the distinction between an authority that has declared a DAPI code and one that has provided no verifiable reference. The field is computed server-side: it is not part of the payload sent by the client.

⚠ This is not a payload field. It is a server-computed response attribute - not part of the submitted JSON.

Version 1.5 extends the intake contract by adding a computed server-side authority verification status to the response, without changing the minimum deposited payload.

Field	Description	Status
authority_verification_status → claimed → declared	Field computed by the system based on the presence or absence of authority.verification in the submitted payload. `claimed` - The authority has declared a DAPI code (authority.verification present and non-empty). The code is not validated server-side: the declaration is recorded but not verified. `declared` - The authority has not provided any DAPI reference. The identity is only declared in the authority.id field. The third state `verified` will be available in future, when real validation against the DAPI registry is implemented. The architectural distinction between declared, claimed and verified is already part of the EVIDE model.	Field returned in the API response

API Response Example - evidentiary_profile

{
  "success": true,
  "evide_id": "2e3a79f7-2011-410f-8c6e-be4b29da1d79",
  "intake_hash": "b268b8a7cff89024a1add61e2abb...",
  "intake_timestamp_utc": "2026-04-16T07:06:24+00:00",
  "schema_version": "2.1",
  "fedis_requested": false,
  "evidentiary_profile": {             // server-computed
    "profile_version": "1.1",
    "identity": "claimed",               // from authority.verification presence
    "authority": "declared",             // from authority.id + authority.role
    "classification": "stable",         // from intervention.classification_status
    "threshold": "met",                  // from classification_context.threshold_status
    "threshold_authority": "attributed", // from threshold_authority.attribution_status
    "boundary_readiness": "verified_partial", // from handoff.boundary_readiness.status
    "runtime_visibility": "partial",    // from handoff.boundary_readiness.visibility_surface
    "trace_reference": "restricted",    // from intervention.trace.access
    "continuity": {                    // Forensic Cross-Check — inferred
      "mode": "inferred",
      "state": "degraded",              // stable + partial visibility → degraded
      "derivation": "classification_x_runtime_visibility",
      "function": "forensic_cross_check"
    },
    "decision_wave_compression": {     // DWC — inferred server-side
      "mode": "inferred",
      "state": "detected",              // not_detected | detected | critical | unknown
      "function": "decision_wave_compression"
    },
    "formal_accountability_collapse": { // FAC — inferred server-side
      "mode": "inferred",
      "state": "detected",          // continuity degraded → detected, not not_detected
      "function": "formal_accountability_collapse"
    }
  },
  "handoff": {                            // operational boundary confirmation
    "submission_status": "submitted",    // updated by EVIDE
    "acceptance_status": "accepted"      // updated by EVIDE
  },
  "fedis_status": null,
  "status": "RICEVUTA"
}

→ evidentiary_profile is computed server-side from the payload — it is not part of the submitted JSON and is not included in the canonical hash.
→ profile_version evolves independently from evide_schema. Dim 9 is inferred via Forensic Cross-Check (classification × runtime_visibility) and expresses the structural coherence of a single closure — exposed under the historical API field name continuity, unrelated to Evidentiary Continuity across a chain (see note below). Dim 10 (decision_wave_compression / DWC) inferred: runtime_visibility × boundary_readiness × unresolved_signals. Dim 11 (formal_accountability_collapse / FAC) inferred: authority × threshold_attribution × continuity. States for dim 10-11: not_detected | detected | critical | unknown.

Schema evolution — v1.6 Historical · v1.6

Classification Status - Operational stability of the classification

The classification_status field allows declaring the stability state of the classification assigned at the time of deposit. It does not describe the psychological confidence of the reviewer, but the structural state of the classification in the operational context: whether it is consolidated, provisional, or contested. The field is optional but recommended when the classification is not final.

Field	Description	Status
intervention .classification_status → stable → provisional → contested	Stability state of the classification assigned in intervention.rationale_type. `stable` - Category assigned with no known ambiguity under the active taxonomy. `provisional` - Category assigned provisionally or pending refinement. `contested` - Category assigned despite known interpretive disagreement or overlap with other categories. If absent, the system assumes no default state. The field makes the operational quality of the classification observable at the time of deposit.	Optional

Schema evolution — v1.7 Historical · v1.7

Classification Context

Optional nested object inside intervention that makes visible whether the classificatory act relied on an upstream taxonomy and threshold structure at the moment of recording. It does not validate the threshold itself. It exposes whether such a structure existed and whether the classification was recorded as having met it.

v1.7 does not introduce admissibility logic into EVIDE.
It introduces visibility of whether admissibility had a structure upstream.

Field	Description	Status
intervention .classification_context .taxonomy_reference .threshold_reference .threshold_status	Optional nested object that exposes the upstream classification context at the moment of deposit. .taxonomy_reference - Reference to the taxonomy source used at the time of classification. May be omitted if the version is already identified via taxonomy_version. .threshold_reference - Reference to the upstream rule, threshold, or admissibility condition used by the originating system. .threshold_status - Status of the classificatory threshold at the moment of recording. All subfields are optional, but coherent when present. threshold_reference should be omitted if threshold_status is not_defined. threshold_status values: `met` · `not_met` · `unknown` · `not_defined`	Optional

Schema evolution — v1.8 Historical · v1.8

Threshold Ownership — Attribution Status

The threshold_authority field is an optional object nested inside classification_context. It does not define who should own a threshold: it exposes whether the threshold had a structurally attributable source of authority at the moment of closure. The distinction between absence of threshold (threshold_status: not_defined) and a threshold that exists but has fragmented ownership (attribution_status: fragmented) was previously not observable. v1.8 makes it persistent in the record.

v1.8 does not define who should own a threshold.
It makes visible whether the threshold itself had a structurally attributable source of authority at closure.

Field	Description	Status
intervention .classification_context .threshold_authority .source .attribution_status	Optional object that exposes the attributability state of the authority governing the threshold at the moment of deposit. .source - Declared source of authority over the threshold. E.g. "HR Policy Committee", "AI Governance Board". .attribution_status - Attributability state of the threshold authority at the moment of closure. The field is optional. It becomes relevant when threshold_status is met or not_met but the ownership of the threshold is not clearly attributable to a single source. attribution_status values: `attributed` · `fragmented` · `implicit` · `unknown` `attributed` - single identifiable and attributable authority defined at closure `fragmented` - threshold defined across multiple sources, no single attributable authority `implicit` - threshold present in practice but not formally defined or attributable `unknown` - threshold authority not verifiable at the moment of closure	Optional

Schema evolution — v1.9 Historical · v1.9

Boundary-Ready Schema - Universal Handoff Contract

v1.9 introduces the handoff section: an optional block that makes the boundary state of an object explicit before external anchoring. It translates implementation-specific readiness concepts (such as execution readiness gates) into a universal, system-agnostic vocabulary.

v1.9 does not introduce a new anchoring mechanism.
It makes the pre-anchoring state of an object explicitly observable and universally interpretable.

Field	Description	Status
handoff .boundary_readiness → candidate → verified → not_assessed (deprecated)	Declares the readiness state of the object at the boundary before submission to EVIDE for external anchoring. `candidate` - upstream system declares the object is closed and prepared for boundary review, but it has not yet been independently accepted by EVIDE. `verified` - a boundary-readiness gate (any upstream or independent mechanism) has confirmed the object is suitable for submission. `not_assessed` - legacy v1.9 transitional state. Deprecated in v2.0. In v2.0 use `candidate` instead: it is the structurally honest state for objects that have not passed independent readiness verification. If `boundary_readiness = "verified"`, the resulting evidentiary strength is higher than `"candidate"`, because readiness has already been confirmed by an upstream or independent gate before submission. Important: `"verified"` cannot be self-certified by the upstream system. It requires confirmation by an independent boundary readiness gate, a mechanism external to the system that produced the decision, that the following conditions were true at boundary crossing: runtime conditions that grounded the closure state were stable; rollback viability was not in active degradation; downstream propagation had not altered the reversibility of the decision; replay integrity of the classification context was preserved. If any of these conditions cannot be confirmed by an independent gate, use `"candidate"`. `"candidate"` is not a weaker state, it is the honest state for objects that have not passed independent readiness verification.	optional
handoff .reconstruction_independence → declared → not_declared	Upstream declaration that no downstream step should require reconstruction of intent from audit logs, human memory, or system-specific context. `declared` - upstream explicitly declares that the object is self-contained and reconstruction-independent. `not_declared` - no declaration was made. The object does not satisfy the zero-dependency enforcement constraint and should not be submitted for L3 anchoring. This is a declarative field received by EVIDE from the upstream system. EVIDE does not compute or verify it.	optional
handoff .submission_status → not_submitted → submitted	Declares the submission state of the object from the upstream side. `not_submitted` - correct initial upstream state. The object has not yet been submitted to EVIDE for external anchoring. `submitted` - the object has been sent to EVIDE. Transitions to this value are managed by the upstream system at the moment of submission.	optional
handoff .acceptance_status → not_claimed → pending → accepted → rejected	Declares the acceptance state from the EVIDE side. Updated by EVIDE after processing. `not_claimed` - correct pre-EVIDE state. No acceptance has been claimed or processed. `pending` - EVIDE has received the object and is processing it. `accepted` - EVIDE has accepted the object for external anchoring. `rejected` - EVIDE has rejected the object. The upstream system must resolve the identified condition before resubmission.	optional

Valid state combinations

The following table defines which combinations of submission_status and acceptance_status are structurally valid.
Invalid combinations indicate a malformed object and must not be submitted to EVIDE.

submission_status	acceptance_status	Valid	Meaning
`not_submitted`	`not_claimed`	✓	Correct initial upstream state. Object is ready but not yet sent.
`submitted`	`pending`	✓	Object has been sent. EVIDE is processing.
`submitted`	`accepted`	✓	EVIDE has accepted the object for external anchoring.
`submitted`	`rejected`	✓	EVIDE has rejected the object. Upstream must resolve and resubmit.
`not_submitted`	`pending / accepted / rejected`	✗	Impossible. An object cannot have an EVIDE acceptance state before being submitted.
`submitted`	`not_claimed`	✗	Contradictory. A submitted object must have a declared acceptance state.

EVIDE intake contract - well-formed handoff package (v1.9)

From the EVIDE side, a well-formed handoff package requires all of the following conditions to be satisfied before the object is accepted for external anchoring:

decision.status = "finalized"
authority.id        → present and non-null
authority.role      → present and non-null
intervention.classification_context → present

handoff.boundary_readiness          = "candidate" or "verified"
handoff.reconstruction_independence = "declared"
handoff.submission_status           = "not_submitted"
handoff.acceptance_status           = "not_claimed"

content_hash.algorithm = "SHA-256"
content_hash.value     → present

EVIDE does not require raw logs, full execution traces, or system-internal reconstruction material.

EVIDE accepts a closed, attributable, structurally complete, reconstruction-independent candidate for external anchoring.

If boundary_readiness = "verified", the resulting evidentiary strength is higher than an object submitted only as "candidate", because readiness has already been confirmed by an upstream or independent readiness gate before submission to EVIDE.

Note: The handoff object is optional at schema level. When evide_schema = "1.9", the entire handoff block and all four sub-fields are required by the intake API. In v2.0, boundary_readiness becomes a structured object - see v2.0 section below.

Architectural rationale: Boundary Readiness and evidentiary interpretation are documented in the Architecture Guide.

Schema evolution — v2.0 Historical · v2.0

boundary_readiness Quality Layer — Gate Qualification Framework

v2.0 promotes boundary_readiness from a string to a structured object. The single structural change introduces four canonical states with declared gate identity, visibility surface, and unresolved signals — making the evidentiary quality of the boundary explicitly observable, not just its existence.

"2.1" is the current and only evide_schema value accepted by the API. Earlier values (1.8, 1.9, 2.0) are historical and no longer accepted — see the v2.1 sections below for what changed since.

Field	Description	Status
handoff .boundary_readiness .status	Replaces the v1.9 string value. Declares the evidentiary quality of the boundary assessment. `candidate` - no independent gate has assessed the object. Upstream declares readiness only. `verified` - gate confirmed stability across declared_complete visibility. No unresolved signals. `verified_partial` - gate confirmed what it could see. Unresolved signals declared explicitly. `unverifiable` - gate attempted assessment but visibility was insufficient. Proves diligence, not failure.	required
handoff .boundary_readiness .readiness_gate .identifier .scope_reference	Identifies the system or mechanism that performed the boundary readiness assessment. .identifier - name or ID of the gate system. Required when status ≠ `candidate`. .scope_reference - URL or hash of the gate policy document. Makes `verified` non-self-referential. null when status = `candidate`.	conditional
handoff .boundary_readiness .visibility_surface	Categorical declaration of the gate's observational coverage at assessment time. `null` - no gate operated (candidate). `partial` - gate saw part of the relevant runtime surface. `declared_complete` - gate declares completeness within its scope. Not omniscience. `insufficient` - surface was below minimum viable threshold for any stability claim.	conditional
handoff .boundary_readiness .unresolved_signals	Array of signal identifiers that the gate could not resolve at assessment time. Empty array `[]` when status = `candidate` or `verified`. Minimum one element required when status = `verified_partial` or `unverifiable`. String array in v2.0. Structured signal objects deferred to v2.x.	conditional

Valid state combinations (v2.0)

The submission_status and acceptance_status combinations remain identical to v1.9. The table below defines the valid and invalid combinations specific to the v2.0 boundary_readiness object.

Invalid combinations indicate a malformed object and must not be submitted to EVIDE.
Note: verified cannot be self-certified — readiness_gate.identifier must always reference a gate external to the system that produced the decision.

status	readiness_gate	visibility_surface	unresolved_signals	Valid	Reason
`candidate`	null	null	`[]`	✓	No gate has operated. Upstream declaration only.
`verified`	present	`declared_complete`	`[]`	✓	Gate confirmed stability. Complete visibility. No gaps.
`verified_partial`	present	`partial`	`[min. 1]`	✓	Gate confirmed partial surface. Gaps declared explicitly.
`unverifiable`	present	`insufficient`	`[min. 1]`	✓	Gate operated but surface was below minimum threshold.
`candidate`	present	any	any	✗	Contradictory. If a gate operated, status cannot be candidate.
`verified`	null	any	any	✗	Self-certification. verified requires an independent external gate.
`verified`	present	any	`[min. 1]`	✗	verified cannot have unresolved signals. Use verified_partial.
`verified_partial`	present	any	`[]`	✗	verified_partial requires at least one unresolved signal declared.
`unverifiable`	present	any	`[]`	✗	unverifiable requires at least one unresolved signal declared.

EVIDE intake contract — well-formed handoff package (v2.0)

In v2.0, the intake contract extends the v1.9 conditions with the structured boundary_readiness object. All v1.9 conditions remain valid. The only structural change is the promotion of boundary_readiness from a string to an object.

decision.status = "finalized"
authority.id        → present and non-null
authority.role      → present and non-null
intervention.classification_context → present

handoff.boundary_readiness.status          = "candidate" | "verified" | "verified_partial" | "unverifiable"
handoff.boundary_readiness.readiness_gate  → present when status ≠ "candidate"
handoff.reconstruction_independence        = "declared"
handoff.submission_status                  = "not_submitted"
handoff.acceptance_status                  = "not_claimed"

content_hash.algorithm = "SHA-256"
content_hash.value     → present

EVIDE does not require raw logs, full execution traces, or system-internal reconstruction material.

EVIDE accepts a closed, attributable, structurally complete, reconstruction-independent candidate for external anchoring.

In v2.0, evidentiary strength is now explicitly layered: verified with declared_complete visibility carries the highest strength. verified_partial carries strength proportional to the declared scope minus unresolved signals. unverifiable carries no boundary stability claim but carries a diligence record. candidate carries only the upstream declaration.

Architectural rationale: Boundary Readiness and evidentiary interpretation are documented in the Architecture Guide.

Evidentiary Object Profile (v2.0 response)

EVIDE does not reduce an evidentiary object to a single validity state.
It exposes the known, partial, degraded, or unverifiable dimensions of that object at the moment of deposit.

The evidentiary_profile is server-computed from the intake payload and returned in the API response. It is not part of the submitted JSON and is not included in the canonical hash. Each dimension maps to a specific source field in the payload.

Dimension	Question	Source field	Possible states
`identity`	Who is linked to the record?	`authority.verification` presence	`claimed` · `declared`
`authority`	Who assumes decision responsibility?	`authority.id` + `authority.role`	`declared` · `null`
`classification`	Is the classification stable?	`intervention.classification_status`	`stable` · `provisional` · `contested`
`threshold`	Was a decision threshold defined?	`classification_context.threshold_status`	`met` · `not_met` · `unknown` · `not_defined`
`threshold_authority`	Who owns the threshold?	`threshold_authority.attribution_status`	`attributed` · `fragmented` · `implicit` · `unknown`
`boundary_readiness`	Was the object stable at crossing?	`handoff.boundary_readiness.status`	`candidate` · `verified` · `verified_partial` · `unverifiable`
`runtime_visibility`	Was the runtime condition observable? Server-computed normalization of `visibility_surface`. Values are mapped as shown in the next column.	`handoff.boundary_readiness.visibility_surface` `declared_complete` → `confirmed` `partial` → `partial` `insufficient` → `unverifiable` `null` → `null`	`confirmed` · `partial` · `unverifiable` · `null`
`trace_reference`	Can the upstream trace be located?	`intervention.trace.access`	`available` · `restricted` · `unavailable`
`continuity`	Does the declared observational visibility structurally support the classification?	`classification` × `runtime_visibility` Forensic Cross-Check — inferred server-side	`{mode: inferred,` `state: stable\|degraded\|broken\|unknown}`
Terminology note. `continuity` is the historical API field name for the FCC-derived state above. It refers to structural coherence within a single closure and must not be confused with Evidentiary Continuity (see the v2.1 section below), which concerns declared continuity across chained records. The field name is not changed by this note — only the documentation.
`decision_wave_compression`	Is oversight throughput exceeded?	`runtime_visibility` × `boundary_readiness` × `unresolved_signals` DWC — inferred server-side	`not_detected` · `detected` · `critical` · `unknown`
`formal_accountability_collapse`	Is accountability attributable?	`authority` × `threshold_attribution` × `continuity` FAC — inferred server-side	`not_detected` · `detected` · `critical` · `unknown`

Full example v2.1

{
  "evide_schema": "2.1",
  "created_at_utc": "2026-04-07T09:15:05Z",
  "object_class": "decision_record",

  "source_system": "Example Governance Systems Ltd",
  "source_reference": "CDR-2026-00421",
  "source_timestamp_utc": "2026-04-07T09:15:00Z",

  "decision": {
    "type": "candidate_evaluation",
    "status": "finalized",
    "closure_timestamp_utc": "2026-04-07T09:15:00Z",
    "summary": "AI recommendation overridden by human authority"
  },

  "authority": {
    "id": "user_87421",
    "role": "HR Reviewer",
    "verification": "DAPI-XXXX"
  },

  "intervention": {
    "type": "override",
    "rationale_type": "misclassification_correction",
    "taxonomy_version": "rationale-types-v1.0",
    "classification_status": "stable",
    "classification_context": {
      "taxonomy_reference": "https://example.org/taxonomies/rationale-types-v1.0",
      "threshold_reference": "https://example.org/rules/hr-review-threshold-v1",
      "threshold_status": "met",
      "threshold_authority": {
        "source": "HR Policy Committee",
        "attribution_status": "attributed"
      }
    },
    "rationale": "AI misinterpreted parental leave as employment gap",
    "trace": {
      "reference": "AUDIT_LOG_998721",
      "access": "restricted"
    }
  },

  "fedis_requested": false,

  "human_oversight": {
    "is_declared": true,
    "declared_level": "L2"
  },

  "chain": {
    "parent_evide_id": null,
    "chain_type": null,
    "matter_reference": null
  },

  "handoff": {
    "boundary_readiness": {                        // structured object
      "status": "verified_partial",              // candidate | verified | verified_partial | unverifiable
      "readiness_gate": {
        "identifier": "GateSystem-v1.2",
        "scope_reference": "https://example.org/gate-policy/boundary-v1"
      },
      "visibility_surface": "partial",           // null | partial | declared_complete | insufficient
      "unresolved_signals": ["downstream_propagation_state"]
    },
    "reconstruction_independence": "declared",
    "submission_status": "not_submitted",
    "acceptance_status": "not_claimed"
  },

  "content_hash": {
    "algorithm": "SHA-256",
    "value": "a3f1c2...digest computed on payload without this field"
  }
}

Full architectural backlog and canonical states: app.certifywebcontent.com/docs/evide-v2-roadmap/

New in v2.1 v2.1

Evidence References — Declared External Artifacts

v2.1 introduces the evidence_references array: an optional list of declared pointers to external artifacts (screenshots, documents, video, audio, sensor data...) associated with the record. EVIDE anchors the declaration of an artifact's existence — never the artifact itself.

v2.1 does not receive, store, or validate the referenced artifact.
It anchors a declaration — with an optional hash for downstream verification.

Field	Description	Status
extensions	Array of declared payload extensions. Biconditional with each extension's content: an extension with non-empty content must be listed here, and a listed extension must have non-empty content. Known extensions in v2.1: `evidence_references`, `declarations`.	conditional
evidence_references .artifact_type .pointer .declared_origin .declared_relationship .declared_description .declared_retention_status	Array of declared external artifact references. Each entry describes one artifact without transmitting it. .artifact_type — free-text declared type (e.g. `screenshot`, `pdf`, `video`, `sensor_log`). Not an enum: EVIDE does not constrain or interpret its vocabulary. .pointer — implementation-specific reference to the artifact. May not represent a file path or URL; EVIDE does not resolve, dereference, or validate it. .declared_origin — free-text description of where the artifact came from. .declared_relationship — free-text description of how the artifact relates to this record. .declared_description — free-text human-readable description. .declared_retention_status — `persistent_storage` · `rolling_buffer` · `unknown`. Every field in this array is individually optional. An entry with no fields at all is structurally valid but carries no information.	optional
evidence_references .hash.algorithm .hash.value .hash_scope .hashed_by	Optional integrity anchor for the referenced artifact, computed upstream by the declaring system — never by EVIDE. .hash.algorithm / .hash.value — the computed digest. Required together when `hash` is present. .hash_scope — `full_file` · `segment` · `frame` · `archive`. Required when `hash` is present. .hashed_by — free-text identification of who or what computed the hash. Required when `hash` is present. If `hash` is present, `algorithm`, `value`, `hash_scope`, and `hashed_by` all become required together — a partial hash declaration is rejected.	conditional

Example — declaring a screenshot with hash

"extensions": ["evidence_references"],
"evidence_references": [
  {
    "artifact_type": "screenshot",
    "pointer": "local://test/screenshot.png",
    "declared_origin": "manual test upload",
    "declared_description": "Desktop screenshot supporting the recorded decision",
    "hash": {
      "algorithm": "SHA-256",
      "value": "da710047d3070d6ebf517d59423e43801e2b304e1b5d8aa151b99b37c33b3ece"
    },
    "hash_scope": "full_file",
    "hashed_by": "PowerShell Get-FileHash"
  }
]

EVIDE does not receive, store, or validate the referenced artifact — only the declaration, and optionally its hash.

The hash, when present, is declared by the submitter and never independently verified by EVIDE. A downstream party holding the actual artifact can use it to check the artifact matches what was declared at intake time.

New in v2.1 v2.1 — Evidentiary Continuity

chain.matter_reference — Matter Compatibility

v2.1 completes the chain object — present in the base schema since v1.0 — with matter_reference, and makes chain continuation validation strict and server-side: the parent must exist, belong to the same evidentiary domain, be in an accepted status, and — when declared on both sides — match the matter reference. There is no silent fallback: an invalid continuation fails the request rather than silently starting a new chain.

v2.1 does not merge unrelated matters, and does not let a continuation succeed silently when the parent reference is wrong.
It anchors an explicit, validated relationship between two independently certified records.

Field	Description	Status
chain.parent_evide_id	EVIDE ID of the previous record in the chain. Must reference an existing record, in the same evidentiary domain, in an accepted status. An invalid reference fails the request — there is no silent fallback to a new chain. Null for the first deposit in a chain (the root).	conditional
chain.chain_type	Free text describing the nature of the continuation (e.g. `litigation_hold`, `internal_investigation`, `incident_response`). No fixed enum.	optional
chain.matter_reference	Identifies the underlying matter the chain belongs to, independently of chain_type. If declared on both sides of a continuation, it must match exactly — a mismatch fails the request. If omitted, it is inherited automatically from the parent record, so the safeguard against mixing unrelated matters stays active across the whole chain without repeating it at every step.	optional

Example — opening and continuing a chain

// First intake in a matter — no parent, chain starts here
"chain": {
  "parent_evide_id": null,
  "chain_type": "litigation_hold",
  "matter_reference": "CLIENT-2026-0417"
}

// Second intake — continues the chain above
"chain": {
  "parent_evide_id": "b39d0270-c894-4598-9dd4-c272341b544e",
  "chain_type": "litigation_hold",
  "matter_reference": "CLIENT-2026-0417"
}

// Response — the resolved chain state
"chain": {
  "chain_position": 2,
  "chain_type": "litigation_hold",
  "chain_root_evide_id": "b39d0270-c894-4598-9dd4-c272341b544e"
}

The chain relationship is resolved server-side, after successful validation — the client declares, EVIDE decides. Once created, a chain relationship is immutable: it cannot later be rewritten to point at a different parent.

Full architectural rationale and typical use cases: app.certifywebcontent.com/docs/evide-evidentiary-continuity/

New in v2.1 v2.1 — EVIDE ANCHOR

declarations — Operational Perimeter Declarations

EVIDE ANCHOR lets a record preserve explicit, attributable, time-bound statements of the operational perimeter (environment, privileges, purpose, tools, prohibited operations, agent configuration) an agent was authorized within, before it acted. EVIDE preserves the declaration only — it never verifies its correctness, applies it as policy, or compares it against observed behavior.

A declared perimeter is not a permission granted by EVIDE, and its absence does not mean the agent was unauthorized.
It anchors what was stated, by whom, and when — never what was true.

Field	Description	Status
declarations[].declaration_type	Free text describing the nature of the declaration (e.g. `environment_classification`, `privilege_scope`, `declared_purpose`, `tool_availability`, `prohibited_operations`, `agent_configuration`). No fixed enum.	required
declarations[].declared_value	The content of the declaration — e.g. `"production"` for an `environment_classification`.	required
declarations[].declarant	Who made this specific declaration. Not necessarily the same identity as `authority.id` on the record.	required
declarations[].declared_at	ISO 8601 timestamp of when this declaration was made — distinct from `intake_timestamp_utc`, the server-side fact of when EVIDE received it.	required
declarations[].declared_description	Optional free-text elaboration.	optional
declarations[].authority_source.declared_attribution_status	Whether the authority behind this declaration is clearly attributed — `attributed`, `fragmented`, `implicit`, or `unknown`. Same status vocabulary as `threshold_authority` elsewhere in this schema.	optional
declarations[].authority_source.references[]	Array of `Reference` objects — what legitimizes the declarant's authority to make this declaration (e.g. a policy document, an internal role assignment). Each `Reference` carries `reference_type`, `declared_reference_relationship`, `pointer`, and an optional hash — see the Reference structure below.	optional
declarations[].subject_references[]	Array of `Reference` objects — what substantiates the declared content itself (e.g. a manifest, the target system the declaration is about). Same `Reference` structure, same optional hash, as `authority_source.references[]` above.	optional
declarations[].declared_relations[]	Array of `{ target_declaration_digest, declared_relationship, declared_reason }` — lets a later Declaration state that it supersedes, clarifies, or revokes an earlier one, identified by its `declaration_digest`, never by an `evide_id`. `declared_relationship` is free text (e.g. `supersedes`, `clarifies`, `revokes`).	optional

The Reference structure — and where a hash is optionally declared

Both authority_source.references[] and subject_references[] use the same Reference shape — the same pattern already used for evidence_references elsewhere in this schema. This is where a Declaration can optionally carry an integrity hash: not on the Declaration itself, but on a specific document or system it cites.

Field	Description	Status
reference_type	Free text — e.g. `policy_document`, `manifest`, `prompt`, `target_system`.	required
declared_reference_relationship	Free text describing why this reference is cited — e.g. `authorizes`, `describes`, `restricts`.	required
pointer	Where the referenced document or system lives. For a `target_system`, a standard identifier (e.g. `urn:sys:...`) is recommended over a free-form string.	required
hash.algorithm / hash.value	Optional. `algorithm` is free text — not restricted to SHA-256, unlike EVIDE's own `intake_hash`. Declared by the submitter and never independently verified or recomputed by EVIDE.	optional
hash_scope	What the hash covers — required if `hash` is present.	conditional
hashed_by	Who computed the digest. Required if `hash` is present — a digest EVIDE does not verify is worth only as much as its stated provenance.	conditional

Example — declaring an operational perimeter

// Request
"extensions": ["declarations"],
"declarations": [
  {
    "declaration_type": "environment_classification",
    "declared_value": "production",
    "declarant": "devops-lead",
    "declared_at": "2026-08-03T16:30:00Z",
    "authority_source": {
      "declared_attribution_status": "attributed"
    }
  }
]

// Response — the digest EVIDE computes server-side
"declarations": [
  {
    "declaration_type": "environment_classification",
    "declared_value": "production",
    "declarant": "devops-lead",
    "declared_at": "2026-08-03T16:30:00Z",
    "authority_source": {
      "declared_attribution_status": "attributed"
    },
    "declaration_digest": "845b279030aa739d31c9fbc9dbfd623f58f2d3aeb01a3d1a01041e26c43bbca9"
  }
]

declaration_digest is never sent by the client — it is computed by EVIDE over the canonical form of the single declaration and returned in the response. It is the digest, not the record's evide_id, that a later declaration would reference to state that it supersedes, clarifies, or revokes this one.

Example — a declaration citing a hashed reference

Here the declarant's authority is substantiated by a policy document, cited with a declared integrity hash — the same optional pattern available on subject_references[].

// Request
"extensions": ["declarations"],
"declarations": [
  {
    "declaration_type": "privilege_scope",
    "declared_value": "read-only, no automatic rejection above regulatory threshold",
    "declarant": "compliance-lead",
    "declared_at": "2026-08-04T09:00:00Z",
    "authority_source": {
      "declared_attribution_status": "attributed",
      "references": [
        {
          "reference_type": "policy_document",
          "declared_reference_relationship": "authorizes",
          "pointer": "https://example.org/policies/credit-approval-policy-v1.4",
          "hash": {
            "algorithm": "SHA-256",
            "value": "sha256:c481f0...2a67_example_not_for_submission"
          },
          "hash_scope": "full_file",
          "hashed_by": "policy management system"
        }
      ]
    }
  }
]

The hash sits on the reference, not on the Declaration — it anchors the declared integrity of the cited policy document, exactly as evidence_references does for external artifacts. EVIDE never computes or independently verifies it.

Combining evidence_references and declarations

The two extensions are independent and can be declared together in the same intake — an external artifact anchored alongside the operational perimeter that was in effect when it was produced.

// Request — both extensions declared together
"extensions": ["evidence_references", "declarations"],
"evidence_references": [
  {
    "artifact_type": "document",
    "pointer": "s3://compliance-logs/comp-0198/audit.log",
    "declared_origin": "internal audit system",
    "hash_algorithm": "sha256",
    "hash_value": "7d2e9f4a1c8b3e6f05a2d4c9e8f1023bc5d8e7f0123456bcdef789012345678a",
    "hash_scope": "full_file",
    "hashed_by": "internal audit system"
  }
],
"declarations": [
  {
    "declaration_type": "environment_classification",
    "declared_value": "staging",
    "declarant": "compliance-lead",
    "declared_at": "2026-08-03T17:00:00Z"
  },
  {
    "declaration_type": "privilege_scope",
    "declared_value": "read_only",
    "declarant": "compliance-lead",
    "declared_at": "2026-08-03T17:00:00Z"
  }
]

Note the two separate Declaration objects above — environment and privilege scope kept apart, not merged into one composite declaration, consistent with the Atomic Declaration Rule.

Canonicalisation and hashing

Before computing the SHA-256 hash, the system canonicalises the JSON: it sorts keys alphabetically at all levels and minifies the result (no spaces, no newlines). This ensures that two identical payloads always produce the same hash, regardless of the order in which fields were entered. The canonicalised file is saved and made available for download with the FEDIS certification package.

Implementation note: the content_hash field must be computed on the canonicalized payload excluding the content_hash node itself, which is added only after the digest has been computed.

For hashing purposes, the payload must be canonicalized and serialized excluding the content_hash object, which is added only after the digest has been computed.

Canonicalized output (SHA-256 input, without content_hash):

{"authority":{"id":"user_87421","role":"HR Reviewer","verification":"DAPI-XXXX"},"chain":{"chain_type":null,"matter_reference":null,"parent_evide_id":null},"created_at_utc":"2026-04-07T09:15:05Z","decision":{"closure_timestamp_utc":"2026-04-07T09:15:00Z","status":"finalized","summary":"AI recommendation overridden by human authority","type":"candidate_evaluation"},"evide_schema":"2.1","fedis_requested":false,"handoff":{"acceptance_status":"not_claimed","boundary_readiness":{"readiness_gate":{"identifier":"GateSystem-v1.2","scope_reference":"https://example.org/gate-policy/boundary-v1"},"status":"verified_partial","unresolved_signals":["downstream_propagation_state"],"visibility_surface":"partial"},"reconstruction_independence":"declared","submission_status":"not_submitted"},"human_oversight":{"declared_level":"L2","is_declared":true},"intervention":{"classification_context":{"taxonomy_reference":"https://example.org/taxonomies/rationale-types-v1.0","threshold_authority":{"attribution_status":"attributed","source":"HR Policy Committee"},"threshold_reference":"https://example.org/rules/hr-review-threshold-v1","threshold_status":"met"},"classification_status":"stable","rationale":"AI misinterpreted parental leave as employment gap","rationale_type":"misclassification_correction","taxonomy_version":"rationale-types-v1.0","trace":{"access":"restricted","reference":"AUDIT_LOG_998721"},"type":"override"},"object_class":"decision_record","source_reference":"CDR-2026-00421","source_system":"Example Governance Systems Ltd","source_timestamp_utc":"2026-04-07T09:15:00Z"}

→ SHA-256 of this output is inserted in content_hash.value in the final payload.

A decision recorded under a given taxonomy_version will always remain auditable against that version, regardless of future taxonomy changes.

The human_oversight field

EVIDE does not verify human oversight. It records that it was declared, by whom, and at what level. This distinction is critical: the evidentiary value does not derive from verification, but from the explicit, portable and time-anchored declaration. The phrase that describes the field: "EVIDE does not verify human oversight. It makes its declaration explicit, portable, and externally anchorable."

"EVIDE does not verify human oversight.
It makes its declaration explicit, portable, and externally anchorable."

Planned extensions future

The following fields are planned for future schema versions. They are documented here to allow upstream systems to plan for compatibility.

Field	Description	Status
evide_id	Native EVIDE identifier in the payload. Today assigned after deposit. In future versions it may be pre-generated by the source system and confirmed at deposit time.	planned
issuer .organization .unit	Organisation and unit responsible for the deposit. Distinguishes the technical system from the legally responsible organisation. Useful in multi-org contexts.	planned

// Planned extensions - not part of the active minimum payload
{
  "evide_id": "EVIDE-20260407-0001",
  "issuer": {
    "organization": "Example Governance Systems Ltd",
    "unit": "HR Department"
  }
}