BLACKSWAN Estate Canon

Version: v2.2 — FROZEN (2026-08-30) Sponsor: Mamadou Ly, Founder, Managing Partner & CEO Scope: This document is the single-page reference every contributor (human or AI) must read before authoring any BLACKSWAN artifact — code, documentation, marketing copy, architecture diagrams, or repositories. It is not the constitution of the estate (LCGX is). It is the operating vocabulary and shape that keeps work aligned. Read time: ~5 minutes.

0. Versioning and amendment policy

The Canon was FROZEN at v1.0 on 2026-07-11, then DRAFT at v1.1 with additive §11 (Estate Domains), then FROZEN at v2.0 on 2026-08-30 with the seven-plane formalisation ratified in ADR-014 (2026-08-24) after the SCFOS + GOVCOS wiki pages landed and Nexus v1.2 served prod for 6 calendar days without rollback (T3 founder-consent Motion 2, 2026-08-24), and is now FROZEN at v2.2 on 2026-08-30 with additive §12 (Account Model, ADR-014.1 v0.2, 2026-08-29) and additive §13 (Payment Control Plane, ADR-027 v0.2 RATIFIED, 2026-08-30 under T3 founder-consent Motion 3). The additive §11 (Estate Domains) content from v1.1 is preserved verbatim.

"Frozen" does not mean immutable. It means: no proposal, repository structure, UI specification, or implementation decision may be accepted unless it is demonstrably consistent with the Canon at its current version. If a proposed artifact conflicts with the Canon, either reshape the artifact or open a separate Canon-amendment PR first — never inline the amendment inside an artifact PR.

Amendment procedure

Amendments happen only in dedicated PRs against blackswan-gateway/docs/blackswan-estate-canon.md.
Every amendment PR MUST bump the version header at the top of the file.
The sponsor (Mamadou Ly) reviews and approves every amendment PR before merge.
Amendment PRs MUST include a short changelog entry (see below) describing what changed and why.

Version-bump rule

v1.x → v1.(x+1) — additive-only changes: new sections, new prohibitions, new wiki links, new vocabulary items, new plane rows, clarifications. Anything that a compliant artifact under the previous version is still compliant under.
vN.x → v(N+1).0 — breaking changes: renaming a plane, changing the Nexus render, changing the tech-stack canon, retiring a prohibition, changing a locked invariant, or any change that could invalidate a previously-shipped artifact.

Example: adding a 16th prohibition to §9 → v1.1. Renaming TREICHTEC or dropping HSOS from the roster → v2.0.

Changelog

v1.0 — 2026-07-11 — initial canon: plane roster (5 OS + LCGX), AIOS row-vs-plane hierarchy, vocabulary, technology stack, repository conventions, delivery cadence and postures, Nexus render rule, canonical estate diagram, 16 categorical prohibitions, wiki index.
v1.1 — 2026-07-11 (DRAFT) — additive: introduces §11 Estate Domains (7 domains) as an orthogonal capability view over the §1 plane roster. No renumbering, no prior-text mutation.
v2.0 — 2026-08-24 (DRAFT → 2026-08-30 FROZEN) — breaking: seven-plane formalisation (ADR-014). Admits SCFOS (Supply Chain Finance Operating System) and GOVCOS (Governance & Compliance Operating System) as first-class OS planes in §1. Restructures the Nexus render (§1 launcher paragraph and §7 render rule) from a 4-card grid (falcon / swan-nest / digital-swan / ai) to a 5-card grid (falcon / swan-nest / digital-swan / ai / scfos), with HSOS and GOVCOS both off-card as governed surfaces rendered via a GOVERNED SURFACE chip in Command Centre and gateway plane surfaces. Rewrites the §8 canonical estate diagram to include the two new planes. Rewords prohibition #9 (§9) to permit ratified Canon amendments to the Nexus render while keeping ad-hoc restructuring forbidden. Depends on ADR-022 (co-management governance model, RATIFIED v0.3, 2026-08-24) which admitted SCFOS and GOVCOS at the wiki tier.
v2.2 — 2026-08-30 (FROZEN) — additive: §13 (Payment Control Plane) introduced by ADR-027 v0.2 RATIFIED. Establishes BSE as the estate's payment control plane and codifies the seven-rail invariant (RTGS, Instant, ACH, Correspondent, Card/PSP, Custodian/DVP, TREICHTEC-DLT). BSE-first ordering, no-bypass, and BSE-mediated AIOS/TREICHTEC events. BSE joins LCGX/Gateway/Nexus in the infrastructure tier; it is not a plane. §12 (Account Model) from ADR-014.1 v0.2 (2026-08-29) is also folded in at this version. Motions: T3 founder-consent Motion 2 (2026-08-24) delegating FROZEN authority; T3 founder-consent Motion 3 (2026-08-30) ratifying ADR-027. No prior invariants revised.
v2.1 — 2026-08-29 (DRAFT) — additive: introduces §12 Account Model (namespace, identifier grammar, plane binding) tracking the RATIFIED specification of record. Depends on the Account Model & Naming Specification v0.2 (2026-08-29) and the Nexus RBAC matrix v0.2. No modification to §1-§11. No renumbering.

1. Plane roster (memorise this)

The BLACKSWAN estate has eight top-level planes. Seven are OS planes on the same delivery tier; one is the constitutional plane.

The seven OS planes

Plane	Full name	Codename	Surface	Canonical repo
CMOS	Capital Markets Operating System	Falcon	marketing	`BlackswanCapitalMarketsOS`
PMOS	Private Markets Operating System	Swan Nest	marketing	`BlackswanPrivateMarketsOS`
HSOS	Hedge & Sovereign Operating System	—	governed	`BlackswanHedgeSovereignOS`
AIOS	AI Operating System (24-row registry)	—	marketing	`BlackswanAIOS`
TREICHTEC	DLT execution plane	Digital Swan DLT	marketing	`BlackswanTreichtecDLT`
SCFOS	Supply Chain Finance Operating System	—	marketing	`BlackswanSCFOS`
GOVCOS	Governance & Compliance Operating System	—	governed	`BlackswanGOVCOS`

Marketing vs governed surface. A marketing surface renders as a public Nexus launcher card (fifth-card grid, see §7). A governed surface (HSOS, GOVCOS) does not render as a Nexus card — it appears in Command Centre, gateway plane surfaces, and estate diagrams with a GOVERNED SURFACE chip in place of the palette-swatch strip (BLACKSWAN visual-language spec §2.4). Governed surfaces are not less important; they carry stewardship and posture obligations that are inappropriate for a public launcher card.

The constitutional plane

Plane	Full name	Posture (terminal)	Canonical repo
LCGX	Lybrosis Capital · Global eXchange	`STANDBY · IN-MEMORY ONLY · HOLD · NO-GO`	`BlackswanLCGX`

LCGX is the constitutional plane — the source of authority the other planes reference. Its posture is terminal — it does not advance. No other document, blueprint, or repository may claim the "constitution" title.

Launcher (not an OS plane)

Nexus is a hub-and-spoke launcher and access-control plane. It is not:

an OS plane
an infrastructure layer
a control plane
an "ecosystem brain"
the parent of any rails

Nexus renders as a 5-card grid: falcon · swan-nest · digital-swan · ai · scfos — this render is invariant at v2.0. HSOS and GOVCOS are off-card as governed surfaces (see §7).

Nexus scope is limited to: (a) authenticated launcher, (b) SSO cross-plane via Entra ID, (c) entitlements enforcement, (d) a service catalogue for browsing enrolled apps.

Repos related to the launcher/spine: blackswan-os-spine, and eventually a dedicated blackswan-nexus if needed.

See also §11 (Estate Domains). The plane roster above is the deployment view of the estate. Estate Domains are the capability view — logical capabilities that cut across planes. Every plane implements a subset of Domains; every Domain is implemented by one or more planes. Neither view subsumes the other.

2. AIOS row-vs-plane hierarchy (do not flatten)

AIOS is a 24-row registry parent. Rows 1-23 are AIOS siblings — each is its own repo under the naming pattern aios-<slug>. Row 24 is the LCGX pointer.

Current AIOS sibling roster (partial, all with posture STANDBY · IN-MEMORY ONLY · HOLD · NO-GO):

aios-trackpro · aios-globecover · aios-globecross · aios-correctiveglobal · aios-acr · aios-gffx (PaxTradeX) · aios-globecoin · aios-nafolowealth · aios-propafrica · aios-crookshild · aios-i-ink · aios-votelect · aios-g-visa · aios-capitaf · aios-afreezone · aios-aggrego · aios-commotable · aios-ventura · aios-allocator · aios-cardinal-points · aios-clusterai · aios-tripartite-ai · aios-qrm-ai · aios-lcgx (row 24 pointer)

Rule: TRACKPRO, GLOBECOVER.AI, GLOBECROSS, CORRECTIVE GLOBAL, ACR, and all other aios-* siblings are AIOS rows, not OS-plane peers. Do not list them at the same level as CMOS/PMOS/HSOS/AIOS/TREICHTEC in any UI, diagram, or repo structure.

3. Vocabulary (closed set)

Sponsor line (verbatim)

Mamadou Ly, Founder, Managing Partner & CEO

Appears verbatim in every user-facing footer, About page, and signed communication.

Forbidden phrases outside chain-only scope

Do not use in code, docs, marketing copy, or diagrams:

blockchain
cryptographic
chain of custody
hash chain
landed (use SHIPPED instead)

When referring to the DLT plane specifically, use TREICHTEC DLT or Digital Swan DLT. When referring to settlement records, use settlement records or verifiable records.

AIOS capability tags (closed set)

Only these tags are schema-permitted for AIOS row capability fields:

ai, data, governance, identity, market, media, payments, realestate

No other tags are allowed. The verifier will reject.

Posture line

All OS planes and LCGX carry the posture:

STANDBY · IN-MEMORY ONLY · HOLD · NO-GO

Use the U+00B7 middle-dot (·) as separator — not hyphen, not pipe.

Typographic conventions

Curly quotes U+201C / U+201D on taglines, Copilot questions, marketing copy.
Middle-dot · (U+00B7) in ticket ids (e.g. CMOS EOC·01) and posture chains.
Never landed — always SHIPPED.
TREICHTEC — no h before the final c. Never Treichtech, treichtech, TREICHTECH.

4. Technology stack (canonical)

For any BLACKSWAN estate work, the canonical stack is:

Layer	Canonical	Alternatives	Never
Identity / SSO	Microsoft Entra ID (OIDC)	—	Auth0, Azure AD (old name — same product, wrong label), Supabase Auth
Primary database	PostgreSQL	TimescaleDB extension for time-series (PMOS default)	Supabase (managed DB), MySQL
Cloud	Microsoft Azure	—	Vercel (preview only), AWS (unless explicitly approved)
Frontend	React + TypeScript + Tailwind CSS	Next.js 15 (App Router) for SSR-heavy surfaces; Vite for pure SPA	—
Motion	Framer Motion	—	—
3D	Three.js + React Three Fiber	—	—
Maps	Mapbox GL	—	—
Charts / data viz	D3.js, Recharts	—	—
Streaming	Kafka (KafkaJS in Node)	—	—
Observability	OpenTelemetry	—	—
CI/CD	GitHub Actions	—	—
Containers	Docker	Kubernetes for production orchestration	—
Monorepo (where applicable)	pnpm workspaces + Turborepo	—	—

Payments & billing — canonical model is ledger-only manual settlement (see wiki concepts/blackswan-payments-billing-ledger). Do not propose payment rails, correspondent banking, stablecoin interfaces, or cross-border messaging systems in public copy or in scope for any current lane.

DLT — settlement records and DLT concerns live inside BlackswanTreichtecDLT. Do not fork DLT scope into other repos.

5. Repository conventions

Naming patterns

OS planes: Blackswan<PlaneName>OS (e.g. BlackswanCapitalMarketsOS).
AIOS rows: aios-<slug> (lowercase, hyphenated).
LCGX sub-systems: lcgx-<slug> (lowercase, hyphenated) — e.g. lcgx-lrm, lcgx-ga, lcgx-bsp.
LCGX depth-drill grandchildren: lcgx-<parent>-<slug> (e.g. lcgx-lrm-grid, lcgx-ga-gsp).
Estate-wide surfaces: blackswan-<purpose> (lowercase) — e.g. blackswan-gateway, blackswan-os-spine, blackswan-nexus (reserved).

Branch and merge policy

main is protected on all canonical repos. Direct pushes to main are prohibited.
Work happens on feature branches via PR.
Merge policy: squash-merge + delete branch. Command:
```
gh pr merge <N> --squash --delete-branch
```
If the local post-merge checkout fails (common on sparse worktrees), the remote squash still succeeded — verify with gh pr view <N>.

Commit identity

For any commit authored on behalf of the sponsor:

git -c user.name="Mamadou Ly" -c user.email="yhvk9sj7k7@privaterelay.appleid.com"

`.chain/` seals

HSOS and other planes maintain .chain/ seal files. Preserve all existing seal files byte-identical. Only ADD new terminal seals — never mutate or reorder existing ones. This is chain-only scope; the phrases chain of custody and hash chain may appear inside .chain/ code and docs, but not in public copy.

6. Delivery cadence and postures

Current estate posture (as of 2026-07-11)

All OS planes and LCGX: STANDBY · IN-MEMORY ONLY · HOLD · NO-GO.

This means:

Nothing is in production.
Nothing is GA.
No marketing copy may claim "live", "shipping", "in production", "available", or "GA".
Any deployed surface must carry a visible prototype banner: "Visual prototype — do not submit real confidential, KYC, payment, or institutional data."

Ticket-ID style

Ticket IDs use middle-dot separators: CMOS EOC·01, PMOS PB·111, AIOS·2·06, GFFX·00·01. Case follows plane convention (uppercase plane name, uppercase or numeric lane id).

PR completion vocabulary

Use SHIPPED for a merged PR that closes a lane. Never landed.
Use AUDITED for a plane state that passed a verifier run.
Use DRIFT-CLOSED for a plane state where drift was detected and corrected.
Use MATCH for a verifier row that passed. Use DRIFT for one that failed.

7. Nexus render rule (invariant at v2.0)

The Nexus launcher render is a 5-card grid:

┌──────────┬───────────┬──────────────┬──────┬────────┐
│  falcon  │ swan-nest │ digital-swan │  ai  │  scfos │
│  (CMOS)  │  (PMOS)   │ (TREICHTEC)  │(AIOS)│ (SCFOS) │
└──────────┴───────────┴──────────────┴──────┴────────┘

HSOS is not on the Nexus card render. GOVCOS is not on the Nexus card render. LCGX is not on the Nexus card render. This is deliberate — Nexus renders customer-facing launchers; HSOS and GOVCOS are governed surfaces (see §1) and LCGX is the constitutional plane. All three appear in Command Centre and in the estate diagram (§8) with the appropriate surface treatment.

If a diagram or UI needs to show all seven OS planes plus LCGX plus Nexus, use the estate diagram in Section 8. If a UI needs to enumerate governed surfaces, it renders them with the GOVERNED SURFACE chip in place of the palette-swatch strip — never as marketing cards.

8. Canonical estate diagram (use this shape)

                            Users & Institutions
                                     │
                                     ▼
                          BLACKSWAN Gateway
                    (marketing site · landing · signup)
                                     │
                        Microsoft Entra ID (OIDC SSO)
                                     │
                                     ▼
                          BLACKSWAN Nexus
                    (launcher · 5-card render · entitlements)
                                     │
     ┌───────┬────────┬────────┬────────┬──────────┬────────┬────────┐
     │       │        │        │        │          │        │        │
     ▼       ▼        ▼        ▼        ▼          ▼        ▼        │
    CMOS    PMOS    HSOS     AIOS    TREICHTEC    SCFOS   GOVCOS     │
  (Falcon) (Swan  (governed)         (24-row     (Digital        (governed)
           Nest)                     registry)   Swan DLT)                │
                                        │                                 │
                                        ▼                                 │
                               23 aios-* siblings                         │
                               + row 24 LCGX pointer                      │
                                                                          │
                                                                          │
                          ────────────────────────────────────────────────┘
                                     ▼
                          LCGX — constitutional plane
                       (external · STANDBY · terminal)

Notes:

Nexus does not own the rails. Any rails/services/data-fabric belong inside individual planes, not above them.
AIOS is a plane and a registry — the plane hosts the 24-row registry; the sibling repos live one level below AIOS logically.
HSOS and GOVCOS are governed surfaces — first-class planes but not rendered as Nexus launcher cards. Their Command Centre and gateway surfaces use the GOVERNED SURFACE chip.
SCFOS is a marketing surface admitted to the Nexus render at v2.0 — supply-chain finance has public LP-side and corporate-treasury operator paths.
LCGX sits outside the OS-plane pipeline — it is referenced by AIOS row 24 but does not participate in normal delivery.

9. What contributors (human or AI) must NOT do

Common drift patterns observed. Refuse these categorically:

Do not invent a "BLACKSWAN Digital Operating System" umbrella. The estate does not have one. Each OS plane is its own operating system; there is no super-OS above them.
Do not propose new "constitutions" or "blueprints" that govern the whole estate. LCGX is the constitutional plane. Blueprints scope to a single plane or a single surface.
Do not flatten AIOS rows into OS-plane peers.
Do not use blockchain in any public copy.
Do not propose Auth0, Azure AD (old name), or Supabase.
Do not propose Vercel as production deployment.
Do not push directly to main on any canonical repo.
Do not misspell TREICHTEC.
Do not restructure the Nexus render outside a ratified Canon amendment. The current invariant is a 5-card grid (falcon · swan-nest · digital-swan · ai · scfos) at v2.0. Changing the number of cards, the plane-to-card mapping, or the ordering requires a fresh Canon amendment PR with a major version bump (§0).
Do not mutate .chain/ seal files.
Do not use landed — use SHIPPED.
Do not claim any plane is "live", "GA", "in production", or "shipping" — current posture is STANDBY · IN-MEMORY ONLY · HOLD · NO-GO for all planes.
Do not propose payment rails, correspondent banking, or cross-border settlement systems — canonical model is ledger-only manual settlement.
Do not conflate Nexus with an infrastructure layer, control plane, or AI agent.
Do not commit without the sponsor commit identity when authoring on behalf of Mamadou Ly.
Do not propose amendments to the Canon inside an artifact PR. Canon amendments happen only in dedicated PRs against docs/blackswan-estate-canon.md, reviewed by the sponsor, with a version bump per §0. If a proposed artifact conflicts with the Canon, either reshape the artifact or open a separate Canon-amendment PR first.

10. Quick-reference index (canonical wiki pages)

Full detail lives in the knowledge wiki. Load the relevant page before deep work:

Entities:

entities/blackswanpartnership — the GitHub organization
entities/mamadou-ly — sponsor and product architect

Concepts:

concepts/gmh-pb-111-series — Portfolio Bonds Series and v9 Wave-3 envelope (HSOS)
concepts/lcgx-depth-drill — LCGX LRM/GA grandchild-repo structure
concepts/lcgx-fixture-invariant — LCGX canonical fixture-count contract
concepts/microsoft-entra-oidc — identity foundation for SPA/API and BLACKSWAN SSO
concepts/blackswan-payments-billing-ledger — ledger-only manual-settlement model

Projects:

projects/blackswan-aios — 24-row AI registry with LCGX pointer
projects/blackswan-capital-markets-os — Falcon (CMOS) with P0 launch gates
projects/blackswan-command-centre-prototype-* — HSOS CC2 through CC10 module manifests
projects/blackswan-hedge-sovereign-os — HSOS and PB 111 execution plane
projects/blackswan-lcgx-plane — constitutional LCGX mega-system plane
projects/blackswan-nexus — hub-and-spoke launcher and access control plane
projects/blackswan-private-markets-os — Swan Nest (PMOS)
projects/blackswan-treichtec-dlt — Digital Swan DLT execution plane

11. Estate Domains (orthogonal capability view)

11.1. Purpose

§1 defines planes — the deployment/repository unit of the estate. §11 defines Domains — the logical-capability unit that cuts across planes. The two views are orthogonal and neither subsumes the other:

A plane is where code lives: a repository, a deployment, a posture, a versioning stream.
A Domain is what a capability is: a coherent bundle of institutional intent that may be implemented by one plane, several planes, or a shared cross-plane surface.

Every plane implements a subset of Domains. Every Domain is implemented by one or more planes. Domains are NOT additional planes and NEVER take a plane's posture, changelog, or deployment.

11.2. Domain roster (v1.1 · 7 domains)

#	Domain	One-line intent	Primary planes implementing
1	Identity	The person, principal, or service — who is acting, authenticated via Entra OIDC, mapped to a role. Subsumes Access as its enforcement artefact.	Gateway (SSO shell), every plane consumes
2	Institution	The institutional counterparty profile — LPs, GPs, funds, admins, banks, custodians, sovereign entities. The who on the other side of every capital flow.	PMOS, HSOS
3	Capital	All flows of value, regardless of purpose — investment, treasury, reserve, allocation, drawdown, distribution. The what moved.	PMOS, HSOS, CMOS
4	Settlement	The mechanics of moving value — instructions, matching, netting, confirmation, reconciliation. The how of Capital flows. Kept separate from Capital because settlement is orthogonal to the intent of the flow.	CMOS, TREICHTEC
5	Risk	Market, credit, operational, and compliance risk. Measurement, limits, alerts, jurisdictional permissions.	CMOS, HSOS, PMOS
6	Intelligence	Analytics, forecasting, decision support, insights. AI is the substrate used by this Domain, not a Domain itself.	AIOS (as row registry), consumed by every plane
7	Governance	Audit, controls, evidence, sign-off, regulatory approvals, sponsor authority, gate closure, HOLD/NO-GO management.	Every plane emits; Gateway curates estate-level evidence

11.3. What a Domain is NOT

A Domain is NOT a plane. Domains have no repositories, no postures, no .chain/ files, no deployment.
A Domain is NOT a folder inside a plane. Planes may organise code by Domain or by feature; that is a plane-internal decision.
A Domain is NOT a microservice boundary. Domains describe intent; microservices describe deployment shape. A Domain may span many services or one.
A Domain is NOT a Nexus card. The Nexus render (§7) is a 5-card plane view at v2.0; §11 does not change §7.
A Domain is NOT a marketing surface. Domains are internal governance vocabulary and do not appear on blackswanpartnership.com or any user-facing copy.

11.4. Vocabulary rule (extends §3)

The seven Domain names in §11.2 are additions to the §3 closed set. Any writing about the estate that refers to a Domain MUST use the exact term from §11.2 (case as shown, singular form). No synonyms permitted: "capital movement" is not the same as "Capital Domain"; "risk management" is not "Risk Domain". The word "Domain" is capitalised when the Estate meaning is intended.

11.5. Re-freeze condition for v1.1

v1.1 is DRAFT until the Domain roster passes one full external-review cycle without additions, removals, or renames. When re-frozen:

The version line changes from v1.1 — DRAFT to v1.1 — FROZEN.
The §0 changelog gains a - **v1.1 re-frozen — YYYY-MM-DD** entry.
No structural change; only state transition.

Any structural change to §11 (adding an 8th domain, splitting Capital, merging Identity+Institution) requires a new v1.x additive amendment and NEW ## 12. section — never a mutation of §11.

11.6. Non-goals

No Domain owns a plane. Planes remain the sponsor-owned, sole-source-of-truth deployment unit.
No Domain has a posture. Planes carry postures per §6; Domains do not.
No Domain has an SLA, uptime, or availability target. Those live at the plane or service level.
No Domain has a Sprint or Wave numbering. Delivery cadence remains per plane per §6.
No Domain has a URL. Gateway subdomains map to planes per BGXS §3.1, never to Domains.

Sponsor: Mamadou Ly, Founder, Managing Partner & CEO.

12. Account Model (Namespace, Identifier Grammar, Plane Binding)

12.1. Purpose

§12 is the canonical statement of how BLACKSWAN identifies, classifies, and hierarchically nests every account holder the platform will ever open. It defines the identifier grammar that sits underneath every plane, every ledger, every wallet, every sync job, and every settlement address. It is additive to §1 and §11: §1 defines the planes, §11 defines the Domains, §12 defines the identity-and-account grammar that traverses both.

The specification of record is governance/account-model/2026-08-29-blackswan-account-model-and-naming-specification-v0.2.md, RATIFIED 2026-08-29. This section restates its normative bindings in Canon-native form.

12.2. Namespace registry (11 canonical namespaces)

Every BLACKSWAN account holder receives a root identifier in one of exactly eleven namespaces:

#	Namespace	Entity type	Root pattern	Example
1	`SOV`	Sovereign / public sector spine	`ISO2NNN`	`GB185`
2	`IND`	Individual / natural person	`ISO2-IND-NNNNNN`	`GB-IND-000001`
3	`COR`	Corporation / legal person	`ISO2-COR-NNNNNN`	`GB-COR-000001`
4	`BUS`	Business / sole trader / SME	`ISO2-BUS-NNNNNN`	`GB-BUS-000001`
5	`INS`	Institution not otherwise classified	`ISO2-INS-NNNNNN`	`GB-INS-000001`
6	`FND`	Fund / pooled-capital vehicle	`ISO2-FND-NNNNNN`	`GB-FND-000001`
7	`TRU`	Trust	`ISO2-TRU-NNNNNN`	`GB-TRU-000001`
8	`FAM`	Family office	`ISO2-FAM-NNNNNN`	`GB-FAM-000001`
9	`NGO`	Non-governmental organisation	`ISO2-NGO-NNNNNN`	`GB-NGO-000001`
10	`SPV`	Special-purpose vehicle	`ISO2-SPV-NNNNNN`	`GB-SPV-000001`
11	(implicit)	Sovereign institutional child of `SOV`	`ROOT-<CLASS>[-NNN\|-ISO2\|-NNNNN]`	`GB185-TRE`, `GB185-EMB-FR`

Sovereign roots carry a three-digit serial (NNN, 001-195, alphabetical, from the Government Account Register). Non-sovereign roots carry a six-digit serial (NNNNNN, per jurisdiction, per namespace). Serials are immutable once issued.

12.3. Sovereign institutional class taxonomy (16 classes)

Under SOV, the sovereign side of BLACKSWAN has 16 canonical classes, materialised as 195 sovereigns × 16 classes = 3 120 tier-1 accounts:

ROOT, GOV, CB, TRE, SWF, DMO, TAX, RES, MIN, AGY, PCE, DBK, SUB, EMB, PRJ, WLT.

Full pattern table lives in the specification of record §2.2. Embassies use ROOT-EMB-ISO2 (host jurisdiction). Government projects use ROOT-PRJ-NNNNN. Government wallets nest as ROOT-WLT-NNN[-AAA] and project wallets as ROOT-PRJ-NNNNN-WLT-NNN.

12.4. Invariants (I-01 through I-10)

The following ten invariants are Canon-level. Any deviation is a governance incident:

I-01 Immutable identity. One persistent IND root per natural person; corporate access never creates a second person identity.
I-02 No PII in identifier. Do not encode name, DOB, email, phone, role, or ownership in the primary identifier.
I-03 Jurisdiction prefix. ISO 3166-1 alpha-2 under a documented policy; later jurisdiction changes travel through metadata and governance.
I-04 Legal-entity separation. Corporate/business roots identify entities; accounts and wallets are children.
I-05 User-seat separation. A corporate user seat belongs to the company but links to the person's IND root.
I-06 Relationship separation. Roles, authority, UBO/shareholding, mandates, effective dates live in REL records.
I-07 Account multiplicity. A single root may own multiple ACC and WLT records.
I-08 Auditability. Never recycle identifiers after closure.
I-09 Display names are metadata. Names and trading names are mutable metadata, not primary keys.
I-10 Sequence immutability. Do not renumber historical accounts after country- or entity-name changes; append at next unused serial.

12.5. Object grammar (four object types)

Root — the identifier itself (per §12.2).
Account — <root>-ACC-NNN (non-sovereign) or sovereign class per §12.3.
Wallet — <root>-WLT-NNN[-AAA], with sub-wallet mnemonic suffix.
User seat — <corporate root>-USR-NNNNNN, linked to an IND root.
Relationship — REL-NNNNNNNN, registrar-issued.

12.6. Plane binding (canonical)

Every namespace binds to one or more of the seven planes under §1. Exactly one plane is designated plane of record per root.

Plane	§7 position	Primary namespaces	Off-card / on-card
CMOS	On-card 1	`INS`, `COR`, `FND`	On-card
PMOS	On-card 2	`FND`, `FAM`, `SPV`, `COR`	On-card
TREICHTEC	On-card 3	`INS`, `SPV`, `FND`, `COR` (+ sovereign custody wallets)	On-card
AIOS	On-card 4	Any (operator plane)	On-card
SCFOS	On-card 5	`BUS`, `COR`, `INS`, `NGO`	On-card
HSOS	Governed off-card	`FND`, `FAM`, `INS`, `SPV`, `SOV/SWF`	Off-card, `governed: true`
GOVCOS	Governed off-card	All `SOV/*`, `INS` (with sovereign licence)	Off-card, `GOVERNED SURFACE` chip

Sovereign plane-of-record changes route through ADR-022. Non-sovereign plane-of-record changes route through the standard mandate registry.

12.7. What §12 is NOT

§12 is NOT a data-model DDL specification. DDL is a follow-on artefact after the specification of record is RATIFIED (already achieved 2026-08-29).
§12 is NOT a KYC/KYB SOP. Per-namespace onboarding runbooks are separate artefacts.
§12 is NOT a plane. Namespaces are cross-plane; they do not carry postures, deployments, or Nexus tiles.
§12 is NOT a Domain. Under §11 Domains describe capability intent; namespaces describe the identity of the account holder invoking a capability. Every request through the estate carries both a Domain and a namespace.
§12 is NOT a Nexus render specification. §7 governs the Nexus card grid; §12 does not modify it.

12.8. Vocabulary rule (extends §3 and §11.4)

The eleven namespace codes in §12.2 and the sixteen sovereign classes in §12.3 are additions to the §3 closed vocabulary. Writing about accounts, wallets, or holders MUST use the exact codes as shown. No synonyms: "individual account" is not the same as IND-root; "government wallet" is not the same as SOV/WLT; "SWF" is a class code, not a marketing label.

12.9. Amendment policy

Any change to the eleven namespaces, the sixteen sovereign classes, the ten invariants, or the plane binding requires a superseding ADR and a new specification version. Historical identifiers are never renumbered (I-10). The Canon §12 text tracks the specification of record; when the specification promotes to v0.3 or beyond, §12 is refreshed by a new v2.x amendment PR.

12.10. Cross-references

Specification of record: governance/account-model/2026-08-29-blackswan-account-model-and-naming-specification-v0.2.md
Nexus RBAC matrix: governance/account-model/2026-08-29-nexus-rbac-matrix-v0.2.md
ADR-022 (GOVCOS co-management model, sovereign plane-of-record governance)
ADR-026 DRAFT (GOVCOS C5 BSP-GOVCOS Common Controls Artifact)

Sponsor: Mamadou Ly, Founder, Managing Partner & CEO.

13. Payment Control Plane (BSE authoritative)

Introduced by ADR-027 (RATIFIED v0.2, 2026-08-30). Additive to the Canon.

BSE is the payment control plane of the BLACKSWAN estate. Every payment instruction — regardless of originating plane, agent identity (human or AIOS), or rail destination — passes through BSE for identity resolution, entitlement check, mandate check, limit check, screening, pricing, risk and SLA assignment, and rail selection before it reaches a rail.

13.1. Seven rails (invariant at v2.2)

The estate settles payments on exactly seven rails, codified in the rails architecture workbook:

RTGS (real-time gross settlement)
Instant / Faster Payments (retail and mid-corporate real-time)
ACH / batch clearing
Correspondent banking (cross-border and pre-funded chains)
Card / PSP
Custodian / DVP settlement
TREICHTEC-DLT (programmable-settlement rail)

TREICHTEC-DLT is one rail among seven. It is not "the settlement layer" and no other rail is subordinate to it.

13.2. Invariants

BSE-first ordering. No payment instruction reaches a rail before BSE resolution.
No BSE-bypass rail. Internal transfers, testing environments, sovereign carve-outs, and TREICHTEC-DLT programmable settlement all pass through BSE.
BSE metadata is a first-class message property. Every routed instruction carries the resolution artefact inline as a signed envelope.
Sovereign carve-outs go through BSE. Policy exemptions are BSE configurations, not BSE bypasses.
AIOS and TREICHTEC events are BSE-mediated. Agent-initiated flows have no privileged path.

13.3. Relationship to §1 plane roster

BSE is not a plane. It is a cross-cutting control plane that sits above every plane's payment surface and below every regulated rail. The seven OS planes of §1 continue to be the seven OS planes; BSE joins the LCGX / Gateway / Nexus infrastructure tier as a fourth infrastructure element.

13.4. Follow-on ADRs (declared)

ADR-028 · BSE availability SLA
ADR-029 · BSE schema versioning policy
ADR-030 · Rail onboarding checklist
ADR-031 · AIOS payment mandate policy

None are blocking on §13.

13.5. Cross-references

ADR-027 · BSE as Payment Control Plane · RATIFIED v0.2 · 2026-08-30
Rails architecture workbook: commercial/architecture/BLACKSWAN_Bespoke_Payment_Rails_Architecture_v0.1.xlsx
§12 Account Model (BSE identity resolution reads from §12 grammar)
§1 Plane roster (BSE is not a plane; it is an infrastructure element)

Sponsor: Mamadou Ly, Founder, Managing Partner & CEO.

14. Auth-topology invariant (one estate, one sign-in)

Ratified under Motion 14.1 · 2026-09-08.

BLACKSWAN presents to users as one estate with seven surfaces (Canon §1, §7, §8). Auth topology follows the same shape: one estate, one sign-in.

14.1 Invariant

The gateway is the sole OIDC relying party for the BLACKSWAN estate. Every plane — CMOS, PMOS, HSOS, AIOS, TREICHTEC, SCFOS, GOVCOS, and every future plane — is a downstream JWT-cookie consumer of the session minted by the gateway.

Downstream planes MUST NOT:

Register their own Entra app for user authentication.
Hold an Entra client secret for user authentication.
Run an OIDC authorisation-code flow.
Mint or issue session tokens.
Set the estate session cookie (only the gateway may set it).

Downstream planes MUST:

Read the estate session cookie set by the gateway on the shared estate domain.
Verify the token's signature against a public key (fetched from the gateway JWKS URL or from Entra's JWKS URL where the gateway federates directly).
Extract user claims (subject, roles, entitlement, tenant) from the verified token.
Serve authenticated requests without a further sign-in interaction.

14.2 Structural binding

§14.1 binds all seven present planes and all future planes. A plane's onboarding cannot complete under Canon v2.0 without demonstrating that it is a downstream verifier, not an OIDC RP.

A plane MAY:

Consume machine-to-machine OAuth flows (client-credentials grant) against non-user identities for backend integrations. These are not user sign-in flows and are outside the scope of §14.
Federate its own back-office admin console (if any) against Entra, provided the admin console is not on the user-facing Nexus surface and is documented as such in the plane's ADR track.

14.3 Applicability to REPO overlay design

Per-plane REPO overlays (ADR-021 v0.3, ADR-034 v0.2) MUST reflect §14.1. The 4 Entra keys AZURE_AD_CLIENT_ID, AZURE_AD_TENANT_ID, AZURE_AD_CLIENT_SECRET, AUTH_TRUST_HOST are a gateway-only overlay. They MUST NOT appear in any downstream plane's REPO_STICKY_REQUIRED set.

Downstream planes' Category A REPO overlay is token-verifier keys (session cookie name, gateway JWKS URL, expected issuer, expected audience). The specific set per plane is derived by discovery against each plane's code.

14.4 Enforcement

Per-plane deploy verifier gates (ADR-024.1 v0.4) reject any PR that adds an Entra client-credential key to a downstream plane's REPO_STICKY_REQUIRED.
The Nexus render rule (§7) already renders one shared session across the card grid; a downstream OIDC redirect would break §7.
Any proposal to run a per-plane OIDC RP requires an amendment to this section, adopted under a signed founder-consent motion.

14.5 Rationale

One sign-in preserves the "one estate, seven surfaces" North Star. Per-plane OIDC RPs would fragment sessions, multiply consent screens, produce ambiguous sign-out semantics, and create seven Entra objects to keep aligned with Conditional Access policies. Centralising the RP at the gateway localises the client-secret blast radius, produces one identity truth per user, and matches what CMOS (the pilot plane) ships as of 2026-09-08.

Sponsor: Mamadou Ly, Founder, Managing Partner & CEO.

BLACKSWAN Estate Canon · v2.3 — FROZEN · authored 2026-07-11 · v1.0 frozen 2026-07-11 · v1.1 DRAFT 2026-07-11 · v2.0 DRAFT 2026-08-24 (ADR-014) · v2.0 FROZEN 2026-08-30 (T3 founder-consent Motion 2, 2026-08-24) · v2.1 DRAFT 2026-08-29 (ADR-014.1 §12) · v2.2 FROZEN 2026-08-30 (ADR-027 §13, T3 founder-consent Motion 3) · v2.3 FROZEN 2026-09-08 (Canon §14, T3 founder-consent Motion 14.1) · sponsor Mamadou Ly, Founder, Managing Partner & CEO.

BLACKSWAN Estate Canon

0. Versioning and amendment policy

Amendment procedure

Version-bump rule

Changelog

1. Plane roster (memorise this)

The seven OS planes

The constitutional plane

Launcher (not an OS plane)

2. AIOS row-vs-plane hierarchy (do not flatten)

3. Vocabulary (closed set)

Sponsor line (verbatim)

Forbidden phrases outside chain-only scope

AIOS capability tags (closed set)

Posture line

Typographic conventions

4. Technology stack (canonical)

5. Repository conventions

Naming patterns

Branch and merge policy

Commit identity

.chain/ seals

6. Delivery cadence and postures

Current estate posture (as of 2026-07-11)

Ticket-ID style

PR completion vocabulary

7. Nexus render rule (invariant at v2.0)

8. Canonical estate diagram (use this shape)

9. What contributors (human or AI) must NOT do

10. Quick-reference index (canonical wiki pages)

11. Estate Domains (orthogonal capability view)

11.1. Purpose

11.2. Domain roster (v1.1 · 7 domains)

11.3. What a Domain is NOT

11.4. Vocabulary rule (extends §3)

11.5. Re-freeze condition for v1.1

11.6. Non-goals

12. Account Model (Namespace, Identifier Grammar, Plane Binding)

12.1. Purpose

12.2. Namespace registry (11 canonical namespaces)

12.3. Sovereign institutional class taxonomy (16 classes)

12.4. Invariants (I-01 through I-10)

12.5. Object grammar (four object types)

12.6. Plane binding (canonical)

12.7. What §12 is NOT

12.8. Vocabulary rule (extends §3 and §11.4)

12.9. Amendment policy

12.10. Cross-references

13. Payment Control Plane (BSE authoritative)

13.1. Seven rails (invariant at v2.2)

13.2. Invariants

13.3. Relationship to §1 plane roster

13.4. Follow-on ADRs (declared)

13.5. Cross-references

14. Auth-topology invariant (one estate, one sign-in)

14.1 Invariant

14.2 Structural binding

14.3 Applicability to REPO overlay design

14.4 Enforcement

14.5 Rationale

`.chain/` seals