Skip to content
FxChain · Programmes

Architecture, assurance and governed operations

FxChain organises its work around three complementary programmes. Each keeps its internal reference, carries an explicit status, and is presented here under a public name proposed to explain its function - not to rename its history.

Public names, proposedInternal references keptA status on every lineNot three products
01 · The vision

Govern. Prove. Operate.

A summary of the vision, not an inventory of delivered products. For a non-technical reader: change governance, verifiable assurance and controlled operations.

FxChain articulates an explicit architecture, verifiable qualification evidence and governed operations - while preserving each organisation's own decision authority.

02 · The programmes

What each programme does, and what its name must not be taken to mean

Two readings of the same work: an institutional one, in plain words, and a technical one that keeps every internal reference identifiable in its archives.

Programme 01 · Prove

FxChain Sovereign Assurance & Attestation (SAA)

Assurance and attestation of software versions, their controls and their evidence

In development

The assurance and attestation programme, born from the internal acceptance arc, develops the mechanisms that bind a software version to its controls, its evidence and the conditions of its qualification. Its envisaged product evolution keeps the admission decision in the hands of each organisation.

SAA aims to make verifiable the identity of a software version, the controls applied to it and the evidence that supports its qualification.

SAA establishes the evidence; the operator keeps the decision.

Assurance
technical confidence supported by controls and evidence
Attestation
a statement attributed to an issuer about a precise subject and policy
Sovereign
the organisation keeps control of its trust policy and of its admission decision

What the name does not mean

  • Not a state certification, an absolute guarantee or a universal authorisation to deploy.
  • Attestation and the capability to deploy remain distinct: a passport attests a result; the client or the node decides admission locally.
  • The public name is proposed for the future capability; in the archives the reference keeps its historical meaning.

Internal reference

Q372-SAA (historically "Successor Admission Amendment")

The acceptance discipline

Programme 02 · Operate

FxChain Mission Control (MC)

Governed Operations & Evidence Custody

Implemented locally

The Mission Control programme covers governed execution, the tracking of transitions and the verifiable custody of operational evidence. It aims to make responsibilities and outcomes explicit, without confusing observation, authority and action.

What matters is the scope of an operation, its steps, its responsibilities, its outcomes and the evidence that is kept.

Mission Control lets you follow an operation and verify what actually happened.

Governed operations
an operation runs inside a declared scope, with named responsibilities and recorded steps
Evidence custody
the material that allows the operation to be verified is preserved, not merely logged

What the name does not mean

  • Not the user cockpit. FxDesk remains the chartered candidate for a human operational cockpit; Mission Control is the programme and its mechanisms.
  • No two competing cockpits, and no integration presented as already done.
  • An internal lab today; not a hosted service and not a product.

Internal reference

Q372-MC; a valid historical programme name in custody records

Cold rooms and evidence admission

Programme 03 · Govern

FxChain Architecture & Protocol Programme (APP)

Target Architecture, Interoperability & Implementation Roadmap

Research

The architecture and protocol programme, referenced V1.2-RC3, organises FxChain's target architecture, interfaces and roadmap. It distinguishes capabilities already demonstrated, designs proposed and future developments subject to validation. Producing the plan authorises no implementation by itself.

Within it, the envisaged governance capability is the Sovereign Change Core (SCC): a small core of typed authority, subject, obligation, observation, gate, witness, verdict and transition-receipt objects - who may change what, and under which conditions. Its antecedents are practised today as the acceptance discipline; the core itself has not been started, and by its own genesis law it cannot authorise its own birth.

This programme defines how the capabilities of FxChain must fit together, and in which stages they may be implemented and validated.

Target architecture
the shape the capabilities must take - shared kernel, planes and typed contracts - stated as laws before any code
Roadmap
ordered stages, each with its own validation, none activated by the plan alone
Sovereign Change Core (SCC)
Its antecedents - the acceptance discipline and the evidence lab - are practised today; the compact typed core that compresses them is planned, not built

What the name does not mean

  • "RC3" is a version reference of an internal document, not "FxChain Release 3", and no third operational network is delivered.
  • A design programme: nothing in it is implemented by the plan itself.
  • Object names are published; field lists, defaults and candidate profiles are not.

Internal reference

Supreme Master Plan V1.2-RC3

FxChain Foundations
03 · Names and references

Public names explain function; internal references keep history

Harmonising is not renaming the repository. Identifiers stay in archives, reports and manifests; the public names serve to explain what each programme does, with this explicit correspondence.

Public nameInstitutional descriptorInternal referenceStatus
Sovereign Assurance & Attestation (SAA)Assurance and attestation of software versions, controls and evidenceQ372-SAAIn development
Mission Control (MC)Governed Operations & Evidence CustodyQ372-MCImplemented locally
FxChain Architecture & Protocol ProgrammeTarget Architecture, Interoperability & Implementation RoadmapSupreme Master Plan V1.2-RC3Research
Sovereign Change Core (SCC)Envisaged change-governance capabilityV1.2-RC3, change planePlanned
FxDeskChartered professional terminal; candidate human operational cockpitNaming charter (RFC-0001)Reserved
04 · Boundaries

What this page does not claim

  • Three programmes are not three commercial products; none is available as a service.
  • The public names are proposed presentation names. Under the architecture programme's own rule, a public successor name remains a candidate until the naming charter is changed by a separate authorised act.
  • Internal identifiers keep their historical meaning in archives, reports and manifests; this page does not rename them.
  • No state certification, no absolute guarantee, no universal authorisation to deploy, no third operational network.

Read the discipline behind SAA and MC

The acceptance discipline dossier explains, at the level of method, how a change earns its place on the sealed line - and what that does not establish.