EVIDE
← Back to Signals
Architectural Backlog
In Active Architectural Definition

EVIDE v2.0 — Roadmap

boundary_readiness Quality Layer — Gate Qualification Framework
Public specification v2.0 · May 2026 · Current schema: v2.0
This document describes the architectural transition from EVIDE v1.9 to EVIDE v2.0. The v2.0 schema is now the current public schema. v1.8 and v1.9 remain supported for compatibility - app.certifywebcontent.com/json.
Contents
"v1.9 made the boundary explicit.
v2.0 makes the evidentiary quality of the boundary explicit."
Section 1
1. The Problem v2.0 Solves

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 insight from the v2.0 design process: The solution is not to add runtime monitoring to EVIDE. EVIDE must not become a runtime governance engine. The solution is to make the gate's own observational capacity part of the evidentiary record — so that the limits of what the gate could see become a declared variable, not a hidden assumption.
"They come from anchoring something that was already drifting at the moment it was externalized."

— Key phrase from the GRANT group validation process, May 2026

Section 2
2. Core Change — boundary_readiness as Structured Object

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.

v1.9 — current
"boundary_readiness": "verified" // string
v2.0 — proposed
"boundary_readiness": { // promoted to object "status": "verified", "readiness_gate": { "identifier": "GateSystem-v1.2", "scope_reference": "https://example.org/gate-policy/boundary-v1" }, "visibility_surface": "declared_complete", "unresolved_signals": [] }

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.

Migration path: Systems integrating with EVIDE v1.9 today should treat the string value of boundary_readiness as the future boundary_readiness.status field. The migration will be straightforward for any well-structured integration.
New fields introduced
  • readiness_gate.identifier — identifies the system or mechanism that performed the boundary readiness assessment. Separates the decision authority from the gate authority. Required when status is not candidate.
  • 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, not complete — 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 status is verified_partial or unverifiable.
Section 3
3. Schema Preview

The four canonical states of boundary_readiness.status in v2.0, with their complete object representations:

candidate — no gate has operated
"boundary_readiness": { "status": "candidate", "readiness_gate": null, "visibility_surface": null, "unresolved_signals": [] }
verified — gate confirmed, declared_complete visibility
"boundary_readiness": { "status": "verified", "readiness_gate": { "identifier": "GateSystem-v1.2", "scope_reference": "https://example.org/gate-policy/boundary-v1" }, "visibility_surface": "declared_complete", "unresolved_signals": [] }
verified_partial — gate confirmed, partial visibility with declared gaps
"boundary_readiness": { "status": "verified_partial", "readiness_gate": { "identifier": "GateSystem-v1.2", "scope_reference": "https://example.org/gate-policy/boundary-v1" }, "visibility_surface": "partial", "unresolved_signals": ["downstream_propagation_state"] }
unverifiable — gate operated but surface was insufficient
"boundary_readiness": { "status": "unverifiable", "readiness_gate": { "identifier": "GateSystem-v1.2", "scope_reference": "https://example.org/gate-policy/boundary-v1" // recommended }, "visibility_surface": "insufficient", "unresolved_signals": ["downstream_propagation_state", "rollback_viability"] }
On 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:

"handoff": { "boundary_readiness": { // promoted from string in v2.0 "status": "verified_partial", "readiness_gate": { "identifier": "GateSystem-v1.2", "scope_reference": "https://example.org/gate-policy/boundary-v1" }, "visibility_surface": "partial", "unresolved_signals": ["downstream_propagation_state"] }, "reconstruction_independence": "declared", // unchanged from v1.9 "submission_status": "not_submitted", // unchanged from v1.9 "acceptance_status": "not_claimed" // unchanged from v1.9 }
Section 4
4. Canonical States
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.
On evidentiary strength ordering: 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.
Section 5
5. Validation Rules
  • status: "candidate" — readiness_gate must be null. visibility_surface must be null. unresolved_signals must be empty.
  • status: "verified" — readiness_gate must be present with identifier. visibility_surface must be "declared_complete". unresolved_signals must be empty.
  • status: "verified_partial" — readiness_gate must be present with identifier. visibility_surface must be "partial". unresolved_signals must contain at least one element.
  • status: "unverifiable" — readiness_gate must be present with identifier. visibility_surface must be "insufficient". unresolved_signals must contain at least one element. readiness_gate.scope_reference is strongly recommended.
  • verified cannot be self-certified — readiness_gate.identifier must reference a system or mechanism external to the system that produced the decision.
  • unresolved_signals values — 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.
On the requirement for [min. 1] in unresolved_signals: A record that declares 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.
Section 6
6. What Does Not Change

v2.0 introduces one structural change only. Everything else in the EVIDE schema remains identical to v1.9:

  • All fields outside handoff.boundary_readiness are unchanged
  • handoff.reconstruction_independence — unchanged
  • handoff.submission_status — unchanged
  • handoff.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.
Architectural separation preserved: v2.0 does not transform EVIDE into a runtime governance engine. It extends EVIDE's ability to record the observational capacity of the gate that validated the boundary — without making EVIDE responsible for what the gate observed.
Section 7
7. Contributor Record

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.

Dan Storbaek - first signal
May 2026 · Partial visibility problem · Gate observability
First to identify that "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.
Pascal Berchem
May 2026 · Admissibility persistence · Runtime dependency analysis
Identified that the existence of 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.
Section 8
8. Deferred to v2.x

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, and description per 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_readiness object. 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_partial and must emit unverifiable. Requires the Gate Qualification Framework to be defined first.
Current status
In Active Architectural Definition

EVIDE v2.0 is now the current public schema. The intake API supports v1.8, v1.9 and v2.0 payloads for compatibility.

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