Independent reconstruction

Section 01

Preserved results and independent reconstruction

The useful question is not just "what state did we save?" It is "can another path account for how we reached it?"

Consider a preserved sequence of financial instructions and the result attributed to it. Reading that result back confirms what is stored. It does not, on its own, establish that the sequence is complete, that the same rules were applied or that an independent reconstruction would agree.

Reconstruction addresses this gap. Starting from an explicit boundary, it interprets the preserved material under declared assumptions and derives an observation that can be compared. The boundary matters as much as the calculation: a bounded check is useful precisely because it states what it examined.

For an institution evaluating infrastructure, this offers a concrete line of inquiry: can a result be examined without simply trusting the component that produced it? This is a technical evaluation question, not a claim of regulatory compliance.

Section 02

Two independent reconstruction paths for one preserved history

One preserved history, two reconstruction paths, an explicit comparison.

FxChain's reviewed local foundations distinguish an oracle path from an engine path. Each works within a bounded reconstruction scope. Their observations are then compared; the comparison is not permission to overwrite history or to make either path authoritative.

Separation is valuable because repeating the same implementation can repeat the same mistake. Separation does not by itself guarantee independence: two paths may still share assumptions, input defects or a misunderstood rule. Agreement is evidence under those conditions, not proof that all conditions are correct.

This page describes responsibilities, not proprietary algorithms, wire formats or an executable integration recipe. The diagram is an explanatory map, not a trace of a running deployment.

Section 03

History continuity and state commitments

Continuity and state commitments make the input boundary inspectable.

A reconstruction can reach a plausible-looking answer from incomplete material. Continuity checks help distinguish a usable sequence from one with a missing or inconsistent step. A state commitment provides a comparison point for the reconstructed state; it does not make that state legitimate merely because a digest exists.

Preservation and reconstruction therefore answer different questions. Preservation concerns the retained material and its declared constraints. Reconstruction concerns what can be derived from that material. Neither alone establishes distributed consensus, economic fairness or legal finality.

The local implementation scope includes continuity and state-commitment checks. This public explanation deliberately does not imply a general-purpose database, a live peer-to-peer network or unrestricted replay of arbitrary workloads.

Section 04

Agreement, disagreement and refusal

A comparison should report what it sees, not invent a winner.

Agreement means the compared observations match within the stated scope. It does not establish that both paths are free of shared errors. Disagreement means the observations differ and an explanation is required; choosing the engine or oracle by default would erase the value of comparison.

Refusal means a path could not admit or reconstruct the supplied material under its conditions. If one path refuses and the other produces a result, that asymmetry must remain visible. It is not automatically a diagnosis of which path is wrong.

The internal acceptance material retains qualifications around some asymmetric refusal classifications. We preserve that limit here. "Implemented locally" describes delivered foundations, not universal resolution of every possible discrepancy.

Section 05

Technical evaluation scope

Ask for a bounded subject, an explicit method and a conclusion you can challenge.

A useful technical discussion starts with the history to examine, its initial boundary, the rules assumed by each path and the observations that will be compared. It also identifies what a disagreement would require next and what remains outside the exercise.

The public evidence card explains the reviewed subject, method and limitations. The source and full reproduction package remain private. Access to further material is a separate decision; contacting Flowesome does not grant a licence, an SDK, a production endpoint or a delivery date.

FxChain Foundations is the reading layer for that discussion. It presents implemented local work without promoting it into a publicly available network or a licensed middleware product that has not been released.

What must hold for a comparison to mean anything

Five conditions. If one of them fails, the comparison is theatre.

1. 1The boundary is declared before reconstruction begins.
2. 2Neither path is authoritative by default.
3. 3Refusal is preserved as an outcome; it is never resolved by voting.
4. 4Agreement is evidence under stated conditions, not proof of correctness.
5. 5Every observation can be traced back to what was examined.

What to bring to a technical discussion

A discussion that starts here can be bounded, examined and challenged.

• The history to examine, and why that history
• Its initial boundary, stated explicitly
• The rules each path is assumed to apply
• The observations that will be compared
• What a disagreement would require next
• What deliberately remains outside the exercise