EVIDE v2.0 - Roadmap
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.
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.
Update, July 2026: the profile has since advanced to profile_version: "1.1", which carries eleven members: the same nine 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.
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.
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.
- 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. Update, July 2026:profile_version1.1 has since shipped for a different reason — it added the two inferred dimensions DWC (Dim 10) and FAC (Dim 11). Thecontinuitymode remains"inferred", and the transition to"qualified"is still deferred. - 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.
Unlike the research-layer items below, this one is not experimental and not deferred - it shipped to production the same day it was designed.
EVIDE ANCHOR - Operational Perimeter Declarations
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."
Full field reference: app.certifywebcontent.com/docs/evide-intake-schema/. MCP tool support: app.certifywebcontent.com/docs/evide-mcp/.
The following items are not schema backlog items. They represent emerging theoretical dimensions being developed within the EVIDE research layer. They are documented here to establish a dated public record of their origin within the EVIDE ecosystem.
Epistemic Stabilization Buffer (ESB)
Status: experimental governance schema · research layer · May 2026
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 below (Causal Persistence Signal, Stabilization Source Hierarchy) -- those remain under active research, undisturbed by this update. Full record: Milestone MS-001.
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:
- 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."
Under active experimental development in the EVIDE Governance Lab. Schema version: v_buffer_01.
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: experimental inferential dimension · research layer · May 2026
runtime_visibility × boundary_readiness × unresolved_signals, with states not_detected | detected | critical | unknown. The population-scale model described in the May 2026 text below — 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 text below: the paragraph 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. The original wording is preserved here as a dated record, not as a current description of the construct.
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."
Full technical note: Decision Wave Compression - Technical Note v0.1
Observer-Dependent Reconstructability, Declared Visibility & Authority Continuity
Status: 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.
EVIDE v2.1 is now the current and only accepted public schema. v1.8, v1.9, and v2.0 are historical and no longer accepted.
Current schema reference: app.certifywebcontent.com/json
API documentation: app.certifywebcontent.com/docs/evide-intake-schema/
For questions on v2.0 architecture: info@informaticainazienda.it