EVIDE - Closure Layer: Definition, Scope & Non-Claims
- 0. Why EVIDE Exists
- 0b. Forensic Implications
- 1. Definition
- 2. Timing-Axis Position
- 3. Core Function
- 4. Failure Mode Protected Against
- 5. Explicit Non-Claims
- 6. Observational-Quality Semantics
- 7. Continuity State Inheritance Matrix
- 7b. Closure surface vs continuity substrate
- 8. Consumer-Boundary Invariant
- 9. Composability with Adjacent Layer Types
- 10. Schema Reference
- 11. FEDIS - Optional Forensic Declaration
It standardizes the minimum evidentiary object that can survive outside the source system.
Modern systems increasingly preserve operational continuity even when the original legitimacy conditions behind continuation have degraded, drifted, or become partially unverifiable. A system can keep producing output, maintaining workflow stability, and appearing structurally sound - while the authority, oversight, and evidentiary basis for that continuation have silently shifted.
In this environment, the critical question is no longer only "Is the system working?" but "Does this continuation still have standing to produce consequence?" Operational persistence is not proof of legitimacy. Behavioral completion is not responsibility closure.
EVIDE exists to preserve the accountable closure state before post-event reconstruction, institutional memory, downstream interpretation, or operational continuity silently replace the contemporaneous responsibility configuration that existed when consequence became real. It does not prevent this drift from occurring. It creates an independently verifiable record -- an independent crystallization of the governance conditions that existed at the moment consequence became real -- that makes the drift visible and challengeable from outside the originating system.
at the moment it was externalized."
The following four implications explain why the closure layer architecture addresses challenges that traditional logging, behavioral monitoring, and execution certification cannot resolve -- in judicial, regulatory, and audit contexts.
1. Behavioral completion vs. responsibility closure
Traditional logging systems record continuous behavioral data streams. What courts and regulators require is not a replay of the execution flow -- it is the isolation of the minimum evidentiary object that describes the exact conditions of responsibility at the moment the decision began producing legal or material effects. EVIDE positions itself precisely at that crossing-time boundary, requiring the source system to declare a finalized closure state rather than producing continuous runtime telemetry.
2. Classification Replay: resolving the black-box problem
Each closure record anchors not only the output but the exact version of the risk taxonomy, threshold references, and classification context active at that precise moment. If a decision appears anomalous during audit or litigation, the closure layer enables Classification Replay -- allowing an expert to reconstruct the original governance context without accessing the source system's runtime. Where no rules were defined upstream (threshold_status: not_defined), the record surfaces a structural governance gap rather than attributing fault to an isolated human error.
3. Deterministic canonicalization: a hash that does not depend on formatting
A difference in key ordering, whitespace or character escaping between two serializations of the same JSON payload changes its cryptographic hash, even though the declared content is the same. EVIDE canonicalizes every payload server-side before hashing -- recursive byte-wise key sorting, minification, and a deterministic sort of the extensions and evidence_references arrays -- so that payloads differing only in key order, whitespace or escaping produce the same intake_hash. The sort of the two arrays has a limit: items with equal sort keys keep their submitted order, so swapping them can still change the hash. Anyone holding the record can recompute the hash with the published algorithm (Payload Canonicalization), without depending on how the transmitting software formatted the JSON. This removes one class of technical objections to the hash; whether the record is accepted as evidence, and with what weight, remains for the court or competent authority to assess.
4. Authority vs. execution identity: accountability without surveillance
The closure layer separates two architecturally distinct identities: the authority (the human or organization declared as responsible for the decision, whose identifier, role and powers are recorded as declared, not verified) and the execution identity (the autonomous agent or software system that materially produced the closure object). This separation addresses the labor law and privacy friction directly: the infrastructure does not monitor or surveil employee behavior during their workflow. It asks only that the responsible party formally validate the governance closure of the transaction for which the organization has established accountability. The surveillance concern applies to continuous behavioral tracking -- not to a single, declared, responsibility-bearing closure event.
EVIDE is the closure layer.
Its function is to stabilize the responsibility-bearing closure state once a finalized, attributable decision has reached closure - and to externalize that state as a portable, reconstruction-independent unit -- a crystallization of the accountable configuration at closure time -- that can be verified, challenged, and reviewed from outside the system that produced it.
EVIDE does not resolve admissibility.
It does not supervise execution.
It does not witness governed-state conditions before bind.
It stabilizes the accountable configuration at the moment responsibility closes, and carries that state forward as the canonical record.
The layer exists to prevent post-event reconstruction from silently replacing contemporaneous accountability.
Within any runtime-separation governance model, each layer operates at a precise position on the bind-time axis. EVIDE's position is explicitly post-bind.
| Layer type | Timing surface | Function |
|---|---|---|
| Substrate layer | Pre-bind | Independently corroborated behavioral history - records what entities have done over time, queryable at decision time |
| Witness layer | Before-or-at bind | Independent governed-state evidence around the boundary conditions - policy posture, authority state, tool access, oversight configuration |
| Boundary layer | At bind | Admissibility resolution - produces ALLOW / ESCALATE / REFUSE before consequence commits |
| EVIDE (closure layer) | Post-bind | Evidentiary closure stabilization - responsibility-bearing closure state after the boundary condition has resolved |
EVIDE stabilizes as independently reviewable closure artifacts external to the source system:
- responsibility-bearing closure states
- declared authority conditions
- declared oversight conditions
- intervention and classification context
- observational-quality semantics
- decision wave compression detection (DWC — Dim 10)
- formal accountability collapse detection (FAC — Dim 11)
- evidentiary readiness state
The layer preserves the accountable configuration as it existed at closure time rather than reconstructing it later from logs, memory, or downstream interpretation.
Integrity Invariant: The intake object is stored as decoded at intake, and its intake_hash is computed at that moment on its canonical form. The evidentiary_profile computed server-side is kept separate as an interpretive layer: it is not part of the canonical form and does not change the intake_hash. A later alteration of the stored intake object can be detected by recomputing the hash and comparing it with the intake_hash returned to the source system at intake, provided that this reference value has been kept separately and reliably. The comparison reveals a mismatch with that reference: if the record and its stored digest were altered together, a comparison made only against data held in the same system could still match.
Each closure artifact receives:
- evide_id - stable external identifier, independent of the source system's reference
- intake_hash - SHA-256 of the canonical form of the received payload, computed by EVIDE at intake, independent of the
content_hashdeclared by the source system - intake_timestamp_utc - EVIDE-side temporal anchor, independent of the source system's clock
- authority_verification_status -
claimedwhen the payload carries anauthority.verificationreference, which is recorded but not validated server-side;declaredotherwise. The value does not reflect the account check described below.
authority.dapi_number is required and must match the DAPI number associated with the account that owns the API key; otherwise the intake is refused (dapi_mismatch). In the human structured intake, the DAPI number is taken from the logged-in account. This binds the deposit to the authenticated account, whatever the value of authority_verification_status. It does not verify that authority.id, the declared role or the powers exercised are legitimate: those remain declarations.
Without a closure layer, logs, explanations, retrospective narratives, and downstream interpretations can silently replace the contemporaneous accountable state that existed when consequence became real.
The dangerous transition is not explicit falsification. It is gradual certainty inflation across interoperating layers:
- One layer declares
- Another preserves
- Another operationalizes
- Eventually the ecosystem treats accumulated declarations as stronger than the observable conditions ever justified
The distinction is structural: behavioral completion can be reconstructed from logs. Responsibility closure cannot be reconstructed without losing the evidentiary value of its contemporaneous existence.
EVIDE prevents this by stabilizing the closure state at the moment responsibility closes and anchoring it externally as a reconstruction-independent evidentiary object.
These are structural non-claims. Each represents a function that belongs to an adjacent layer type, not to EVIDE.
authority.verification reference is recorded as claimed, not validated.
EVIDE v1.9 recorded that a boundary was validated. EVIDE v2.0 records the observational quality of the validation itself.
The key problem: validation layers can implicitly overclaim stability beyond the portion of the system they could actually observe. If EVIDE records that a boundary was validated without recording what portion of the system the validation could actually see, then "validated" silently overclaims. Making the visibility surface part of the evidentiary object keeps the closure layer honest without pulling it upstream into governance or admissibility.
v2.0 makes the evidentiary quality of the boundary explicit."
Since v2.0, the closure artifact carries:
- gate identity - the identity of the validation gate that assessed boundary readiness
- gate scope reference - what portion of the upstream system the gate could actually observe
- declared visibility surface - what conditions were within the gate's observational reach (
declared_complete/partial/insufficient) - unresolved signals - conditions that could not be confirmed at validation time
- canonical evidentiary state -
verified/verified_partial/candidate/unverifiable
"verified" from silently implying complete visibility, and prevents opacity from being collapsed into either false stability or automatic failure. In audit or legal contexts, these elements can be examined in the later assessment; the status alone does not demonstrate diligence or exclude negligence. The uncertainty remains preserved as an evidentiary object rather than converted into a clean authorization state.
rather than converted into a clean authorization state."
EVIDE computes a continuity dimension within the server-side evidentiary_profile via Forensic Cross-Check - an inferred anti-Synthetic-Coherence sensor derived from the intersection of classification state and runtime_visibility.
This mechanism prevents a closure object from appearing stable in the evidentiary record when the classification and visibility signals do not jointly support that stability claim.
confirmed
partial
unverifiable
runtime_visibility is not a submitted field. It is derived server-side from handoff.boundary_readiness.visibility_surface: declared_complete maps to confirmed, partial to partial, insufficient to unverifiable. Because intake validation binds visibility_surface to boundary_readiness.status, each column also corresponds to exactly one readiness state: verified, verified_partial, unverifiable.
stable classification while the independent gate reports it could observe only part of the surface (verified_partial). The Forensic Cross-Check surfaces that asymmetry in the evidentiary_profile.continuity dimension as Degraded rather than Stable - preventing synthetic certainty from silently inflating evidentiary strength across composed layers. A contested classification produces Broken at every visibility level: no observational quality repairs a classification that is itself disputed.
provisional classification meets an unverifiable surface - the two signals cannot be related to each other - and whenever either input is missing entirely, which is the case for boundary_readiness: candidate, where visibility_surface must be null. Consumers should treat Unknown as "no conclusion was reached", distinct from any of the three graded states.
Note: the continuity dimension (Dim 9) operates in mode: "inferred". Since profile_version: "1.1" the profile carries two further inferred dimensions: Decision Wave Compression (DWC — Dim 10) and Formal Accountability Collapse (FAC — Dim 11). States for Dim 10-11: not_detected | detected | critical | unknown. When the Gate Qualification Framework (deferred to v2.x) defines a direct observation source, the continuity mode transitions from "inferred" to "qualified".
while continuity conditions underneath it
are already degraded at crossing time.
This is the most important distinction introduced in EVIDE v2.0. Two surfaces coexist inside every closure artifact:
The closure object is formally valid: authority declared, decision finalized, handoff completed, intake hash computed. The system produced a structurally complete evidentiary object.
The runtime conditions beneath the closure — visibility, classification coherence, oversight throughput, attribution integrity — may have degraded before or during externalization. The Forensic Cross-Check surfaces this tension.
Before v2.0, a degraded continuity substrate was invisible inside a structurally intact closure. The evidentiary object appeared clean because structural completeness and continuity integrity were not distinguished.
The evidentiary_profile separates these two surfaces explicitly:
- Closure surface is assessed by the declared fields —
authority,classification,threshold,boundary_readiness. These can all be structurally present. - Continuity substrate is assessed by the inferred dimensions —
continuity(Dim 9),decision_wave_compression(Dim 10),formal_accountability_collapse(Dim 11). These expose whether the conditions beneath the declared surface were coherent at the moment of crossing.
boundary_readiness: verified_partial + classification: stable + continuity: degraded + dwc: detectedis not a contradiction. It is an accurate evidentiary picture: the closure is structurally complete and an independent gate did assess the boundary, but that gate declared it could observe only part of the surface — so the responsibility coherence beneath the closure was already degraded at the moment it was externalized. This is precisely what EVIDE is designed to make visible — not to prevent, and not to collapse into binary pass/fail.
This is the architectural core of the closure layer: the closure layer now preserves both the surface of the closure and the substrate conditions under which it was formed. A third party reviewing the record can distinguish structural completeness from continuity integrity — and that crystallization survives outside the originating system.
EVIDE outputs must not be interpreted by downstream consumers as:
- execution authorization
- admissibility certification
- runtime-governance approval
- inherited authority transfer of any kind
The closure artifact preserves evidentiary accountability only within the explicitly declared scope of the layer. No downstream consumer may silently upgrade evidentiary stabilization into execution authority.
Implementation patterns that route an EVIDE closure artifact directly into an execution decision path without independent authority resolution are structural failures - they violate the no-authority-transfer invariant that any well-composed governance architecture must maintain.
EVIDE is designed to compose with any governance architecture that implements the following layer types, regardless of the specific system providing them.
intake_hash can compare them without accessing EVIDE, the source system, or any upstream layer. A match shows that the record corresponds to that hash; it does not by itself establish that the hash is the authentic reference value.Since v2.0, boundary_readiness is a structured object rather than a string. This is the central schema change that introduces observational-quality semantics into the evidentiary record.
| status | visibility_surface | unresolved_signals | Evidentiary meaning |
|---|---|---|---|
| candidate | null | [] | Upstream declares readiness. No independent gate assessment. |
| verified | declared_complete | [] | Gate confirmed stability across declared scope. Maximum evidentiary strength. |
| verified_partial | partial | [min. 1] | Gate confirmed what it could see. Gaps are part of the record. |
| unverifiable | insufficient | [min. 1] | Gate attempted but surface was below threshold. Records the declared visibility limit and the gate reference; it is neither proof of diligence nor a failure. |
Full schema: app.certifywebcontent.com/json - API documentation: app.certifywebcontent.com/docs/evide-intake-schema/
Closure artifacts stabilized by EVIDE are structured for independent verifiability outside the source system. For legal, compliance, and LegalTech contexts, an EVIDE record can be the subject of a FEDIS (Forensic Evidence Declaration and Integrity Statement): an optional forensic document, issued through a separate certification process and intended to support the record's later examination. Setting fedis_requested: true submits a request for evaluation and a separate quote; it does not generate or issue FEDIS. The platform generates the document only after the certifier explicitly initiates generation.
A FEDIS document includes:
- the SHA-256 fingerprints of the record's canonical JSON (its intake_hash) and of the frozen Evidentiary Artifact Record (EAR);
- a chain-of-custody section and the certifier's declaration, citing ISO/IEC 27037:2012 among its reference frameworks;
- the certifier's qualified electronic signature (eIDAS Art. 25) and, as a distinct step, a qualified electronic time stamp (eIDAS Art. 41) issued by a third-party qualified trust service provider;
- the L3 (Forensic) level of the HOE (Human Oversight Event) taxonomy.
The time stamp attests the moment at which it is applied to the FEDIS document: it does not make the intake timestamp qualified, does not date the original event and does not prove that the content is true. FEDIS does not alter the evidentiary object: the intake record and its intake_hash stay as they are, and FEDIS adds a signed document that refers to them and can be verified on its own.
FEDIS documentation: EVIDE vs Execution Certification