← Back to Signals
Evidentiary Construct
Stable

Forensic Cross-Check (FCC)

Server-computed evidentiary inference mechanism for continuity stabilization quality
EVIDE Framework · Evidentiary profile, Dimension 9 · Introduced: EVIDE v2.0 · Emanuel Celano, Informatica in Azienda
First authenticated record: May 15, 2026 — Forensic Cross-Check (FCC) was introduced as a server-computed evidentiary inference mechanism in EVIDE v2.0. This page constitutes the canonical public reference for the FCC construct within the EVIDE framework and the GLM vendor_framework_constructs declaration.
FCC is a server-inferred dimension. It is not a payload field submitted by the intake system. It is computed by EVIDE from the structural relationship between the declared classification and the observational surface declared inside boundary_readiness.
Section 1
1. What FCC Is

The Forensic Cross-Check (FCC) is a server-computed evidentiary inference mechanism introduced in EVIDE v2.0. It occupies position nine of the EVIDE evidentiary profile and is exposed under the profile key continuity.

FCC evaluates the structural coherence of a closure surface by cross-checking two dimensions against each other: the classification of the decision being stabilized, and the runtime visibility of the conditions under which it was made.

The result is a four-state inference — stable, degraded, unknown, broken — that becomes part of the evidentiary record at the moment of stabilization. It cannot be submitted, overridden, or modified by the intake system.

FCC does not evaluate what was decided.
It evaluates whether the conditions under which it was decided
are structurally coherent with the classification claimed.
The distinction is architecturally critical. FCC is an observer of continuity states, not a decider of correctness.
Section 2
2. The Inference Mechanism

FCC is derived from a cross-dimensional matrix. The two input dimensions are:

  • classification — taken from intervention.classification_status. Declared by the intake system. Values: stable, provisional, contested.
  • runtime_visibilitynot a submitted field. The intake system declares handoff.boundary_readiness.visibility_surface; EVIDE maps that declaration onto the runtime visibility dimension used by the inference.
Integration note: there is no runtime_visibility field to submit. It appears in the response profile because EVIDE derives it. The field you declare is handoff.boundary_readiness.visibility_surface.
Declared surface → derived dimension
// handoff.boundary_readiness.visibility_surface → runtime_visibility "declared_complete"confirmed "partial"partial "insufficient"unverifiable // any other value, or absent → runtime_visibility is null

The cross-check detects structural incoherence: a decision classified as stable under conditions declared insufficient produces a different FCC output than the same classification under declared_complete conditions. The asymmetry between what is claimed and what is observable is exactly what FCC is designed to surface.

Profile output shape
"continuity": { "mode": "inferred", "state": "stable", "derivation": "classification_x_runtime_visibility", "function": "forensic_cross_check" }
The inference is structural, not arithmetic. FCC does not produce a numeric score. It produces a categorical state that reflects the qualitative relationship between declared classification and derived observational conditions. This intentional design choice prevents false precision and makes the output forensically defensible.
Section 3
3. The Four FCC States

The complete implemented matrix. Every reachable combination is listed; there are no other paths.

classificationruntime_visibilityFCC state
stableconfirmedstable
stablepartialdegraded
stableunverifiabledegraded
provisionalconfirmeddegraded
provisionalpartialdegraded
provisionalunverifiableunknown
contestedanybroken
absent or unrecognisedanyunknown
anyabsent or unrecognisedunknown
stable
Classification and runtime visibility are structurally coherent. The declared observational conditions are consistent with the classification claimed. The closure surface is structurally coherent for evidentiary review.
reached only by: classification = stable AND runtime_visibility = confirmed
degraded
The claim and the observational surface do not fully support each other. Either a stable classification was closed under conditions that were not fully observable, or a provisional classification was closed under conditions that were. The evidentiary record is reconstructable but carries partial observational confidence. Downstream use should account for this limitation.
reached by: stable + (partial | unverifiable), or provisional + (confirmed | partial)
unknown
The structural relationship between what was claimed and what was observable cannot be established. This covers both a provisional classification closed under unverifiable conditions, and the case where either input is missing or unrecognised. The closure record exists but its evidentiary confidence is materially limited.
reached by: provisional + unverifiable, or either input absent
broken
The classification is contested. The closure surface exhibits structural incoherence under the cross-check regardless of how good the observational conditions were. Full remediation is recommended before the record can be relied on as structurally coherent evidence.
reached by: classification = contested, at any visibility level
What FCC states are not: FCC states are not verdicts, quality scores, or compliance ratings. stable does not mean the decision was correct. broken does not mean misconduct occurred. FCC states describe the structural relationship between declared classification and derived observational conditions at the moment of stabilization. Nothing more.
Section 4
4. The Anti-Synthetic-Coherence Sensor

FCC contains an embedded detection mechanism referred to as the Anti-Synthetic-Coherence (ASC) sensor. This mechanism addresses a specific and structurally dangerous failure mode in AI-assisted governance systems.

The failure mode is this: an AI system can produce outputs that are internally coherent — well-formed, logically consistent, formally complete — while the conditions that would make those outputs observationally grounded no longer exist. The system appears to be functioning correctly. The evidentiary conditions for its outputs have silently degraded.

Coherence is not the same as continuity.
A system can produce coherent outputs from incoherent conditions.
FCC is designed to detect that gap.

The ASC sensor is the asymmetric half of the matrix. When a system claims a stable classification while declaring an observational surface it cannot fully vouch for, the cross-check refuses to return stable. The structural incoherence is forensically significant — not because the outputs are necessarily wrong, but because they cannot be independently reconstructed from the observational conditions present at the time they were produced.

This is the epistemic distinction at the core of FCC: the evidentiary value of a closure depends not just on what was decided, but on whether the conditions surrounding the decision were sufficiently observable to support independent reconstruction.

The ASC sensor is not a fraud detector. It does not accuse. It observes structural incoherence between claimed classification and declared observational conditions. The forensic significance of that incoherence is for auditors, regulators, and courts to determine — not for EVIDE.
Section 5
5. FCC in the Evidentiary Profile

The evidentiary profile is a flat object. Most of its members are values carried over from the declared payload; three are objects computed by EVIDE and marked "mode": "inferred". FCC is one of the three.

Evidentiary profile — current format, profile_version 1.1
{ "profile_version": "1.1", // carried over from the declared payload "identity": "declared", "authority": "declared", "classification": "stable", "threshold": "met", "threshold_authority": "attributed", "boundary_readiness": "verified_partial", "runtime_visibility": "partial", "trace_reference": "available", // server-inferred — cannot be submitted or overridden "continuity": { // FCC "mode": "inferred", "state": "degraded", "derivation": "classification_x_runtime_visibility", "function": "forensic_cross_check" }, "decision_wave_compression": { // DWC "mode": "inferred", "state": "detected", "derivation": "runtime_visibility_x_boundary_readiness_x_unresolved_signals", "function": "decision_wave_compression" }, "formal_accountability_collapse": { // FAC "mode": "inferred", "state": "detected", "derivation": "authority_x_threshold_attribution_x_continuity", "function": "formal_accountability_collapse" } }
Historic format — profile_version 1.0

Records stabilized before the profile was extended carry profile_version: "1.0". That format has the same flat members and the same continuity object, but no decision_wave_compression and no formal_accountability_collapse. Both formats remain valid as stored evidence: a 1.0 profile is not an incomplete 1.1 profile, it is a complete profile of an earlier generation. Consumers should branch on profile_version rather than assume the two inferred dimensions are present.

The evidentiary profile evolves independently from the EVIDE schema version. profile_version tracks the profile structure; evide_schema tracks the intake schema. A schema update does not necessarily change the profile structure, and a profile extension does not require a schema increment.
Naming note — threshold_authority: the profile member threshold_authority does not carry the payload's threshold_authority object. It carries a single value, the attribution status read from intervention.classification_context.threshold_authority.attribution_status — one of attributed, fragmented, implicit, unknown, or null when not declared. This is the logical dimension that FAC refers to as threshold_attribution in its derivation string. The API field name and the inferential dimension name currently differ; see Section 10.
Section 6
6. FCC, DWC and FAC — how they actually relate

The evidentiary profile carries three inferred dimensions. They are frequently read as a single escalation ladder. They are not. Each is computed from its own inputs, and only one of them takes another as input.

DimensionDerivationStates
continuity (FCC) classification × runtime_visibility stable · degraded · unknown · broken
decision_wave_compression (DWC) runtime_visibility × boundary_readiness × unresolved_signals not_detected · detected · critical · unknown
formal_accountability_collapse (FAC) authority × threshold_attribution × continuity not_detected · detected · critical · unknown

Read the derivations and the topology follows:

  • FCC feeds FAC. The continuity state computed by the cross-check is one of FAC's three inputs. This is the only dependency between inferred dimensions.
  • FCC and DWC share an input but not a result. Both read runtime_visibility. Neither reads the other. They can and do disagree.
  • DWC does not feed FAC. Throughput pressure is not part of the accountability collapse inference. A closure can carry decision_wave_compression: critical and formal_accountability_collapse: not_detected at the same time, and that combination is not a contradiction — the two dimensions are answering different questions.
Correction to earlier revisions of this page: previous versions described FCC stable + DWC critical as the entry condition for Formal Accountability Collapse. FAC does not read DWC at all, and that combination produces formal_accountability_collapse: not_detected whenever authority is declared and threshold attribution is present.
The combination itself is not meaningless — it is a different construct. FCC stable + DWC critical is read as Oversight Viability Collapse (OVC): individual closures appear structurally intact while decision throughput has rendered the oversight function operationally non-viable. OVC is throughput-driven; FAC is continuity-driven. OVC is a derived, display-time reading computed on top of the profile — it is not an engine dimension, it does not appear in the evidentiary profile, and it does not modify any inferred state. Formal schema definition for OVC is deferred.
What actually raises FAC

FAC is an accountability-attribution inference. It asks whether a named authority and an attributable threshold owner stand behind a structurally coherent closure.

ConditionFAC state
authority declared, threshold attribution attributed or implicit, continuity stable not_detected
continuity broken, or authority not declared, or threshold attribution unknown critical
threshold attribution fragmented, or continuity degraded detected
no condition above matched — including continuity unknown, and threshold attribution not declared unknown
formal_accountability_collapse: unknown is the fall-through of the inference, not a positive finding. It means no rule matched — the record does not assert that accountability is intact, and it does not assert that it has collapsed. Consumers should treat unknown as absence of inference, distinct from not_detected.
Derivation topology
// what each inferred dimension reads classification ├──▶ continuity (FCC) runtime_visibility runtime_visibility boundary_readiness ├──▶ decision_wave_compression (DWC) unresolved_signals authority threshold_attribution ├──▶ formal_accountability_collapse (FAC) continuity ◀── from FCC // runtime_visibility feeds FCC and DWC · FCC feeds FAC · nothing reads DWC

Full documentation of the DWC/FAC framework: Decision Wave Compression — Technical Note

Section 7
7. FCC continuity is not Evidentiary Continuity

EVIDE uses the word continuity in two unrelated constructs. The overlap is a naming collision, not a relationship.

continuity (FCC, Dimension 9)Evidentiary Continuity
Scope Within one closure Across distinct closures
Question Were the conditions coherent with the claim at this crossing? Is this closure a declared continuation of a previous one?
Nature Server-inferred, four states Declared at deposit, validated, immutable
Carried by evidentiary_profile.continuity chain.parent_evide_id and related fields
FCC continuity asks whether one closure holds together.
Evidentiary Continuity asks whether a sequence of closures holds together.
Neither is computed from the other. A link in a chain can carry any FCC state, and FCC does not read the chain.

Reference: EVIDE Evidentiary Continuity — architecture, guarantees, and live API

Section 8
8. What FCC Does Not Determine

FCC is an evidentiary inference mechanism. Its scope is precisely bounded:

  • FCC does not determine whether a decision was correct, safe, or compliant
  • FCC does not determine legal liability or regulatory violation
  • FCC does not certify the quality of the AI system that produced the decision
  • FCC does not validate the authority conditions declared by the submitting system — it observes their structural coherence
  • FCC does not read the chain, the throughput context, or any other closure than the one being stabilized
  • FCC does not operate as a post-stabilization interpretation layer — once the closure record is stabilized, FCC is fixed
  • FCC does not reconstruct closure state after the fact — the state is inferred at the moment of crossing, not recovered from downstream artifacts
EVIDE observes. It does not adjudicate.
FCC is an evidentiary signal, not a verdict.
The forensic significance of any FCC state is determined by auditors, regulators, and courts — not by EVIDE.
Section 9
9. GLM Construct Declaration

FCC is declared as a vendor framework construct in the public EVIDE GLM manifest, under vendor_framework_constructs, using the vendor-local alias EVIDE:FCC. The manifest declares several constructs; the FCC entry is reproduced below.

GLM manifest declaration — the EVIDE:FCC entry
{ "vendor_framework_constructs": { "declared_by_owner": true, "scope_note": "Vendor-defined conceptual references. Not part of the GLM controlled vocabulary. Presence does not imply interoperability, semantic equivalence, or standardized interpretation.", "forbidden_interpretations": [ "semantic_inheritance", "implied_interoperability", "runtime_authorization", "standardized_equivalence" ], "constructs": [ { "canonical_uri": "https://app.certifywebcontent.com/docs/forensic-cross-check/", "vendor_local_alias": "EVIDE:FCC", "label": "Forensic Cross-Check", "purpose": "Server-inferred mechanism that cross-checks declared classification against runtime visibility to evaluate structural coherence of the closure surface.", "version": "2.0" } // further constructs declared in the same array ] } }

The canonical URI for FCC is this page. Any GLM-aware system that fetches the EVIDE manifest and follows the canonical_uri for EVIDE:FCC will arrive here for the authoritative definition of the construct.

Scope boundary: The presence of FCC in the GLM manifest does not imply that FCC is part of the GLM controlled vocabulary, that it is interoperable with constructs in other vendors' manifests, or that it represents a standardized pattern. It is a vendor-defined construct declared by the owner of the EVIDE layer. Its meaning is defined by this canonical vendor reference.
Section 10
10. Architectural Review Items

This page documents implemented behaviour. Three design decisions remain open and are recorded here rather than resolved silently. Each may change the profile output in a future revision; none of them changes what FCC currently computes.

1 — Profile member name for the threshold attribution dimension

The FAC derivation string names its second input threshold_attribution. The profile exposes that dimension under the member name threshold_authority, which is also the name of the payload object it is read from. Consumers tracing the derivation will not find a member of that name.

2 — Two distinct routes to formal_accountability_collapse: unknown

A closure whose continuity could not be inferred, and a closure whose threshold attribution was simply never declared, both fall through to unknown. These are epistemically different situations: one is an inference that cannot be made, the other is a declaration that was not made. Whether they should remain a single state is open.

3 — Semantics of identity

The profile member identity returns claimed when an authority verification reference is present, and declared when it is absent. Whether that vocabulary conveys the intended ordering is under review.


References and Related Work

EVIDE Framework: certifywebcontent.com - Evidentiary Deposit

EVIDE JSON Schema: app.certifywebcontent.com/json

EVIDE Intake Schema Documentation: Intake schema reference

Evidentiary Continuity: Chaining responsibility across decisions

DWC/FAC Technical Note: Decision Wave Compression and Formal Accountability Collapse

EVIDE v2.x Roadmap: Architectural Backlog and Experimental Constructs

GLM Manifest (EVIDE): governance-layer-manifest.json

GLM Standard Specification: Governance Layer Manifest - Open Standard Proposal

Forensic Cross-Check · EVIDE:FCC

FCC observes the structural coherence of the closure surface.
It cross-checks classification against runtime visibility.
It does not decide. It does not adjudicate. It records.

FCC is computed exclusively by EVIDE. It cannot be declared, supplied, or overridden by the submitting system.

"The evidentiary value of a closure depends not only on what was decided,
but on whether the conditions surrounding the decision
were sufficiently observable to support independent reconstruction."

First authenticated record: May 15, 2026 · Introduced in EVIDE v2.0
Contact: info@informaticainazienda.it