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

Account binding at intake. On the API intake, authority.dapi_number is required and must match the DAPI identity bound to the API key. Missing value: 422 missing_field; non-matching value: 403 dapi_mismatch; key not bound to a user identity: 403 missing_user_binding. The check binds the deposit to the authenticated account; it does not verify the declared authority, role or powers.

The EVIDE intake payload is a JSON object submitted via POST. Its decoded form is canonicalized and hashed deterministically at intake (Section 4). 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.dapi_number — required on the API intake; must match the DAPI identity bound to the API key used for the request, cross-checked server-side at intake time (errors: see Account binding at intake).

• authority.verification — declared textual reference, not validated server-side. When present, evidentiary_profile.identity returns "claimed" instead of "declared", without verifying identity, role or powers; separate from the authority.dapi_number check.
• 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 — requests evaluation for optional FEDIS forensic certification
• 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. Records the declared visibility limit and the gate reference; it is neither proof of diligence nor a 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 payload is stored as decoded by the server, and its hash is computed on the canonical form described in Section 4.

Before computing the SHA-256 intake hash, the server canonicalizes the decoded payload with the rules below, as specified in the technical note Payload Canonicalization. Changing only JSON whitespace outside string values, or using alternative escape sequences that decode to the same string value, does not change the hash, and object key order is normalized. This is not an equivalence for every semantically identical payload: any difference in values, in the order of arrays not reordered below, or in details normalized by the decoder can produce a different hash.

• Remove the top-level content_hash node if present. A content_hash key nested inside another object is not removed.
• Sort object keys recursively at every nesting level, by byte-wise string comparison (PHP ksort with SORT_STRING): uppercase letters sort before lowercase letters.
• Sort arrays named extensions by value with the PHP <=> operator: byte-wise for the registered extension names; numeric strings are compared as numbers, non-strings as empty strings.
• Sort arrays named evidence_references by the composite key artifact_type, pointer, declared_origin, hash.value, compared byte-wise in that order. A missing component counts as an empty string, and no other field is considered. Items with equal sort keys keep their submitted order; swapping them can change the hash if their canonical representations differ.
• Keep the submitted element order of every other array. Each element is canonicalized recursively.
• Serialize as minified JSON with PHP json_encode and the flags JSON_UNESCAPED_UNICODE | JSON_UNESCAPED_SLASHES: UTF-8 characters and slashes are not escaped.
• Compute SHA-256 of the resulting bytes, expressed as lowercase hexadecimal.

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) is a forensic document that references an EVIDE intake record and is intended to support its later examination. It is not a default system artifact but the optional output of a separate certification process. Setting fedis_requested: true submits a request for evaluation and a separate quote. It does not generate or issue FEDIS. The platform generates the document only after the certifier explicitly initiates generation.

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

Once the certifier initiates generation, the platform generates the FEDIS document for the certifier's signature. The document states the SHA-256 fingerprints of the intake record (the Canonical Intake Record JSON for structured intakes, the received artifact for file, text and URL intakes) and of the frozen Evidentiary Artifact Record (EAR), and documents the chain of custody. The certifier signs it with a qualified electronic signature (eIDAS Art. 25), and, as a distinct step, the document receives a qualified electronic time stamp (eIDAS Art. 41) issued by a third-party qualified trust service provider. The time stamp attests the moment at which it is applied to the FEDIS document: it does not make the intake timestamp qualified, does not date the original event and does not prove that the content is true.

FEDIS is intended to support examination in audit, regulatory and judicial contexts. It does not guarantee admissibility or the evidentiary weight a court or competent authority may assign to it.