Validation & Failure Semantics

Implemented — within the JIT and schema layers

This is the part of the design that most directly serves review: a system that reports only what succeeded cannot be checked for what it missed.

The no-silent-drop rule

Every in-scope record and candidate terminates in an explicit outcome. Summary counts are computed from those outcomes. A separate number cannot be supplied to conceal an omission.

JIT candidate outcomes

Outcome	Meaning
NORMALIZED	Produced one or more Observations
DUPLICATE	A repeat of an identical locator within one index snapshot
UNSUPPORTED	Read, but not expressible under the pinned schema
ERROR	Processing failed
NOT_RELEVANT	Exact-hit reconstruction found no real account participation

NOT_RELEVANT is worth noting: a reverse-index match bit is a hint, not a finding. A candidate that reaches the engine on a coarse match and turns out not to involve the account terminates explicitly rather than disappearing.

Source extraction outcomes

The same five outcomes apply to SourceRecord selection in a SourceExtractionRun, with NOT_RELEVANT requiring the grounds the contract specifies.

Run-level closure

A run is not COMPLETE merely because it finished:

• A TransactionDiscoveryRun is COMPLETE only when the profile and producer artifact are pinned, the block range has no gaps or unresolved errors, and every unique discovered transaction is linked. If required trace or state material could not be obtained, the run must be PARTIAL.
• Interpretation closure is PARTIAL while any UNSUPPORTED or ERROR remains. A hypothesis being REJECTed or DEFERred does not mark the Observations it cited as processed.

Where uncertainty is preserved

Situation	What the system does
Unconfirmed bridge destination	Confirmed OUT Posting plus a MISSING destination leg; no arrival Posting, no confirmed continuity, no lot carry
Unknown acquisition cost	basisStatus: UNKNOWN, not zero
ERC-4337 user operations	userOpHash and userOpIndex retained as native evidence; terminates UNSUPPORTED rather than mapping to a fabricated transaction coordinate
Transaction-less block credits and withdrawals	Terminates UNSUPPORTED with native coordinates preserved
Provider divergence	Detected and surfaced rather than resolved by picking a winner silently
Reorg	Recorded as an inclusion revision; the previous inclusion is not replaced

In each case the alternative — filling the gap with a plausible default — would produce a cleaner-looking result that a reviewer could not audit.

Reproducibility

The same input at the same versions produces the same result. When versions differ, the cause of the change is explainable.

Supporting mechanisms:

• An immutable selection snapshot and selection digest fix what a run considered.
• Shared execution evidence is materialized once per chainId + blockHash + transactionIndex + evidenceProfile, so retries, duplicate workers, process crashes, and provider failover do not create duplicate executions.
• Content-addressed artifacts make the inputs to a result identifiable by hash.
• A validated generation is never edited in place; corrections arrive as new records carrying supersedes and a reason.

Validation depth

Type-checking individual fragments is not sufficient to publish. #ValidateGeneration checks global references and closure conditions across transaction, inclusion, execution, discovery run, link, observation run, and Observation. #ValidatePublication additionally checks the manifest against actual content hashes.

What is not covered

A user-facing coverage and reconciliation view — the surface that would make these outcomes reviewable by a non-engineer — is Not verified. The outcomes exist and are stored; the interface that surfaces them does not. See Tax Inventory & Report.