EVIDE Minimum Intake JSON

EVIDE (External Evidentiary Deposit) is a structured evidentiary intake layer designed to anchor AI-assisted or human decisions to an independent, cryptographically verifiable record. Each intake transforms a closed decision into a portable evidentiary object that can be validated outside the originating system, without requiring operational access to the source system, its logs, or its infrastructure.

EVIDE does not:

• verify whether the declared authority was legitimate
• validate the correctness of the decision
• introduce admissibility logic
• replace governance frameworks
• operate inside the decision pipeline

EVIDE operates at a specific and bounded layer. Understanding what it does and does not do prevents misuse and misinterpretation.

• EVIDE records closure state, not runtime execution
• EVIDE anchors the externally visible responsibility state at the moment a decision becomes final
• EVIDE preserves admissibility visibility without enforcing admissibility
• EVIDE is evidentiary, not supervisory
• EVIDE does not replay decisions — it anchors closure objects
• EVIDE does not verify declared oversight — it makes the declaration persistent, portable, and independently verifiable

EVIDE access provisioning requires DAPI identity verification. This requirement exists because EVIDE operates as an evidentiary responsibility layer. The intake infrastructure must be able to attribute API activity to a verifiable identity source, even when deposited payloads contain declared or non-verified authority states.

DAPI therefore functions as the identity-bound access layer of the EVIDE intake infrastructure, separating:

• infrastructure access attribution
• payload-declared authority
• evidentiary responsibility visibility

The EVIDE intake payload is a JSON object submitted via POST. It is canonicalized and hashed deterministically before storage. The current schema version is "2.0". Versions "1.8" and "1.9" remain supported for compatibility.

• evide_schema — must be "2.0" for current intake. "1.8" supported for compatibility (no handoff). "1.9" supported with handoff as string.
• source_system — name of the originating system
• source_reference — unique decision identifier in the source system
• source_timestamp_utc — ISO 8601 UTC timestamp of decision production
• decision.type — decision category (e.g. candidate_evaluation, risk_classification)
• decision.status — must be "finalized"
• decision.closure_timestamp_utc — UTC timestamp of closure
• decision.summary — natural-language description of the decision
• authority.id — authority identifier in the source system
• authority.role — role of the authority

• authority.verification — DAPI reference code linking the authority to a verified identity. Without it, authority_verification_status returns "declared" instead of "claimed".
• intervention.type — override / approval / rejection / escalation
• intervention.classification_context — upstream governance structure visibility (v1.7). Required for evide_schema 2.0.
• human_oversight.is_declared + declared_level — L1 / L2 / L3
• fedis_requested — triggers FEDIS forensic certification workflow
• chain.parent_evide_id — links to a previous intake in a verifiable evidence chain
• handoff — boundary state declaration for L3 intake. Required when evide_schema = "1.9" or "2.0". In v2.0, boundary_readiness is a structured object with four canonical states. See Section 3.

Full schema reference: app.certifywebcontent.com/json

The classification_context object exposes whether the classification act was supported by an upstream taxonomy and threshold structure at the moment of recording. It does not validate the threshold — it makes the presence or absence of such a structure externally visible. Required when evide_schema = "2.0".

• met — threshold was defined and the decision satisfied it
• not_met — threshold was defined but not satisfied
• unknown — threshold may exist but state is not verifiable at deposit time
• not_defined — no threshold was formally defined for this classification

Exposes whether the threshold had a structurally attributable source of authority at closure. attribution_status is required when threshold_authority is present.

• attributed — single identifiable 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

The handoff object defines the boundary state of a closure object before EVIDE accepts it for external anchoring. Required when evide_schema is "1.9" or "2.0". In v2.0, boundary_readiness is promoted from a string to a structured object with four canonical states.

• status — required. One of: candidate, verified, verified_partial, unverifiable.
• readiness_gate.identifier — required when status ≠ candidate. Name or ID of the gate system that performed the assessment.
• readiness_gate.scope_reference — required when status ≠ candidate. URL or hash of the gate policy document. Makes verified non-self-referential.
• visibility_surface — categorical declaration of the gate's observational coverage: null (candidate), partial, declared_complete, insufficient.
• unresolved_signals — string array of signal identifiers the gate could not resolve. Empty for candidate and verified. Minimum one element for verified_partial and unverifiable.

• candidate — readiness_gate: null, visibility_surface: null, unresolved_signals: []. No gate has operated. Upstream declaration only.
• verified — readiness_gate: present, visibility_surface: declared_complete, unresolved_signals: []. Gate confirmed stability across complete visibility.
• verified_partial — readiness_gate: present, visibility_surface: partial, unresolved_signals: [min. 1]. Gate confirmed what it could see. Gaps declared explicitly.
• unverifiable — readiness_gate: present, visibility_surface: insufficient, unresolved_signals: [min. 1]. Gate operated but surface was below minimum threshold. Proves diligence, not failure.

• reconstruction_independence — must be declared for EVIDE intake.
• submission_status — must be not_submitted when sent by the upstream system.
• acceptance_status — must be not_claimed when sent by the upstream system.

After a successful intake, EVIDE returns the updated handoff state with submission_status: "submitted" and acceptance_status: "accepted". In v2.0, boundary_readiness is returned as a structured object. The original submitted payload is stored and hashed without modification.

Before computing the SHA-256 hash, the system canonicalizes the JSON: keys are sorted alphabetically at all levels and the result is minified. This guarantees that two semantically identical payloads always produce the same hash regardless of key submission order. The content_hash field is excluded before hashing.

• Remove the content_hash node if present
• Recursively sort all keys alphabetically at every nesting level
• Serialize to minified JSON (UTF-8, no escaped slashes)
• Compute SHA-256 of the resulting string

EVIDE follows a strict backward-compatible evolution model. Each version adds optional fields or response attributes without breaking existing integrations.

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

EVIDE is designed to receive structured closure objects from any system — AI pipelines, workflow engines, governance platforms, runtime agent systems — without requiring integration inside the decision pipeline.

The minimal boundary requirements for the source system are:

• an explicit closure state (not only behavioral completion)
• an identified authority bound to that closure
• an explicit responsibility declaration
• a stable reference to the upstream trace
• a coherent classification context (even if initially internal)

• evidence_id → source_reference (primary object identity)
• event_id → intervention.trace.reference (runtime event identity)
• trace_reference → intervention.trace.reference (upstream trace continuity)

Reference implementation: RANKIGI × EVIDE Interface Mapping (v0.3)

FEDIS (Forensic Evidence Declaration & Integrity Statement) transforms an EVIDE intake record into a legally presentable forensic artifact. It is not a default system artifact but a formal evidentiary output generated through a certification process, triggered by setting fedis_requested: true in the intake payload.

Reference: certifywebcontent.com — FEDIS

A FEDIS-ready EVIDE record must include:

• cryptographically fixed closure state (SHA-256 intake hash)
• independent UTC intake timestamp
• declared authority bound to the closure
• classification context sufficient for external interpretation
• stable upstream trace reference

FEDIS extends the EVIDE record with a qualified eIDAS digital signature, RFC 3161 timestamping, SHA-256 and SHA-512 fingerprints, formal chain of custody declaration, and sworn statement — making the same record usable in audit, regulatory, and judicial contexts without reprocessing.