The public registry of certified evidence within the </AI> Protocol framework
External evidentiary deposit system for digital evidence and closed decision units. It allows anchoring content, decisions and system outputs, including those based on artificial intelligence, to a verifiable, independent and temporally defined reference, in sectors where oversight must not be declared, but demonstrated.
EVIDE is part of the </AI> Protocol, the framework for verifiable supervision of digital and artificial intelligence systems.
EVIDE schema v2.0 – Forensic Cross-Check and Evidentiary Profile
EVIDE now goes beyond preserving what a system declared. With v2.0, the evidentiary_profile is server-computed at intake time: a nine-dimensional read of the closure object that includes continuity, inferred via Forensic Cross-Check. EVIDE now cross-checks whether the declared stability claim was coherent with what the gate could actually observe at boundary crossing.
The problem EVIDE solves
The AI Act requires human oversight. But it does not define how that oversight becomes provable.
And this is exactly where, in practice, the problems begin.
What many teams are already observing is this:
- the decision exists, but the reference is not stable across systems
- authority is recorded, but not clearly attributable
- the rationale exists, but remains free text, unstructured and not recoverable in a coherent way under audit pressure
- the process exists, but cannot be reconstructed in a defensible way
The system does not fail. It does something more subtle.
It stabilizes decision objects that are only partially defined.
And this is exactly the point where interpretability and defensibility begin to degrade over time.
AI Act -> is normative | EVIDE -> is evidentiary
AI Act -> is ex-ante (compliance) | EVIDE -> is ex-post (defensibility)
AI Act -> is policy | EVIDE -> is evidence
The AI Act defines what must exist. EVIDE defines what must be provable.
They are not in competition. They are two different layers of the same accountability chain.
Who uses EVIDE – and why
Every day, organizations across regulated sectors make thousands of AI-assisted decisions. Credit approvals, claims assessments, hiring screenings, clinical recommendations, compliance reviews. In each case, the question regulators and courts are beginning to ask is not whether AI was used, but whether the human who reviewed the output was operating within a documented, defensible structure.
EVIDE addresses this question structurally, across five sectors:
Credit decisions, risk assessments, KYC/AML reviews. Regulatory audit cannot reconstruct which taxonomy was in use at the time of a decision. EVIDE anchors it externally at intake.
Claims assessment, fraud detection, underwriting decisions. When a denied claim is challenged in court, EVIDE provides the structured record of human review against a defined criterion, externally verifiable.
Under the EU AI Act, AI-assisted personnel decisions are high-risk. EVIDE makes human oversight demonstrable, not declared, with taxonomy and threshold anchored at the moment of review.
AI is increasingly present in diagnostic support and triage. EVIDE separates institutional liability from individual clinician liability through structured attribution anchored independently.
Law firms, DPOs and compliance consultants operating across multiple clients and regulatory frameworks. A single EVIDE integration works across all clients, all sectors: the schema is domain-agnostic. When regulators ask: the answer is not a document. It is a verifiable record with a hash and a timestamp.
Explore all use cases with risk/benefit analysis ->
What is the External Evidentiary Deposit
The External Evidentiary Deposit – EVIDE is the public and verifiable registration system for certified digital evidence within the </AI> Protocol. Each deposited evidentiary unit receives a unique identifier in the format EVIDE-YYYYMMDD-XXXX, permanently associated with the SHA-256 hash of the content and the UTC timestamp of the intake.
The term “external” does not indicate a geographical location, but a fundamental architectural principle: the deposit is carried out with a third-party entity, independent from those who produced or used the evidence. This separation is the necessary condition for the deposit to have evidentiary value in legal contexts and not be challenged as self-referential.
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.
EVIDE JSON: making decision structure visible
The EVIDE JSON schema defines the minimum structured payload required to anchor a decision as an independently verifiable evidentiary object. It exposes whether the decision was made within a defined upstream structure (taxonomy, threshold, and the authority behind that threshold) at the moment of recording.
This does not validate decisions. It exposes whether a decision was made within a defined structure, and whether that structure itself had an attributable source.
“classification_context”: {
“taxonomy_reference”: “https://…”,
“threshold_reference”: “https://…”,
“threshold_status”: “met”,
“threshold_authority”: {
“source”: “Policy Committee”,
“attribution_status”: “attributed”
}
}
}
A key architectural principle is the separation between taxonomy_reference (internal classification system, an editorial choice) and threshold_reference (external rule or regulatory parameter, a normative constraint). This separation is not a technical detail. It is what allows governance and regulation to coexist without being confused.
The full schema specification, including field definitions, required and optional fields, canonicalisation rules, closure interpretation guide, and classification patterns, is maintained at:
EVIDE JSON – current schema specification ->
Forensic Cross-Check and the evidentiary profile
With EVIDE v2.0, the system no longer limits itself to preserving what the source system declared. At intake time, EVIDE computes a server-side evidentiary_profile, a nine-dimensional structured read of the closure object that is not part of the submitted payload and is not included in the canonical hash.
The nine dimensions cover: identity, authority, classification, threshold, threshold authority, boundary readiness, runtime visibility, trace reference, and continuity.
The ninth dimension, continuity, is the most architecturally significant. It is not declared by the source system. It is inferred by EVIDE through the Forensic Cross-Check:
“mode”: “inferred”,
“state”: “degraded”,
“derivation”: “classification_x_runtime_visibility”,
“function”: “forensic_cross_check”
}
The Forensic Cross-Check detects a specific and previously unaddressed failure mode: Synthetic Coherence: the condition where a decision appears procedurally stable and internally coherent, while the actual observable runtime surface supporting that stability has already degraded at the moment of boundary crossing.
In practice, the inference follows a conservative matrix:
- stable classification + confirmed visibility -> continuity: stable
- stable classification + partial visibility -> continuity: degraded
- provisional classification + any visibility -> continuity: degraded or unknown
- contested classification + any visibility -> continuity: broken
This also creates a clean evolution path: today mode: "inferred", future Gate Qualification Framework mode: "qualified", without breaking downstream compatibility.
Read the full schema reference ->
Layer boundary validation
EVIDE operates at the evidentiary anchoring boundary of the accountability chain, at the point where a responsibility-bearing closure state crosses a trust boundary and becomes independently verifiable outside the originating system.
The boundary behavior has been technically validated in real-world integration scenarios, including live runtime governance architectures. Key findings:
- Internal traceability, even if complete and structured, does not cross into independent evidentiary status without a trust-separated anchoring layer
- The closure trigger is not behavioral completion, but responsibility closure: the moment an outcome is explicitly bound to an identified authority
- The evidentiary object produced at this boundary is verifiable without access to the originating system
- Evidentiary strength is graded: a record anchored with full attribution, defined taxonomy, and verified threshold authority carries significantly higher defensibility than one anchored with partial or absent structural grounding
For the full technical analysis of boundary behavior and graded evidentiary states:
- EVIDE Boundary Model – Layer boundary validation and evidentiary states
- EVIDE Boundary Model v2 – Graded evidentiary states and external defensibility
From decision to defensible structure: the full technical analysis ->
-> From decision to defensible structure: when supervision becomes evidence
-> Read the public technical specification
-> Verify a CWC code in the public registry
-> EVIDE – Evidentiary registry for digital content and decisions
-> CWC registry policy
-> Request an official CWC verification code
-> AI governance documentation framework
-> Implementation guide: verifiable AI supervision
-> Oversight bias
-> Decision Attestation Layer
-> AI Evidence Officer
-> The evidentiary layer in AI governance
-> FAQ on the </AI> Protocol
Related readings:
-> AI Data Poisoning
-> Human in the loop
-> Real cases of AI governance failures
Work with us:
What it is for
EVIDE addresses a concrete need: anchoring evidence, decisions and outputs of digital systems to a verifiable reference over time.
- Internal protection: immediate registration with defensible hash and timestamp
- Legal prevention: early certification before disputes arise
- On-demand escalation: certification can also occur later while preserving the validity of the original hash
- Cost optimization: selective certification only where necessary
The structure of the deposit
The process is structured in two distinct levels with increasing evidentiary value.
Level 1 – Evidentiary intake
At the moment of submission, the SHA-256 hash is calculated and the UTC timestamp is recorded. This already constitutes proof of the existence of the content in that form.
- FILE / ZIP: byte-by-byte hash
- URL: exact string hash
- TEXT: normalized text hash
- JSON: canonicalised payload (keys sorted alphabetically) and deterministically hashed
All processes are compliant with RFC 3161 and prepared for qualified eIDAS timestamps.
With the introduction of the structured JSON type, EVIDE now also supports the deposit of structured decision objects. Unlike generic types, JSON is not arbitrary 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 before hashing, guaranteeing a deterministic hash independent of field order.
For the current schema specification, required fields and canonicalisation rules: EVIDE JSON – current schema specification ->
The JSON deposit allows external systems to treat the EVIDE identifier as a portable authority reference: a verifiable evidentiary anchor that can move across layers and remain valid independently of the system that produced the original decision.
EVIDE deposits are also available via API for systems handling high volumes of structured decisions. The endpoint accepts JSON payloads conforming to the current EVIDE schema, computes the canonicalized hash deterministically and returns the evide_id, the intake_hash, and the server-computed evidentiary_profile in the response.
Suitable for AI systems producing decisions at scale, automated governance platforms, and enterprise integrations requiring continuous evidentiary anchoring without manual intervention.
Level 2 – FEDIS certification and publication
Full certification includes professional validation, FEDIS issuance and publication in the EVIDE registry. Original files are deleted after issuance, the system retains only the hash.
The EVIDE identifier
EVIDE-20260403-0042- EVIDE registry prefix
- YYYYMMDD date
- XXXX unique progressive number
The registry is public and verifiable. Integrity can be checked by calculating the hash of the original content.
The separation between intake and certification
Not all declarations need to be public. All must be defensible.
The intake has evidentiary value even without publication. FEDIS certification represents the next level.
Certification can also occur later, provided that the content exactly matches the recorded hash.
Verifiable Evidence Chain
With the introduction of the Verifiable Evidence Chain, EVIDE no longer certifies a single moment. It certifies a process.
Each intake remains independent and immutable, with its own SHA-256 hash and UTC timestamp. But it can be linked to a previous intake, creating a verifiable evidentiary sequence over time. Each node in the chain maintains its own integrity: the link is optional and does not modify the fingerprint of the individual element.
You can try the test navigation [click here]
Why this changes everything
In legal proceedings or audits, proving the final decision is not enough. It is often necessary to reconstruct how you moved from the initial version to the definitive one: what changes were made, when, and in what order.
The EVIDE evidence chain responds precisely to this need:
- Intake #1 – original document, initial decision, first version
- Intake #2 – revision, update, integration
- Intake #3 – final version, with FEDIS certification and EVIDE publication
Each step has its own hash. The sequence is verifiable. Professional diligence becomes demonstrable.
You are not storing a file. You are documenting professional accountability over time.
Concrete use cases:
- Contracts under negotiation: each version is certified, the sequence is unassailable
- Company policies: subsequent revisions are linked to the original version
- AI system outputs: every model update or response change is tracked
- Medical or legal decisions: the decision-making process is documented step by step
- Regulatory compliance: versions of policies and procedures are verifiable over time
One verified identity, multiple organisations
A single DAPI identifies the person. The same verified identity can operate across multiple distinct organisational perimeters, keeping requests, chains and billing separate.
This architecture addresses a concrete need for lawyers, DPOs, consultants and professional firms managing multiple clients or mandates simultaneously:
- Lawyer – manages the law firm, three client companies and a public body with a single login
- External DPO – operates across multiple organisations as data protection officer, keeping logs and requests separate
- AI governance consultant – certifies outputs and decisions for different clients, with separate billing for each mandate
- Professional firm – collaborators operate under the same structure but across distinct client perimeters, with differentiated roles and access
How it works
The DAPI identifies the professional. The organisation defines the operational perimeter. Each request originates within a specific organisational perimeter:
- Requests, chains and certifications remain separate by organisation
- Billing is associated with the organisation, not the individual user
- Roles within each organisation are configurable: owner, admin, member
Roles within the organisation
The three roles define the visibility perimeter and responsibility of each member:
| Role | Request visibility | Billing | Typical use case |
|---|---|---|---|
| Owner | All organisation requests, regardless of who created them | Can enter and manage billing details | Firm principal, mandate holder |
| Admin | All organisation requests, regardless of who created them | Can enter and manage billing details | Senior associate, operations manager |
| Member | Only their own requests within the organisation | Cannot modify billing details | Associate, trainee, assigned consultant |
A principal lawyer (owner) sees all the firm’s cases. An associate (member) sees only their own. The separation is automatic and requires no manual configuration for each request.
- Multiple professionals can operate on the same organisation with distinct DAPI identities
We do not sell certifications to individual users. We provide an evidentiary infrastructure to professionals who bring it to their clients.
The professional who adopts EVIDE for one client naturally becomes the entry point for all their clients. A lawyer who certifies a company’s decisions will quickly see the value of extending the same system to other mandates within their firm.
EVIDE as digital proof infrastructure
With the introduction of the evidence chain and multi-organisation management, EVIDE evolves from a point-in-time certification tool to an operational infrastructure for digital proof.
This is not about certifying a single piece of content. It is about building a system in which every decision, every revision, every relevant digital output is anchored to a verifiable, independent and temporally defined reference.
- Isolated – each intake is autonomous and individually verifiable
- Sequential – intakes can form evidentiary chains over time
- Perimeter-separated – each organisation has its own operational space
- Scalable – a professional can manage N organisations with a single identity
From isolated proof to continuous accountability.
What practitioners are saying
Independent signals from architects and practitioners working on adjacent problems in AI governance, execution boundaries, and evidentiary infrastructure.
“The isolation of ‘continuity-substrate instability’ is the most critical architectural diagnosis of the year. The industry is obsessed with auditing the payload while completely ignoring the physics of the transport layer. Evidence without physical enforcement is just an autopsy report. The EVIDE architecture is setting the standard for how we translate degraded trust into kinetic severance.”
Naimat Ullah, Principal Architect: AI Execution Boundaries, Founder Velos Systems
May 2026 – in response to: “The Hidden Governance Risk: When Evidentiary Integrity Is Not Enough”
All external signals and architectural validations ->
Access to the system
Access is reserved to DAPI certificate holders, ensuring the identity of the subject performing the deposit.
The EVIDE registry, on the other hand, is public and accessible without authentication.
The framework is publicly defined as “The </AI> Protocol” and is forensically certified through CertifyWebContent. This documentation constitutes a verifiable and timestamped record of its structure, its concepts and its implementation.