EVIDE v2.0 - Roadmap
v2.0 makes the evidentiary quality of the boundary explicit."
Sections 1-7 below are the original May 2026 v2.0 design document, preserved as published. It is not split by month and not rewritten for current-state accuracy - it is the record of what was designed and why.
v2.0 makes the evidentiary quality of the boundary explicit."
In EVIDE v1.9, handoff.boundary_readiness is a string with three possible values: "candidate", "verified", and "not_assessed".
This model works correctly for the majority of cases. However, it contains a structural assumption that does not hold in all real-world systems:
"verified" as a binary flag implicitly assumes that the gate had complete visibility of the runtime conditions it was assessing.
In practice, this is frequently not true. Many upstream systems are partial black boxes. Telemetry arrives with latency. The gate sees a projection of the runtime state, not the runtime state itself.
Emitting "verified" on fragmented visibility means the gate is attesting to something it did not have full capacity to confirm. This is not a technical problem - it is an evidentiary one.
The consequence: a record anchored with boundary_readiness: "verified" may carry an implicit claim of stability that the gate was not actually in a position to make. This weakens the evidentiary quality of "verified" as a category and reduces its defensibility in audit or legal contexts.
- Key phrase from the GRANT group validation process, May 2026
The single structural change in v2.0 is the promotion of boundary_readiness from a string to a structured object.
The string value "candidate" / "verified" becomes the status field of the new object. All other top-level fields of handoff remain unchanged.
This is a breaking change. Parsers that expect a string for boundary_readiness will need to be updated. This is why v2.0 requires a major version increment rather than a minor addition.
boundary_readiness as the future boundary_readiness.status field. The migration will be straightforward for any well-structured integration.
- readiness_gate.identifier - identifies the system or mechanism that performed the boundary readiness assessment. Separates the decision authority from the gate authority. Required when
statusis notcandidate. - readiness_gate.scope_reference - URL or hash reference to the gate policy document under which the assessment was performed. Makes
"verified"non-self-referential: the gate declares not just that it checked, but what protocol it followed. - visibility_surface - categorical declaration of the observational coverage the gate had at assessment time. Values:
null|partial|declared_complete|insufficient. Note:declared_complete, notcomplete- the gate declares completeness within its scope, not omniscience. - unresolved_signals - array of signal identifiers that the gate could not resolve at assessment time. Required to be non-empty when
statusisverified_partialorunverifiable.
The four canonical states of boundary_readiness.status in v2.0, with their complete object representations:
unverifiable: This is the most forensically important state. A record with status: "unverifiable" and a present readiness_gate.identifier proves that an independent assessment was attempted but the source system was too opaque to confirm boundary stability. In audit or legal contexts, this demonstrates diligence, not negligence. It documents a technical limit, not a governance failure.
Complete v2.0 handoff example:
| status | readiness_gate | visibility_surface | unresolved_signals | Evidentiary meaning |
|---|---|---|---|---|
| candidate | null | null | [] | Upstream declares readiness. No independent gate has assessed the object. |
| verified | present | declared_complete | [] | Gate confirmed stability across its declared scope. Maximum evidentiary strength within gate scope. |
| verified_partial | present | partial | [min. 1] | Gate confirmed what it could see. Unresolved signals are declared. Gaps are part of the record. |
| unverifiable | present | insufficient | [min. 1] | Gate attempted assessment but surface was below minimum viable threshold. Proves diligence, not failure. |
verified carries the highest evidentiary strength within the gate's declared scope. verified_partial carries strength proportional to the declared scope minus unresolved signals. unverifiable carries no boundary stability claim but carries a diligence record. candidate carries only the upstream declaration - no independent confirmation of any kind.
status: "candidate"-readiness_gatemust be null.visibility_surfacemust be null.unresolved_signalsmust be empty.status: "verified"-readiness_gatemust be present withidentifier.visibility_surfacemust be"declared_complete".unresolved_signalsmust be empty.status: "verified_partial"-readiness_gatemust be present withidentifier.visibility_surfacemust be"partial".unresolved_signalsmust contain at least one element.status: "unverifiable"-readiness_gatemust be present withidentifier.visibility_surfacemust be"insufficient".unresolved_signalsmust contain at least one element.readiness_gate.scope_referenceis strongly recommended.verifiedcannot be self-certified -readiness_gate.identifiermust reference a system or mechanism external to the system that produced the decision.unresolved_signalsvalues - string array in v2.0. A recommended controlled vocabulary will be documented separately. Structured signal objects (with type, severity, description) are deferred to v2.x.
verified_partial or unverifiable without naming what it could not see would be structurally incoherent. The constraint forces the gate to make its gaps explicit - an auditor always knows where to investigate further.
v2.0 introduces one structural change only. Everything else in the EVIDE schema remains identical to v1.9:
- All fields outside
handoff.boundary_readinessare unchanged handoff.reconstruction_independence- unchangedhandoff.submission_status- unchangedhandoff.acceptance_status- unchanged- Canonicalization algorithm - unchanged
- SHA-256 hashing - unchanged
- FEDIS compatibility - unchanged
- DAPI identity model - unchanged
- API authentication - unchanged
- EVIDE's role - unchanged: EVIDE anchors closure states, not runtime states. It does not monitor systems. It does not enforce admissibility. It does not certify decision correctness.
New in v2.0 - evidentiary_profile: introduced as a server-computed response object (profile_version: "1.0"). Not part of the submitted payload, not included in the canonical hash. Nine evidentiary dimensions, including continuity - inferred via Forensic Cross-Check (classification × runtime_visibility) as anti-Synthetic-Coherence sensor.
The v2.0 architectural definition emerged from a structured multi-party design process. The following contributors are documented at the level of their observable contribution to the design.
"verified" as a binary string implicitly assumes complete gate visibility - a condition that does not hold in systems with partial telemetry or black-box upstream components. The observation that a gate sees a projection of the runtime state, not the runtime state itself, was the architectural trigger for v2.0. Without this signal, the string model would have remained unquestioned.
boundary_readiness as a field reveals an implicit runtime dependency upstream - and framed this not as a weakness of EVIDE but as a demonstration that the upstream and evidentiary layers address the same risk from two different architectural positions. His framing of "the architectures remain separate, but now explain why each other becomes necessary" became the key articulation of the v2.0 complementarity model.
What happened after the May 2026 record, month by month. Each panel is closed by default - open the ones you need. Nothing here rewrites Layer 1; it records what changed, was clarified, or shipped afterward.
The following items were discussed during the v2.0 design process and deliberately excluded from the v2.0 scope. They are documented here as formal backlog items for future iterations. "Deferred" describes their status as of May 2026 - it does not by itself mean every item below remains deferred today; several are revisited in later panels of this timeline.
- Structured unresolved_signals objects - adding
type,severity, anddescriptionper signal. Deferred to v2.x to maintain a lean v2.0 schema. v2.0 uses a string array with a recommended vocabulary. - evidentiary_strength as response field - a server-computed field in the API response that reflects the evidentiary weight of a submitted
boundary_readinessobject. The concept is sound but belongs to the response specification, not the intake schema. - Gate Qualification Framework - a separate methodological sub-specification defining how a gate qualifies itself before it can emit
"verified". This is a discipline document, not a schema extension. It may become a companion document to the EVIDE specification. - minimum_visibility_threshold - a declared minimum surface below which a gate cannot emit
verified_partialand must emitunverifiable. Requires the Gate Qualification Framework to be defined first. - continuity.mode: "qualified" - the
continuitydimension is now live in v2.0 asmode: "inferred"via Forensic Cross-Check (classification × runtime_visibility). When the Gate Qualification Framework defines a direct observation source field,modetransitions to"qualified"- replacing inference with direct evidentiary input. Profile version will advance to 1.1 at that point. - governance-reactive evidentiary states -
unverifiableas conditional escalation state (not failure) is the first documented instance. Formal category definition deferred to v2.x vocabulary specification. - continuity_drift across anchored states - EVIDE can compute and expose continuity transitions between two anchored records via Forensic Cross-Check Delta (
forensic_cross_check_delta). The drift calculation is mathematically possible, but the selection of the comparison baseline is not mathematically neutral - it is a governance act. EVIDE can expose the delta given a declared baseline, but cannot independently determine which comparison baseline is semantically authoritative without inheriting a governance role over the chain itself. The upstream environment must declare thecomparison_policyand its authority. Formal schema definition deferred to v2.x. See also: Critical Questions - classification authority and continuity boundary.
The following items were not schema backlog items. They represented emerging theoretical dimensions being developed within the EVIDE research layer, documented at the time to establish a dated public record of their origin within the EVIDE ecosystem.
Epistemic Stabilization Buffer (ESB)
Status as declared in May 2026: experimental governance schema · research layer
An experimental governance construct that introduces a structured observation window between intake and crystallization. The ESB does not simply delay closure - it actively observes whether evidentiary continuity holds during the window, and makes that observation part of the forensic record.
The foundational semantic distinction of ESB is architectural: buffer_verdict = stable does not mean "true". It means: temporaneamente sufficientemente stabilizzato per crossing - temporarily sufficiently stabilized for boundary crossing. This distinction prevents epistemic overclaim and governance inflation.
Key dimensions under research (as of May 2026):
- Stabilization source hierarchy - who or what produced the stabilization has epistemic weight. A human-reviewed stabilization is not equivalent to an automated timeout, and the ESB record must reflect this difference explicitly.
- Stability trend - not only how stable, but whether stability is improving or degrading during the window. A powerful predictive signal for DWC/FAC analysis over time.
- Continuity state during window - the buffer is not a waiting period. It is an observation of whether internal continuity holds under temporal pressure.
- Closure trigger semantics - a buffer closed by timeout is forensically distinct from a buffer closed by convergence. The mechanism of closure becomes part of the evidentiary record.
- Instability reason taxonomy -
unstablealone is forensically insufficient. The cause of instability - authority conflict, evidence gap, observability loss - determines the appropriate governance response.
"The buffer does not ask whether the object is ready. It asks whether it is still the same object it was when the window opened."
As declared in May 2026: under active experimental development in the EVIDE Governance Lab. Schema version: v_buffer_01. This was the Lab-only research identifier at that time - see below for its current status.
Causal Persistence Signal
An inferential/observational signal - not a judgment - that qualifies whether a subsequent state preserves sufficient causal inertia from its previous degradation path. The signal does not prove falsity. It does not classify truth or error. It observes whether the evolution paid the expected dynamic cost.
"An authentic degradation leaves inertia. If inertia disappears too rapidly, coherence may have been synthetically reconstructed rather than genuinely maintained."
Proposed values: present - attenuated - absent - inconclusive.
Architecturally consistent with anti-synthetic coherence (EVIDE Dim. 9), continuity degradation, and DWC/FAC inference.
The buffer is not a truth engine. It is an observer of causal persistence.
Architectural Layer Separation - May 2026
The ESB operates on two structurally distinct layers that must never be conflated:
- Current / Final State Layer - the buffer record at its most recent or terminal condition. This is what downstream systems consume. It reflects the outcome of the stabilization process.
- Forensic Observation History Layer - an immutable, append-only event log where every intermediate observation during the buffer window is timestamped and stored independently. This layer is never overwritten. It is the audit trail of the stabilization process, and it remains accessible even after the final verdict is declared.
This separation is architecturally necessary: a final verdict of stable must be readable alongside the complete sequence of intermediate observations that produced it - including degrading trends that later recovered, and signals that remained unresolved throughout the window.
Stabilization source epistemic hierarchy (indicative ordering): human review carries higher epistemic weight than automated convergence, which carries higher weight than timeout expiration. A buffer that reaches stable through timeout is forensically distinct from one that reaches stable through declared human review - and the evidentiary record must reflect this difference explicitly.
Formally documented and under experimental validation in the EVIDE Governance Lab, May 2026.
Decision Wave Compression (DWC) and Formal Accountability Collapse (FAC)
Status as declared in May 2026: experimental inferential dimension · research layer
An experimental inferential construct measuring systemic throughput pressure on meaningful oversight capacity. DWC observes whether the volume, velocity, and density of decision closures crossing a governance boundary within a time window is compatible with real human governance - not just formally declared oversight.
Related emerging category: Formal Accountability Collapse (FAC) - the condition in which closure surfaces remain formally stable while the accountability infrastructure surrounding them becomes operationally degraded under compression conditions. FAC does not require misconduct. It measures an emergent structural condition.
"Meaningful oversight has a throughput boundary. Beyond it, oversight continues to exist formally while ceasing to function semantically."
This May 2026 description was subsequently clarified - see the July 2026 panel for what DWC and FAC actually compute, and for the introduction of Oversight Viability Collapse (OVC).
Recursive Semantic Governance (RSG), published May 2026, is a formal framework for preserving accountability across AI boundary transformations, directly grounded in the ESB and DWC/FAC constructs above. Its operational layer, G-LOOP-E, followed in July 2026 - see that panel.
evidence_references extension for declaring external artifacts (screenshots, video, sensor logs) without EVIDE ever storing them - see New in v2.1.
evidence_references extension introduced in v2.1 is now exposed publicly as the External Artifacts capability -- one of the platform's complementary capabilities, documented alongside Epistemic Stabilization Buffer and Verified Human Identity in the EVIDE Use Cases documentation. It allows EVIDE to anchor references to screenshots, video, sensor logs and other external evidence without storing the underlying files, preserving evidentiary separation while extending the range of supported evidence types.
The profile has since advanced to profile_version: "1.1", which carries eleven members: the same nine described in the May 2026 record plus the two inferred dimensions decision_wave_compression (Dim 10) and formal_accountability_collapse (Dim 11). Records stabilized under 1.0 remain valid and complete for their generation — consumers should branch on profile_version rather than assume the two later dimensions are present.
profile_version 1.1 shipped for a reason distinct from the continuity.mode: "qualified" item recorded in the May 2026 backlog — it added the two inferred dimensions DWC (Dim 10) and FAC (Dim 11). The continuity mode remains "inferred", and the transition to "qualified" is still deferred.
POST /api/intake/esb, POST /api/buffer/update, POST /api/buffer/close), documented at app.certifywebcontent.com/api-reference. The Epistemic Stabilization Buffer is now one of the platform's complementary capabilities, documented alongside External Artifacts and Verified Human Identity in the EVIDE Use Cases documentation.
buffer_verdict: stable at 85.0/100 across three timestamped events, with FCC: stable throughout. This validates the buffer's open/observe/close mechanism and its ability to produce a defensible verdict under real conditions. It does not by itself validate the deeper sub-components documented in the May 2026 panel (Causal Persistence Signal, Stabilization Source Hierarchy) -- those remained under active research, undisturbed by this update. Full record: Milestone MS-001.
runtime_visibility × boundary_readiness × unresolved_signals, with states not_detected | detected | critical | unknown. The population-scale model described in the May 2026 panel — volume, velocity and density across a time window — remains a research program and is not what the API emits. The two share a name, not a scope. A fourth, related derived construct has since emerged and is now live: Oversight Viability Collapse (OVC) - a display-time reading of FCC stable combined with DWC critical, distinct from FAC because it is throughput-driven rather than continuity-driven. OVC does not modify the evidentiary profile and is not part of the inferential engine itself; it is a derived interpretation layered on top of it. Formal schema definition for OVC, like the items above, remains deferred to v2.x. Consequence for the May 2026 panel: the paragraph there describing FAC as arising "under compression conditions" predates this split and describes what is now OVC. As implemented, FAC is derived from authority × threshold attribution × continuity and does not read DWC at all. That original wording is preserved in the May 2026 panel as a dated record, not as a current description of the construct.
Current technical definition: Decision Wave Compression - Technical Note
Three Lab milestones (MS-002, MS-004, MS-005) · two controlled calibration experiments, one validated capability · added July 2026
This v2.0 schema's visibility_surface and readiness_gate fields encode structurally what a related family of Lab experiments has since tested empirically: whether, and how, a gate's declared visibility into the conditions it is assessing shapes the formal record it produces.
Observer Reconstructability v0.1 (MS-002) confirmed that FCC and DWC behave as observer-sensitive dimensions under controlled calibration - and, more precisely, that FAC's sensitivity to declared visibility is a designed dependency (FAC requires documented continuity degradation before declaring accountability collapse), not an accidental one.
Authority Visibility Asymmetry v0.2 (MS-004) tested the same question from the other direction: does a party's narrated visibility into who authorized something move the system's findings on its own? Across two severity levels - including the extreme case of an observer declaring zero visibility beyond the bind-time state - the answer held: only concrete, independently structured signals moved the findings, never the narrative itself. Both v0.1 and v0.2 remain controlled calibration experiments, not proof of real-world observer-dependent reconstructability - that requires genuinely independent observers of a real, unplanned event, a condition reserved for a later research stage.
Authority Continuity (v_observer_03 - MS-005) is the one member of this family that has progressed to a validated, operational capability: EVIDE now ingests an externally established authority-continuity dimension through an explicit attestation envelope, confirmed to remain fully isolated from the validated inferential core across all four tested states (intact, degraded, unverifiable, absent).
"A gate that cannot see everything is not the same as a gate that has failed. The record should say which one happened."
Full milestone record: EVIDE Governance Lab Milestones. Business-facing synthesis: EVIDE Working Papers.
G-LOOP-E, the operational layer built on RSG (May 2026), continuously verifies accountability survivability between boundary crossings - and is now validated: MS-006 confirmed the reconstructability engine on 4 of 4 pre-registered test cases, including proof that it evaluates authority independently of FCC rather than as a proxy. Both papers, plus a business-facing synthesis of what all six validated Lab projects mean for legal defensibility, are collected in the EVIDE Working Papers series.
Read the Working Papers →Unlike the research-layer items in the May and July panels, this one was not experimental and not deferred - it shipped to production the same day it was designed.
Status: shipped to production · MCP Server v1.3.0 · August 2026
EVIDE ANCHOR introduces declarations (schema v2.1, opt-in extension): 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. Each Declaration carries a server-computed declaration_digest, and a later Declaration can state that it supersedes, clarifies, or revokes an earlier one via declared_relations, without ever rewriting it.
The underlying primitive, Declaration, is deliberately EVIDE-wide rather than specific to this extension - the same reusable structure (declarant, authority_source, subject_references, declared_at) that evidence_references and Evidentiary Continuity already use in their own form. ANCHOR is the protocol name; Declaration is the primitive underneath it, alongside GLM, FEDIS, and DAPI.
Atomic Declaration Rule: each Declaration should represent one attributable statement. When a request describes multiple independent facts, each is preserved as its own Declaration rather than merged into a composite one - a behavior observed directly during agent testing and formalized as a modeling rule afterward, not decided in the abstract beforehand.
"A declared perimeter is not a permission granted by EVIDE, and its absence does not mean the agent was unauthorized. It anchors what was stated, by whom, and when - never what was true."
Field reference as originally shipped: app.certifywebcontent.com/docs/evide-intake-schema/. MCP tool support: app.certifywebcontent.com/docs/evide-mcp/.
Current canonical documentation: EVIDE ANCHOR - canonical page
Published August 2026: a dedicated use-case page for autonomous physical systems - humanoid robots, cobots, drones, AGVs, medical and surgical robots. It positions EVIDE as an independent evidentiary layer that preserves what a physical AI system reported observing at a declared boundary event, externally timestamped and owner-attributed - not a safety controller, collision-avoidance system, or emergency stop mechanism. Integration is via the EVIDE MCP Server's evide_escalate call, designed to run asynchronously alongside real-time control cycles without blocking physical execution. The page also carries EVIDE ANCHOR's declared-operational-perimeter model into the physical domain (declared operating zone, tool/actuator authorization, prohibited maneuvers) and references the EU Digital Omnibus on AI (Regulation (EU) 2026/1744, in force since 27 July 2026) for regulatory context.
Current canonical documentation: EVIDE for Physical AI
The Epistemic Stabilization Buffer - previously documented only inside this roadmap's research-layer notes (May 2026) and progressively updated in place (July 2026) - now has a dedicated canonical public reference: app.certifywebcontent.com/docs/epistemic-stabilization-buffer/. It documents the construct as currently implemented: the intake-time request fields, the observation cycle, verdict crystallization, its relationship (or lack of one) to the evidentiary profile, and its ownership/non-disclosure boundary.
stability_trend, continuity_state, causal_persistence_signal (with exactly the four values proposed there), closure_trigger, and instability_reason are live fields, and the event log is confirmed insert-only with no update or delete path. v_buffer_01, referenced in the May 2026 panel, was the Lab-only research identifier at the time and is not the current implementation.
The public GLM manifest (https://www.certifywebcontent.com/.well-known/governance-layer-manifest.json) was published as manifest_version 8.0 on 12 September 2026. The vendor_framework_constructs entry for EVIDE:ESB had its canonical_uri updated to point to the new ESB canonical page above. Its label, vendor_local_alias, purpose, and version were carried forward unchanged from their original May 2026 wording. No other vendor framework construct was modified as part of the manifest 8.0 publication.
A GLM-aware system fetching the manifest and following canonical_uri for the vendor-local alias EVIDE:ESB now arrives at the dedicated ESB reference page instead of at this roadmap's general v2.0 backlog. The previous manifest version (7.0) is archived at /.well-known/archive/governance-layer-manifest-v7.json, consistent with the manifest's own historical-anchoring policy.
EVIDE Mobile, the official mobile client of the EVIDE platform, is now available on both stores: Android was already live on Google Play, and the iOS build was approved and published to the Apple App Store on 12 September 2026. It operates on the same records and within the same evidentiary environment as the web platform - not a separate archive. Built around four capabilities: persistent sign-in on the device, search and review of previous intakes with evidentiary status visible at a glance, Human Structured Intake directly from the field, and Case Navigator for following registered relationships between linked intakes and certifications node by node.
Download and full feature list: app.certifywebcontent.com/evide-mobile
The complete Human Structured Intake (HSI) reference guide was published in September 2026, in five languages (English, Italian, French, German, Spanish). It documents every field of the Human Structured evidentiary model - decision type, authority role and identifier, classification and threshold status, boundary readiness, unresolved signals - each verified individually against HumanStructuredIntakeService.php, with seven enterprise use cases (compliance, SOC, HR, fraud prevention, industrial, AI governance, incident response) illustrating what EVIDE's preservation of a declared human decision does and does not establish.
Current canonical documentation: Human Structured Intake - Complete Guide
For constructs that now have their own canonical reference, this is where their current technical definition lives - not in this roadmap.
EVIDE v2.1 is the current and only accepted public schema. v1.8, v1.9, and v2.0 are historical and no longer accepted.
For questions on v2.0 architecture: info@informaticainazienda.it