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.1", the only value accepted by the API today. Earlier values ("1.8", "1.9", "2.0") are historical — see Section 5 for their evolution — and are no longer accepted.

• evide_schema — must be "2.1". Earlier values ("1.8", "1.9", "2.0") are historical and no longer accepted.
• 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, evidentiary_profile.identity returns "declared" instead of "claimed"
• intervention.type — override / approval / rejection / escalation
• intervention.classification_context — upstream governance structure visibility (introduced v1.7). Required.
• human_oversight.is_declared + declared_level — L1 / L2 / L3
• fedis_requested — triggers FEDIS forensic certification workflow
• chain — links this intake to a previous one, forming a verifiable evidentiary chain (introduced v1.0 as a base-schema field, extended v2.1 with matter_reference). chain.parent_evide_id — EVIDE ID of the previous record. chain.chain_type — free text describing the continuation (e.g. litigation_hold, internal_investigation). chain.matter_reference — optional, inherited from the parent if omitted; if declared on both sides it must match. Validation is strict: the parent must exist, belong to the same evidentiary domain, be in an accepted status, and — if a matter_reference is declared — match it. There is no silent fallback: an invalid parent_evide_id fails the request rather than silently starting a new chain. See Evidentiary Continuity for the full model.
• handoff — boundary state declaration for L3 intake. Required. boundary_readiness is a structured object with four canonical states (introduced v2.0). See Section 3.
• extensions — array of strings declaring which optional schema extensions this payload carries. Registered extensions: evidence_references, declarations. An extension must be declared here to be accepted (v2.1).
• evidence_references — array of declared external artifact references (screenshots, video, sensor logs, documents), anchored without EVIDE storing the underlying file. Optional integrity hash per artifact, declared by the submitter. Requires "extensions": ["evidence_references"] on the same payload. (v2.1)
• declarations — array of 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. Requires "extensions": ["declarations"] on the same payload. See EVIDE ANCHOR. (v2.1)

The chain guarantees above are enforced at intake, not reconciled afterwards. Each condition returns its own code, so an integrator can tell a data error from an authorization refusal without parsing prose:

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.

• 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. boundary_readiness is a structured object with four canonical states (promoted from a plain string in v2.0).

• 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 response also includes evidentiary_profile — a server-computed eleven-dimensional read of the intake object (profile_version: "1.1"). The profile is not part of the submitted payload and is not included in the canonical hash. 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.4.1)

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.