Update log
- 7 September 2026 - First edition. Drawn from the architecture programme's master plan (internal reference Supreme Master Plan V1.2-RC3), a ratifiable draft pending final seal. Everything here is design direction: candidate and non-binding. Object names and relationships are given; field lists, defaults, thresholds and candidate profiles are deliberately withheld.
Short answer
The FxChain Architecture & Protocol Programme describes the target anatomy of FxChain as three planes that share one small vocabulary and nothing else.
The runtime plane owns what consensus sees: admission, intents, cells, causal ordering, execution, state, receipts, blocks, persistence, transport and finality. The change plane owns how the protocol and its implementation are allowed to evolve: work authority, bounded mutation rights, successor admission, acceptance, closeout, supersession and recovery. The assurance plane owns claims, observations, instruments, evidence, falsifiers and gates: it can establish, refute or leave a claim unestablished, and it can do nothing else.
Between them sits a shared semantic kernel - identity, reference, version, commitment, coordinate, reason, lineage, supersession and a minimal receipt header - admitted on five conditions and forbidden to contain any plane's machinery. Every crossing between planes is a typed contract, closed-world by profile, and the governing law is written in capitals in the plan: cross-plane authority never transfers implicitly.
Two further separations complete the shape. Evidence lives in two worlds, an open-world log that keeps growing and a closed-world release manifest that is sealed and complete. And every registered object is classified on three independent axes - technical maturity, governance state and truth class - because "implemented", "ratified" and "activated" answer different questions and may never be compressed into one.
What is established, what is in development, what is not claimed
| Claim | Status | Basis | Limit |
|---|---|---|---|
| The programme's master plan states these laws, planes, contracts and axes | Research | The plan is a ratifiable draft pending final seal | Candidate and non-binding; producing the plan authorises no implementation |
| The deterministic offline core the plan builds on exists locally | Proven today | Implemented local harness; FxChain Foundations | Local only: no network, no production consensus, no production VM |
| A small Sovereign Change Core with typed objects is envisaged inside the change plane | Planned | The plan's transmutation section | Not built; adoption requires a machine-checked model |
| Cross-plane contracts exist as named, closed profiles | Research | Four initial profile families named in the plan | Design; no registry is activated |
| The three-axis classification governs a registry that must validate before any seal | Research | The plan's classification chapter | Design; the registry itself is future work |
| Independent external review of the plan | Later gate | Not commissioned | The plan's own review cycles are internal |
| That any of this is implemented, activated or deployed | Not claimed | The plan separates ratification, implementation and activation | Ratified does not imply implemented; implemented does not imply activated |
The decisive correction
The plan opens with what it calls the decisive architectural correction: FxChain is no longer one system with many modules, but three planes that share a kernel deliberately smaller than any of them.
SHARED SEMANTIC KERNEL
identity . reference . version . domain . grammar . commitment
coordinate . reason . receipt header . supersession
|
+----------------+----------------+
| | |
v v v
RUNTIME PLANE CHANGE PLANE ASSURANCE PLANE
consensus- engineering epistemic /
critical evolution proof
| | |
intent -> cell change intent claim -> observation
-> execution -> authority -> falsifier
-> state -> acceptance -> gate result
-> block -> closeout -> judgment
Figure 1 - The three planes over one kernel, redrawn from the plan. The arrows inside each plane are its own lifecycle; nothing crosses between planes without a typed contract.
The architecture is described as fractal only at the semantic level: identity, version, commitment, reason and lineage recur everywhere, but each plane owns different business semantics, a different failure model and different authority. The plan's phrase for the rule is share semantics, not plumbing.
The shared semantic kernel
The kernel is the vocabulary all three planes speak. Its candidate primitives are a dozen names - identity, reference, version, domain, grammar identity, commitment, coordinate, reason identity, lineage, supersession reference, a minimal receipt identity and a generic scope grammar - and the plan is stricter about what may join them than about what they are.
A type may enter the kernel only when all five of the following hold:
- at least two planes consume it with strictly identical semantics;
- sharing it creates no authority bridge;
- it contains no runtime-, change- or assurance-specific state;
- its shared representation is smaller than the business objects that consume it;
- its lifecycle and versioning can be reasoned about without importing one plane's policy into another.
Two clarifications keep the kernel small. A receipt is shared only as a minimal identity and header algebra; runtime receipts, change receipts and assurance receipts remain different families. A scope is a generic bounded grammar, never a giant union of every permission in the ecosystem.
And the plan names what must never appear in the kernel: Git concepts, pull requests, reviewer seats, continuous-integration jobs, payment claims, bank-specific fields, market microstructure, wallet interface concerns or assurance judgments. If any of those appear in the kernel, the decomposition has failed.
The three planes and what each owns
RUNTIME PLANE CHANGE PLANE ASSURANCE PLANE
owns owns owns
. deterministic . work authority . claims, observations
admission . bounded mutation instruments, evidence
. intent, cell, rights, writer leases . falsifiers, gates
causal ordering . successor admission, . mutation-observer
. effect, execution amendment, acceptance coverage
. state, receipts, . closeout, supersession . independent
blocks . recovery governance reconstruction
. persistence, . proof reuse,
transport, validators, calibration
finality
cannot cannot cannot
. call live external . gain runtime state . merge, activate
services during authority by approving runtime power, or
consensus a future version make an external
. consume anything but claim true by
committed, versioned, observation alone
deterministic inputs
Figure 2 - What each plane owns, and the one thing each is forbidden to do. The prohibitions are as load-bearing as the ownerships.
The three prohibitions are the point. The runtime plane consumes only committed, versioned, deterministic inputs and cannot call anything live during consensus. The change plane can approve a future protocol version and gains no runtime state authority by doing so. The assurance plane can establish, refute or leave a claim unestablished - and cannot merge, cannot activate, and cannot turn an external claim into truth by observing it.
Typed crossings: authority never transfers implicitly
No plane may acquire another plane's authority through an ordinary object reference. Every meaningful crossing is a typed contract that records where it comes from, where it goes, what subject and class of payload it carries, what authority it does and does not convey, what must be true before it is valid, what evidence it requires, when it is valid, how it may be consumed, how it fails and what receipt it leaves.
The contract layer is closed-world by profile. There is no generic catch-all tunnel: a concrete crossing exists only when its exact profile is present in a versioned registry. The plan names four initial families.
CHANGE ---- protocol version adoption ----> RUNTIME
ASSURANCE -- evidence submission ----------> CHANGE
RUNTIME ---- runtime fact export ----------> ASSURANCE
EXTERNAL CLAIM CORE -- attestation import -> an eligible consumer
CROSS_PLANE_AUTHORITY_IMPLICITLY_TRANSFERS = NEVER
Figure 3 - The four initial crossing families and the law that governs all of them. A future authority-bearing crossing must be introduced as its own named, closed profile; an open "authority passage" is forbidden by name.
The consequences are spelled out. A runtime receipt may become evidence in the assurance plane without becoming change authority. An assurance judgment may support a change decision without becoming a runtime capability. A ratified change object may name a protocol version without activating it. An external attestation may be adjudicated without becoming canonical state, until a separate deterministic runtime rule explicitly consumes the adjudicated result.
Two evidence worlds
The plan separates two populations of evidence that, it says, should never be forced into one object.
OPEN-WORLD EVIDENCE LOG CLOSED-WORLD RELEASE MANIFEST
appendable finite
ordered sealed
content-addressed population-complete
checkpointable immutable after seal
| |
+---- a manifest may bind a ---------+
checkpoint of the log
Figure 4 - An operational log keeps growing after a checkpoint; a release manifest proves completeness only for its declared closed population, and can bind a checkpoint of the log.
This resolves what the plan calls a recurrent contradiction: a seal was being expected to be both the final write and part of an indefinitely growing operational history. It cannot be both. The evidence lab's own custody surfaces are the concrete case - a published surface is a closed manifest; the recorder chain is an open log.
Three axes, not one lifecycle
A single lifecycle enumeration is, in the plan's words, insufficient, because technical maturity, governance state and truth class answer different questions. Every registered object therefore carries three orthogonal dimensions.
TECHNICAL MATURITY GOVERNANCE STATE TRUTH CLASS
how mature and what authority has what kind of truth
compatibility-bearing been granted to design, the object is allowed
is this? implement or activate? to represent?
from reserved and from unratified through from canonical
exploratory, through ratifiable and ratified, protocol and state,
candidate and to implementation through governance,
implemented-but-not- authorised, activation evidence, projection
canonical, to canonical; eligible and activated; and operational, to
then deprecated, then suspended or ephemeral, research
superseded, prohibited revoked and external attestation
Figure 5 - Three questions, three axes. The value ranges are described, not enumerated; the plan owns the exact sets.
What the plan makes explicit is a set of non-compression laws, stated as inequalities:
- implemented is not activated;
- ratified is not implemented;
- canonical protocol is not canonical state;
- an external attestation is not canonical state;
- a projection is not canonical state;
- evidence is not authority.
Not every combination of the three axes is legal, and the illegal ones are structural: canonical state requires canonical maturity and an activated governance state; research may never be treated as activated canonical protocol or state; an external attestation may be authenticated, adjudicated and persisted but never becomes canonical state merely through attestation; a projection may be operationally activated without ever gaining state authority; something implemented but not canonical may run in a laboratory profile without inheriting canonical compatibility; and a prohibited object cannot be eligible for activation. A registry entry that violates one of these is structurally invalid and must fail validation before any seal can be produced.
The registry is described as a graph rather than a census: relations between objects are typed and independently addressable - owns, references, authorised-by, requires, consumes, produces, supersedes, derives-from, observes, attests, persists, projects, activates, conflicts-with. No active type may be without an owner, and no future target becomes a current capability merely by appearing in the atlas.
The laws
The plan's design laws govern the whole target architecture and are, in its words, more fundamental than any crate map or provider choice. They are reproduced here in short form because they are the most durable public statement of the direction.
| # | Law | In one line |
|---|---|---|
| 1 | Proof before power | An object may be visible, versioned, inspected and attacked long before it may mutate canonical state |
| 2 | Law before engine | Storage, consensus, proof systems, databases and networks are mechanisms; FxChain owns the grammar they implement |
| 3 | Declared is not observed | A declaration is attributed intent; an observation has an observer, an instrument, a scope and a coordinate |
| 4 | Unknown is not false | Missing evidence, an instrument crash, a parser failure and a measured zero are distinct states |
| 5 | Instrument failure is not domain failure | An instrument error is never converted into fail, killed, absent or clean |
| 6 | Valid signature is not authority | Authenticity, authorisation, admission, execution and finality are separate judgments |
| 7 | Safety, liveness and non-retroactivity travel together | Reject unauthorised evolution, represent authorised evolution, preserve historical acceptance exactly |
| 8 | Consensus sees deterministic committed inputs only | Human reviews, external observations and non-deterministic outputs never make validators disagree on identical bytes |
| 9 | The hot path is bounded | Remote input cannot select unbounded memory, recursion, proof work, state growth or iteration |
| 10 | Canonical truth and projections are different species | Dashboards, caches and indexes are reconstructible consumers, never sources of truth |
| 11 | Every load-bearing claim needs a falsifier | Without an executable or independently checkable refutation path, a guarantee is unestablished |
| 12 | Evidence is reusable when its assumptions are unchanged | Replaying unchanged proof campaigns for ceremony is prohibited by default |
| 13 | Assurance cost is risk-proportional | A documentation change does not need consensus-grade ceremony; a validator-set transition does |
| 14 | Same kernel, hostile worlds | The simulator and the real node exercise the same transition kernel when the semantics under test are the same |
| 15 | Share semantics, not plumbing | The planes reuse a small vocabulary and never import each other's machinery |
| 16 | Formalise once, then build | A new assurance primitive is accepted only if it reduces future complexity or raises the proof floor materially |
| 17 | Power must have a computable shape | A change that widens authority must make the before and after power graphs comparable |
| 18 | A signature binds a consequence ceiling | Where a profile can move value or grow state irreversibly, the signed semantics bound the maximum consequence |
| 19 | Irreversibility may not outrun established truth | Uncertain facts justify preparation or quarantine before they justify an irreversible release |
| 20 | Evidence count is not independence | Ten observations sharing one parser, author or environment may be one failure domain |
| 21 | Reused proof must survive fresh scepticism | Incremental assurance needs an explicit invalidation graph and a challenge path that recomputes without trusting the cache |
| 22 | Constitutional liveness must be machine-checkable at the core | Safety, successor representability, conditional liveness and non-retroactivity must be falsifiable before activation of the core |
| 23 | History is queryable lineage | A current rule can expose the amendment lineage that made it effective, without rewriting historical receipts |
| 24 | Determinism has an explicit firewall | Every source of nondeterminism near consensus is classified: forbidden, normalised, committed or operational-only |
| 25 | Sovereignty is tested by exit | A provider is replaceable only when export, independent import and reconstruction have been demonstrated |
| 26 | Added semantic surface must earn its existence | A new type, owner, grammar or authority branch must create a capability, remove duplication, make a defect impossible or reduce a measured risk |
Several of these are already practised on the development line - proof before power, declared is not observed, unknown is not false, every claim needs a falsifier, evidence count is not independence - and the evidence lab dossier shows where. Others describe the target and are stated as such.
What this dossier does not establish
- It does not establish that the target architecture is built, activated or deployed. The plan itself separates ratification from implementation and implementation from activation.
- It reproduces the shape of the design - laws, planes, contracts, worlds and axes - and withholds its fields, defaults, thresholds, contract identifiers and candidate profiles.
- The plan is a ratifiable draft pending final seal; its own status vocabulary applies to it.
- No external party has reviewed the plan; its review cycles are internal.
Verdict
The direction is a decomposition, and the decomposition is enforced by prohibitions rather than by diagrams. Three planes own three kinds of truth; a kernel smaller than any of them carries the shared vocabulary; every crossing is a named contract that cannot carry authority by accident; evidence is kept in an open log and a closed manifest that never pretend to be each other; and every object is placed on three axes that refuse to be compressed into one word like "done".
Read together with the acceptance discipline and the evidence lab, the laws show where the direction comes from: they are the failures of the development line, written forward as constraints on the architecture that must not repeat them.
Frequently asked questions
Is this the FxChain roadmap?
It is the architecture the roadmap must fit. The plan orders implementation and names its gates, but this dossier describes the target shape, not delivery dates. No date is stated anywhere on this portal for any of it.
Why three planes rather than one well-designed system?
Because the three kinds of truth fail differently and are governed differently. Consensus truth must be deterministic and bounded; engineering evolution must be authorised and reversible in the right places; assurance must be free to refute without being able to activate. One plane with three moods would let one of them borrow the others' authority by accident - which is exactly what the crossing law forbids.
What is the Sovereign Change Core?
The envisaged core of the change plane: a small set of typed objects - authority, subject, obligation, observation, gate, witness, verdict and transition receipt - into which the plan compresses the discoveries of earlier programmes. It is planned, not built, and its adoption is gated on a machine-checked model.
Does "canonical" mean "live"?
No. Canonical maturity is one axis; activation is another. Something can be canonical protocol without being canonical state, and ratified without being implemented. The non-compression laws exist precisely so that no single word implies the others.
Where are the fields, the schemas and the defaults?
In the plan, which is private and non-binding. This dossier publishes the laws and the shape of the objects on purpose, and stops there.
Sources and methodology
This dossier is drawn from the architecture programme's master plan: its delivery posture, its design laws, its macro-architecture chapter (shared kernel, three planes, cross-plane contracts, two evidence worlds), its three-axis classification chapter and its transmutation section. Laws are quoted in condensed form; prohibitions are reported as stated.
The plan is an internal, ratifiable draft. Nothing in it is implemented by virtue of being written; its own status vocabulary - candidate, non-binding, pending final seal - applies to every statement above. Object names and relationships are reported; field lists, enumerations, defaults, thresholds and candidate profiles are withheld by editorial rule. Figures shown anywhere on this portal come from a single dated snapshot; none are introduced by this dossier.
Related reading: The three programmes for the public names and references; The acceptance discipline and The evidence lab for the practice the laws were written from; Technology for the runtime organs.