Architecture Guide

Documentation › Architecture Guide

EVIDE anchors what was declared, not whether it was correct. Every architectural choice below follows from that one distinction.

Architectural Principles

This guide documents why EVIDE's schema and workflows are shaped the way they are — the reasoning behind specific fields, states, and boundaries. For field definitions and payload construction, see the JSON Schema Reference. For endpoints and intake profiles, see the API Reference.

Boundary Readiness

The following notes explain the reasoning behind boundary_readiness across both v1.9 (string value) and v2.0 (structured object). For the field definitions themselves, see the JSON Schema Reference.

boundary_readiness and runtime conditions - architectural rationale

EVIDE anchors closure states, not runtime states. It does not monitor conditions after anchoring and does not introduce runtime governance.

"They come from anchoring something that was already drifting at the moment it was externalized."

This is the failure mode that boundary_readiness is designed to prevent. The distinction between "candidate" and "verified" carries a precise architectural meaning: it declares whether the runtime conditions that grounded the closure state were independently confirmed as still stable at the moment of boundary crossing - not whether the decision itself was correct.

A system cannot evaluate its own boundary readiness and declare it "verified". That evaluation must come from a gate that is independent of the system that produced the decision. If no such independent confirmation exists, "candidate" is the correct and complete value - not a fallback.

This distinction preserves the separation between runtime governance and evidentiary anchoring: EVIDE does not prevent instability from forming upstream. It makes the boundary condition independently observable at the exact moment of externalization.

boundary_readiness and runtime conditions — architectural rationale (v2.0)

EVIDE anchors closure states, not runtime states. It does not monitor conditions after anchoring and does not introduce runtime governance.

"They come from anchoring something that was already drifting at the moment it was externalized."

In v2.0, this failure mode is addressed more precisely. The gate's own observational capacity becomes part of the evidentiary record. What the gate could not see is declared explicitly in unresolved_signals — it is no longer a hidden assumption but a documented variable.

A system cannot self-certify boundary_readiness.status = "verified". That evaluation must come from an independent gate declared in readiness_gate.identifier. If the gate's visibility was incomplete, the honest state is verified_partial with declared gaps — not verified.

unverifiable is not a failure state. It is the most forensically honest state when an independent gate operated but the source system was too opaque to confirm boundary stability.

Gate independence is a governance qualification, not a self-declared payload field in v2.0. Formal gate qualification is deferred to the v2.x Gate Qualification Framework.

Unverifiable States

Interpretation of unverifiable downstream

The <code>unverifiable</code> state operates at the deposit boundary, not downstream.

At deposit time, it functions as a documentation quality marker. The record itself remains valid, but explicitly captures that the stability of the declared state could not be independently confirmed at the moment of crossing.

What happens downstream is intentionally outside EVIDE’s scope. An auditor, admissibility framework, compliance system, or governance layer may decide to treat an <code>unverifiable</code> record as:

– a review flag
– a degraded input
– a condition requiring escalation
– or an acceptable state under specific operational constraints

EVIDE makes the condition persistent and queryable. The behavioral consequence of that condition belongs to the system that consumes the record, not to EVIDE itself.

Closure interpretation at evidentiary boundary

This section clarifies how closure states should be interpreted at the evidentiary level.
EVIDE does not define or enforce closure types. It exposes the conditions required to distinguish them.

In practice, two distinct closure conditions may exist upstream:

Behavioral completion - the process has reached an outcome
Responsibility closure - the outcome is explicitly bound to an authority

EVIDE does not introduce a dedicated field to represent this distinction. Instead, it allows it to be inferred from the presence or absence of structural elements in the payload.

Behavioral completion

"decision": {
  "status": "finalized"
}

A finalized decision without a bound authority and declared human oversight represents behavioral completion only. The system has produced an outcome, but no accountable actor is formally attached to it.

Responsibility closure

"decision": {
  "status": "finalized"
},
"authority": {
  "id": "...",
  "role": "..."
},
"human_oversight": {
  "is_declared": true
}

A finalized decision with a bound authority and declared human oversight represents responsibility closure. The outcome is not only produced, but explicitly attributable.

EVIDE does not define closure types.
It makes visible whether a decision is merely completed or formally attributable.

The Layer 2 → Layer 3 boundary requires responsibility closure, not behavioral completion.
This distinction is not enforced by EVIDE, but made observable through the payload structure.

Recommended classification combinations (structural completeness patterns)

The following combinations are provided as implementation guidance only.
They do not introduce validation logic. EVIDE does not enforce any combination as valid or invalid.
Their purpose is to make structural completeness visible, not to evaluate correctness.

This section defines observable patterns of structural completeness, not rules of admissibility.

1. Complete and stable classification

"classification_status": "stable",
"classification_context": {
  "taxonomy_reference": "https://example.org/taxonomies/rationale-types-v1.0",
  "threshold_reference": "https://example.org/rules/hr-review-threshold-v1",
  "threshold_status": "met"
}

The classification is operationally stable and anchored to a defined upstream taxonomy and threshold rule. This is the strongest evidentiary state: both the operational condition and the structural grounding are visible.

2. Stable classification - no upstream structure visible at deposit time

"classification_status": "stable",
"classification_context": {
  "taxonomy_reference": null,
  "threshold_reference": null,
  "threshold_status": "unknown"
}

The classification is considered stable by the source system, but no upstream structure is visible at deposit time. The gap is exposed, not evaluated. EVIDE does not judge the classification - it records that no structural reference was anchored alongside it.

3. Provisional classification with visible upstream structure

"classification_status": "provisional",
"classification_context": {
  "taxonomy_reference": "https://example.org/taxonomies/rationale-types-v1.0",
  "threshold_reference": "https://example.org/rules/review-threshold-v1",
  "threshold_status": "met"
}

An upstream structure exists and is visible, but the classification itself is not yet operationally stable. The structural grounding is present - the operational state is still pending resolution.

4. Contested classification with defined structure

"classification_status": "contested",
"classification_context": {
  "taxonomy_reference": "https://example.org/taxonomies/rationale-types-v1.0",
  "threshold_reference": "https://example.org/rules/review-threshold-v1",
  "threshold_status": "met"
}

The classification is disputed, but the upstream taxonomy and threshold context remain visible. The existence of a defined structure does not resolve the dispute - it makes the dispute interpretable against a stable reference.

5. Stable classification - taxonomy present, no threshold defined

"classification_status": "stable",
"classification_context": {
  "taxonomy_reference": "https://example.org/taxonomies/rationale-types-v1.0",
  "threshold_reference": null,
  "threshold_status": "not_defined"
}

A taxonomy exists and is referenced, but no upstream threshold was defined for this classification. This may indicate a governance maturity gap upstream - the classification system exists, but the admissibility condition has not yet been formally specified. EVIDE makes this condition visible without making EVIDE responsible for resolving it.

EVIDE does not decide whether a classification is correct.
It makes the presence or absence of structural grounding visible.

These combinations describe how that visibility appears in practice.
They are not validation rules.

Threshold Authority — architectural rationale

A threshold can exist even when the authority that established it cannot be formally attributed.

EVIDE does not evaluate whether a threshold is correct. It documents whether responsibility for that threshold was structurally attributable at the moment of deposit.

Four observable conditions, not four judgments:

attributed — a single identifiable authority was formally defined
fragmented — defined across multiple sources, no single attributable authority
implicit — present in practice but never formally defined
unknown — not verifiable at the moment of closure

Threshold Authority does not determine whether a threshold is valid. It makes visible whether responsibility for that threshold was structurally attributable at boundary crossing.

Forensic Cross-Check (FCC) and baseline authority

EVIDE computes continuity deltas across anchored states. It does not determine which baseline is authoritative.

The selection of the comparison baseline is a governance act, not an evidentiary one.

This separation is not incidental. It prevents EVIDE from collapsing into a semantic authority layer, keeps comparison policy explicitly upstream-governed, and preserves the Forensic Cross-Check in its correct architectural role: observer of continuity states, not decider of which states carry governance weight. That governance authority remains upstream.

⚠ Planned — not part of the active v2.1 schema. Deferred to v2.x.

"continuity_drift": {
  "mode": "post_derived",
  "comparison_policy": "externally_declared",
  "comparison_policy_authority": "declared_by_upstream",
  "baseline_reference": "EVIDE-0012",
  "current_reference": "EVIDE-0048",
  "baseline_state": "stable",
  "current_state": "degraded",
  "delta": "negative",
  "function": "forensic_cross_check_delta"
}

Different comparison policies may produce different continuity deltas across the same chain. Examples include: last_sequential, last_known_stable, or externally_declared.

EVIDE exposes the observable drift between states. It does not decide which baseline carries governance authority. The upstream environment must declare the comparison_policy and its authority before EVIDE can expose a governance-qualified continuity delta.

Architectural principle:
EVIDE computes the delta. It does not select the baseline.
The baseline selection is a governance act, not an evidentiary one.

Ready to deposit?

Access the portal Try the demo