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

"EVIDE does not try to standardise how a decision is made. It standardises the minimum evidentiary object that can survive outside the source system."

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.

Acronym definition

EVIDE

E → Evidentiary object

V → Verifiable state

I → Integrity-bound

D → Decision-complete

E → Externally anchored

EVIDE is not just evidence.
It is Evidence that is Verifiable, Integrity-bound, Decision-complete, and Externally anchored.

External anchoring is what makes a decision externally accountable.

A decision is anchor-ready not when it is free of interpretation, but when the interpretation it contains has already been made explicit, attributable, and no longer needs to be reconstructed by the executing layer.

The goal is not to eliminate interpretation. The goal is to ensure that interpretation is explicit, owned, and sealed before execution.

Versioning: public specification vs schema

The public specification version (v0.1) and the evide_schema field version in the payload (1.0) 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

v2.0

Documentation and format

evide_schema field

"2.0"

Data contract in the payload

v1.9 - previous stable schema

Schema fields

Field	Description	Status
evide_schema	EVIDE schema version. Use "2.0" for the submitted payload.	Required
source_system	Name of the system that produced the decision. E.g. "AquariuOS", "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	Link to the EVIDE Verifiable Evidence Chain. Null for first deposit.	Optional

Additional fields in v1.1 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

Additional fields in v1.2 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

New fields v1.3 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

New fields v1.4 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

v1.5 — Computed response attributes 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. <code>claimed</code> - 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. <code>declared</code> - The authority has not provided any DAPI reference. The identity is only declared in the authority.id field. The third state <code>verified</code> 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 v2.0 - 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.0",
  "fedis_requested": false,
  "evidentiary_profile": {             // server-computed — new in v2.0
    "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": "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 (continuity) inferred via Forensic Cross-Check (classification × runtime_visibility) — anti-Synthetic-Coherence sensor. Dim 10 (decision_wave_compression / DWC) inferred: runtime_visibility × boundary_readiness × unresolved_signals. Dim 11 (formal_accountability_collapse / FAC) inferred: authority × threshold_attribution × continuity_state. States for dim 10-11: not_detected | detected | critical | unknown.

New fields v1.6 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. <code>stable</code> - Category assigned with no known ambiguity under the active taxonomy. <code>provisional</code> - Category assigned provisionally or pending refinement. <code>contested</code> - 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

New in v1.7 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. <strong>.taxonomy_reference</strong> - Reference to the taxonomy source used at the time of classification. May be omitted if the version is already identified via taxonomy_version. <strong>.threshold_reference</strong> - Reference to the upstream rule, threshold, or admissibility condition used by the originating system. <strong>.threshold_status</strong> - 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

Recommended classification combinations (structural completeness patterns)

The following combinations are provided as implementation guidance only.
They do not introduce validation logic. EVIDE does not enforce any combination as valid or invalid.
Their purpose is to make structural completeness visible, not to evaluate correctness.

This section defines observable patterns of structural completeness, not rules of admissibility.

1. Complete and stable classification

"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"
}

The classification is operationally stable and anchored to a defined upstream taxonomy and threshold rule. This is the strongest evidentiary state: both the operational condition and the structural grounding are visible.

2. Stable classification - no upstream structure visible at deposit time

"classification_status": "stable",
"classification_context": {
  "taxonomy_reference": null,
  "threshold_reference": null,
  "threshold_status": "unknown"
}

The classification is considered stable by the source system, but no upstream structure is visible at deposit time. The gap is exposed, not evaluated. EVIDE does not judge the classification - it records that no structural reference was anchored alongside it.

3. Provisional classification with visible upstream structure

"classification_status": "provisional",
"classification_context": {
  "taxonomy_reference": "https://example.org/taxonomies/rationale-types-v1.0",
  "threshold_reference": "https://example.org/rules/review-threshold-v1",
  "threshold_status": "met"
}

An upstream structure exists and is visible, but the classification itself is not yet operationally stable. The structural grounding is present - the operational state is still pending resolution.

4. Contested classification with defined structure

"classification_status": "contested",
"classification_context": {
  "taxonomy_reference": "https://example.org/taxonomies/rationale-types-v1.0",
  "threshold_reference": "https://example.org/rules/review-threshold-v1",
  "threshold_status": "met"
}

The classification is disputed, but the upstream taxonomy and threshold context remain visible. The existence of a defined structure does not resolve the dispute - it makes the dispute interpretable against a stable reference.

5. Stable classification - taxonomy present, no threshold defined

"classification_status": "stable",
"classification_context": {
  "taxonomy_reference": "https://example.org/taxonomies/rationale-types-v1.0",
  "threshold_reference": null,
  "threshold_status": "not_defined"
}

A taxonomy exists and is referenced, but no upstream threshold was defined for this classification. This may indicate a governance maturity gap upstream - the classification system exists, but the admissibility condition has not yet been formally specified. EVIDE makes this condition visible without making EVIDE responsible for resolving it.

EVIDE does not decide whether a classification is correct.
It makes the presence or absence of structural grounding visible.

These combinations describe how that visibility appears in practice.
They are not validation rules.

Closure interpretation at evidentiary boundary

This section clarifies how closure states should be interpreted at the evidentiary level.
EVIDE does not define or enforce closure types. It exposes the conditions required to distinguish them.

In practice, two distinct closure conditions may exist upstream:

Behavioral completion - the process has reached an outcome
Responsibility closure - the outcome is explicitly bound to an authority

EVIDE does not introduce a dedicated field to represent this distinction. Instead, it allows it to be inferred from the presence or absence of structural elements in the payload.

Behavioral completion

"decision": {
  "status": "finalized"
}

A finalized decision without a bound authority and declared human oversight represents behavioral completion only. The system has produced an outcome, but no accountable actor is formally attached to it.

Responsibility closure

"decision": {
  "status": "finalized"
},
"authority": {
  "id": "...",
  "role": "..."
},
"human_oversight": {
  "is_declared": true
}

A finalized decision with a bound authority and declared human oversight represents responsibility closure. The outcome is not only produced, but explicitly attributable.

EVIDE does not define closure types.
It makes visible whether a decision is merely completed or formally attributable.

The Layer 2 → Layer 3 boundary requires responsibility closure, not behavioral completion.
This distinction is not enforced by EVIDE, but made observable through the payload structure.

New in v1.8 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

New in v1.9 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.

boundary_readiness and runtime conditions - architectural note

EVIDE anchors closure states, not runtime states. It does not monitor conditions after anchoring and does not introduce runtime governance.

"They come from anchoring something that was already drifting at the moment it was externalized."

This is the failure mode that boundary_readiness is designed to prevent. The distinction between "candidate" and "verified" carries a precise architectural meaning: it declares whether the runtime conditions that grounded the closure state were independently confirmed as still stable at the moment of boundary crossing - not whether the decision itself was correct.

A system cannot evaluate its own boundary readiness and declare it "verified". That evaluation must come from a gate that is independent of the system that produced the decision. If no such independent confirmation exists, "candidate" is the correct and complete value - not a fallback.

This distinction preserves the separation between runtime governance and evidentiary anchoring: EVIDE does not prevent instability from forming upstream. It makes the boundary condition independently observable at the exact moment of externalization.

New in v2.0 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.

v2.0 is the current public schema. API enforcement may follow implementation rollout.
All existing v1.9 integrations remain valid and unaffected.

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.

Interpretation of unverifiable downstream

The <code>unverifiable</code> state operates at the deposit boundary, not downstream.

At deposit time, it functions as a documentation quality marker. The record itself remains valid, but explicitly captures that the stability of the declared state could not be independently confirmed at the moment of crossing.

What happens downstream is intentionally outside EVIDE’s scope. An auditor, admissibility framework, compliance system, or governance layer may decide to treat an <code>unverifiable</code> record as:

– a review flag
– a degraded input
– a condition requiring escalation
– or an acceptable state under specific operational constraints

EVIDE makes the condition persistent and queryable. The behavioral consequence of that condition belongs to the system that consumes the record, not to EVIDE itself.

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.

boundary_readiness and runtime conditions — architectural note (v2.0)

EVIDE anchors closure states, not runtime states. It does not monitor conditions after anchoring and does not introduce runtime governance.

"They come from anchoring something that was already drifting at the moment it was externalized."

In v2.0, this failure mode is addressed more precisely. The gate's own observational capacity becomes part of the evidentiary record. What the gate could not see is declared explicitly in unresolved_signals — it is no longer a hidden assumption but a documented variable.

A system cannot self-certify boundary_readiness.status = "verified". That evaluation must come from an independent gate declared in readiness_gate.identifier. If the gate's visibility was incomplete, the honest state is verified_partial with declared gaps — not verified.

unverifiable is not a failure state. It is the most forensically honest state when an independent gate operated but the source system was too opaque to confirm boundary stability.

Gate independence is a governance qualification, not a self-declared payload field in v2.0. Formal gate qualification is deferred to the v2.x Gate Qualification Framework.

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?	`handoff.boundary_readiness.visibility_surface`	`confirmed` · `partial` · `unverifiable` · `null`
`trace_reference`	Can the upstream trace be located?	`intervention.trace.access`	`available` · `restricted` · `unavailable`
`continuity`	Did meaning remain stable across boundary?	`classification` × `runtime_visibility` Forensic Cross-Check — inferred server-side	`{mode: inferred,` `state: stable\|degraded\|broken\|unknown}`
`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_state` FAC — inferred server-side	`not_detected` · `detected` · `critical` · `unknown`

Forensic Cross-Check (FCC) and baseline authority

EVIDE computes continuity deltas across anchored states. It does not determine which baseline is authoritative.

The selection of the comparison baseline is a governance act, not an evidentiary one.

This separation is not incidental. It prevents EVIDE from collapsing into a semantic authority layer, keeps comparison policy explicitly upstream-governed, and preserves the Forensic Cross-Check in its correct architectural role: observer of continuity states, not decider of which states carry governance weight. That governance authority remains upstream.

⚠ Planned — not part of the active v2.0 schema. Deferred to v2.x.

"continuity_drift": {
  "mode": "post_derived",
  "comparison_policy": "externally_declared",
  "comparison_policy_authority": "declared_by_upstream",
  "baseline_reference": "EVIDE-0012",
  "current_reference": "EVIDE-0048",
  "baseline_state": "stable",
  "current_state": "degraded",
  "delta": "negative",
  "function": "forensic_cross_check_delta"
}

Different comparison policies may produce different continuity deltas across the same chain. Examples include: last_sequential, last_known_stable, or externally_declared.

EVIDE exposes the observable drift between states. It does not decide which baseline carries governance authority. The upstream environment must declare the comparison_policy and its authority before EVIDE can expose a governance-qualified continuity delta.

Architectural principle:
EVIDE computes the delta. It does not select the baseline.
The baseline selection is a governance act, not an evidentiary one.

Full example v2.0

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

  "source_system": "AquariuOS",
  "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
  },

  "handoff": {
    "boundary_readiness": {                        // promoted from string — new in v2.0
      "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/

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,"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.0","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":"AquariuOS","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": "AquariuOS Ltd",
    "unit": "HR Department"
  }
}

How to deposit

Log in to the portal with your DAPI code
Create a new request and select the JSON structured type
Paste the JSON payload into the dedicated field
The system validates, canonicalises and computes the SHA-256 hash
Receive the EVIDE code and the downloadable canonicalised file

API Access

API access available for enterprise integrations

An API endpoint is available for depositing EVIDE records directly from external systems. Access is reserved for certified partners and enterprise clients. Contact us to receive technical documentation and access credentials.

Request API access

Ready to deposit?

Access the portal Try the demo