EVIDE Minimum Intake JSON v0.1

"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

v0.1

Documentation and format

evide_schema field

"1.2"

Data contract in the payload

Schema fields

Field	Description	Status
evide_schema	EVIDE schema version. Always "1.0" for this version.	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 - DAPI code if the authority is verified through DAPI. Optional.	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

Full example v1.2

{
  "evide_schema": "1.2",
  "created_at_utc": "2026-04-07T09:15:05Z",  // new in v1.1
  "object_class": "decision_record",          // new in v1.1

  "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",  // new in v1.2
    "rationale": "AI misinterpreted parental leave as employment gap",
    "trace": {
      "reference": "AUDIT_LOG_998721",
      "access": "restricted"
    }
  },

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

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

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

→ content_hash.value is the only field calculated after canonicalization. The payload is hashed without the content_hash node, then the digest is inserted here.

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":"1.2","human_oversight":{"declared_level":"L2","is_declared":true},"intervention":{"rationale":"AI misinterpreted parental leave as employment gap","rationale_type":"misclassification_correction","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.

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

Ready to deposit?

Access the portal Try the demo