BLACKSWAN Gateway Experience Standard (BGXS)

Version: v1.2 (authored 2026-07-11 · amended 2026-07-11 · locked 2026-07-12 · amended 2026-07-14 · amended 2026-07-14) Sponsor: Mamadou Ly, Founder, Managing Partner & CEO Scope: This document defines the user experience of the BLACKSWAN Gateway — the public-facing marketing surface, SSO shell, and ecosystem directory hosted at blackswan-gateway. It governs how the gateway looks, feels, and moves, not what the estate contains.

Inheritance: BGXS is a subordinate document to the BLACKSWAN Estate Canon. The Canon governs the estate; BGXS governs the gateway. Where the two speak to the same subject, the Canon wins. BGXS cannot override, reinterpret, or amend the Canon. If a BGXS requirement conflicts with the Canon, either reshape the BGXS requirement or open a separate Canon-amendment PR per Canon §0 before proceeding.

Read time: ~7 minutes.

0. What BGXS answers (and what it does not)

BGXS answers the five gateway questions the Canon deliberately leaves open:

What should visitors see?
How should the gateway feel?
How do users move from public content into authenticated access?
How is the cinematic Black Swan sequence integrated?
How do institutional users discover the ecosystem?

BGXS does not answer:

Plane roster, vocabulary, tech stack, delivery cadence, or prohibitions — those live in the Canon (§1–§9).
Backend design of any OS plane — that lives in each plane's own repo.
The constitutional plane — that is LCGX, which BGXS never renders.

Position in the governance stack

BLACKSWAN Estate Canon v2.2              ← constitutional governance
    ↓
BLACKSWAN Reference Architecture (BSRA)   ← technical architecture
    ↓
BLACKSWAN Gateway Experience Standard    ← this document (public gateway experience)
    ↓
BLACKSWAN Enterprise Design Language     ← visual + interaction tokens
    ↓
Implementation Standards                 ← coding, repos, CI, testing, security, deploy

BGXS specifies the gateway; BEDL specifies the tokens the gateway consumes; Canon governs both; BSRA describes the technical architecture BGXS operates within; Implementation Standards define how it is built.

1. Question 1 — What should visitors see?

1.1 Audience model (three concentric rings)

The gateway serves three ring-audiences, in this order of prominence:

Institutional visitors (LPs, sovereign wealth desks, hedge fund allocators, capital markets counterparties, regulators). Highest-value ring. Everything above the fold must resonate with this audience first.
Ecosystem participants (partner firms, service providers, prospective hires, ecosystem developers). Second ring.
General public (press, retail interest, curious readers). Third ring — served but never centred.

Design decision: the gateway is a statement surface, not a lead-capture funnel. No newsletter modals, no cookie banners beyond regulatory minimum, no chat widgets, no "book a demo" CTAs above the fold.

1.2 Landing surface (above the fold, first paint)

Exactly four elements, in this stacking order:

Nav bar — top-left wordmark BLACKSWAN, top-right nav (Estate · Access · Contact). Nothing else.
Cinematic Black Swan sequence — full-viewport hero (see §4).
Statement line — a single line, curly quotes, dark background, gold accent. Locked: “Institutional discipline for markets that cannot afford drift.” Sponsor-locked 2026-07-12; design shape (one line, curly quotes, gold accent) locked by BGXS.
Posture strip — small, bottom of viewport: STANDBY · IN-MEMORY ONLY · HOLD · NO-GO — middle-dot separator, muted colour. Required on every non-authenticated page. Never removed until sponsor advances estate posture.

Not on the landing: feature grids, testimonials, logo walls, metric counters, blog previews, product screenshots. All of these belong deeper in the tree, not on the first paint.

1.3 Below the fold (single scroll depth, three sections max)

Scroll 1: The estate at a glance — a static diagram of the 6-plane structure (5 OS + LCGX pinned separately), rendered as a read-only visualisation. Non-interactive on public surface. Labels only, no click-through — click-through is gated behind Access (§3).

Scroll 2: Sponsor line — verbatim as required by the Canon: Mamadou Ly, Founder, Managing Partner & CEO. Small, dignified, single line.

Scroll 3: Footer — legal, privacy, contact email, GitHub org link. No social icons on public surface v0.1.

That is the entire public marketing surface for v0.1. Additional pages (About, Estate detail, Press) are deferred to BGXS v0.2+.

2. Question 2 — How should the gateway feel?

Every visual and motion decision must satisfy all four of these adjectives. If any decision fails on any adjective, it does not ship.

Adjective	Meaning at the gateway	Anti-pattern
Institutional	Reads like a Tier-1 bank's investor-relations page, not a fintech landing	Playful animations, emoji, casual copy, gradient buttons
Restrained	Small type sizes for body, generous whitespace, no more than 2 accent colours on any screen	Multi-colour gradients, decorative illustrations, hero videos with music
Cinematic	The Black Swan hero sequence is the only "expressive" element on the gateway. Everything else is quiet	Multiple hero animations, parallax on every scroll, animated icons
Confidential	Nothing on the public surface reveals internal architecture, plane internals, ticket IDs, roadmap dates, financial figures, or client names	Diagrams that expose Nexus registry fields, screenshots of internal surfaces, roadmap timelines

As of v0.2, §2 no longer authors visual token values. BEDL v0.1 is the single source of truth for colour, typography, motion, spacing, and elevation tokens. §2 consumes BEDL and adds only gateway-specific enforcement — policies that constrain how the gateway draws from BEDL. Where a value is named below, it names a BEDL token, not a gateway-authored value.

2.1 Colour (consumes BEDL §2)

The gateway consumes the BEDL §2 semantic tokens (--bg-page, --bg-surface, --fg-primary, --fg-secondary, --accent, --accent-hover) over the BEDL raw palette. The gateway MUST NOT introduce colour tokens beyond BEDL §2; any proposal for a colour outside the BEDL palette requires a BEDL amendment, not a BGXS one.

Gateway enforcement (policy, not tokens):

Single accent only. The public surface uses exactly one accent (--accent, hovering to --accent-hover) — for statement-line accent, cinematic Black Swan silhouette highlight, and the single CTA. No second accent on any public surface.
Signal colours (--state-hold, --state-standby, --state-shipped) are functional — they communicate posture and gate state and never decorate the public surface.
Posture strip, footer meta, and timestamps use --fg-secondary.

2.2 Typography (consumes BEDL §3)

The gateway consumes the BEDL §3 type ramp (--type-display-hero, --type-display-1, --type-display-2, --type-body-lead, --type-body, --type-body-small, --type-mono, --type-eyebrow) and the two locked families (Display + Text) defined in BEDL §3. The gateway MUST NOT introduce type tokens or families beyond BEDL §3.

Gateway enforcement (policy, not tokens):

Two families maximum on the gateway (display + body), per BEDL §3.
Mono (--type-mono) is reserved for wordmarks and the posture strip only.
Curly quotes “ ” (U+201C / U+201D) in all copy and middle-dot · (U+00B7) as status separator, per BEDL §3.2.

2.3 Motion (consumes BEDL §6)

The gateway consumes the BEDL §6 duration tokens (--duration-instant, --duration-fast, --duration-medium, --duration-slow, --duration-narrative) and easing tokens (--ease-standard, --ease-emphasis, --ease-linear). The gateway MUST NOT introduce motion tokens beyond BEDL §6.

Gateway enforcement (policy, not tokens):

One expressive element: the Black Swan hero sequence (§4), choreographed with --duration-narrative and --ease-emphasis.
All other motion is functional: scroll fade-in, link hover, and page transitions use the fast/medium/slow duration tokens; nothing on the public surface exceeds --duration-slow.
No parallax anywhere on the public surface.
No autoplay video except the hero sequence.
Respect prefers-reduced-motion per BEDL §6.3 — the Black Swan hero collapses to a still-frame silhouette when the user opts out; no page-transition fades.

3. Question 3 — How do users move from public content into authenticated access?

This section is the auth-topology decision. It answers the two TBD-EOC-03 markers left by CMOS EOC·02 (PR #45).

3.1 Topology decision (locked at BGXS v0.1)

The gateway hosts the SSO shell. Every plane's authentication callback lives under its own subdomain.

Auth handoff chain (v0.2, six logical stages):

Landing → Access → Institution Profile → Entitlements → Nexus → Plane

The chain gains two logical stages at v0.2 — Institution Profile (§3.1.4) and Entitlements (§3.1.5) — inserted between Access and Nexus. Both are served from the existing SSO subdomain (access.bsp1.io); they add no new hosts, no new redirect-allowlist entries, and no new dev ports. The host topology, redirect URIs, Entra app registrations, and dev-port allocations in the tables below are unchanged from v0.1 and remain the CMOS EOC consumer contract.

Public marketing surface:  https://bsp1.io
                                        │
                                        ▼
                          Access CTA (single button)
                                        │
                                        ▼
                    https://access.bsp1.io
                          (Entra ID authorize endpoint)
                                        │
    ┌───────────────────────────┬───────┼─────────────────────┬─────────────────────────────────┐
    ▼                           ▼                             ▼                                   ▼
    https://falcon.bsp1.io      https://swan-nest.bsp1.io     https://digital-swan.bsp1.io       https://ai.bsp1.io
            /auth/callback              /auth/callback                /auth/callback                     /auth/callback
    (CMOS · falcon)             (PMOS · swan-nest)             (HSOS · digital-swan)               (AIOS · ai)

Per-plane subdomains and callback URIs:

Plane · Card	Subdomain	Redirect URI	Entra app registration
CMOS · falcon	`falcon.bsp1.io`	`https://falcon.bsp1.io/auth/callback`	`cmos-falcon-prod`
PMOS · swan-nest	`swan-nest.bsp1.io`	`https://swan-nest.bsp1.io/auth/callback`	`pmos-swan-nest-prod`
HSOS · digital-swan	`digital-swan.bsp1.io`	`https://digital-swan.bsp1.io/auth/callback`	`hsos-hedge-sovereign-prod`
AIOS · ai	`ai.bsp1.io`	`https://ai.bsp1.io/auth/callback`	`aios-ai-prod`
Gateway SSO shell	`access.bsp1.io`	(Entra endpoint host, not a plane callback)	(uses per-plane app registrations)

Rationale for the subdomain-per-plane topology:

Matches Canon §8 diagram — each OS plane is a peer with its own host.
Preserves plane isolation — a compromise in one plane's callback does not expose others.
Simplifies Entra allowlist per app — each app registration has exactly one production redirect URI (plus one dev entry), not a shared multiplex.
Enables per-plane operational independence — teams can rotate certificates, deploy, and revoke per plane without cross-plane blast radius.

3.1.4 Institution Profile stage (post-Access, pre-Nexus)

After successful Entra OIDC authentication (Access), before Nexus renders plane cards, the authenticated principal is enriched with institution context: which institution they represent, which entities they act for, which jurisdictions apply, which agreements are in force. The Institution Profile stage is a lookup, not a decision — it produces a profile object consumed by Entitlements.

Host binding: Institution Profile is served from the SSO subdomain (access.bsp1.io) — no new host, no new redirect allowlist entry.

Non-goals:

Not a role or permission decision (Entitlements owns that)
Not a KYC verification (external systems own that; Institution Profile consumes their attestation)
Not authoritative on identity (Access via Entra owns identity)

3.1.5 Entitlements stage (post-Institution-Profile, pre-Nexus)

Given the authenticated principal and their Institution Profile, Entitlements determines which planes and which routes within a plane the principal may reach. Entitlements is a decision, not a lookup. It produces an entitlements object consumed by Nexus to render only permitted plane cards and to gate plane routes.

Host binding: Entitlements is served from the SSO subdomain (access.bsp1.io) — no new host, no new redirect allowlist entry.

Non-goals:

Not a live role-management surface (that lives per plane or in a future admin surface)
Not the Nexus render itself (Nexus consumes Entitlements output)
Not RBAC storage authority (Entra + downstream systems own storage; Entitlements evaluates)

3.2 Local development callback convention

Add a matching localhost entry per plane, using a canonical port allocation:

Plane · Card	Dev port	Dev redirect URI
CMOS · falcon	`5401`	`http://localhost:5401/auth/callback`
PMOS · swan-nest	`5402`	`http://localhost:5402/auth/callback`
HSOS · digital-swan	`5403`	`http://localhost:5403/auth/callback`
AIOS · ai	`5404`	`http://localhost:5404/auth/callback`
Gateway SSO shell	`5400`	`http://localhost:5400/auth/callback`

Ports allocated in the 54xx range because it does not collide with common local ports (3000-4000 dev servers, 5000 Flask, 5432 Postgres, 6379 Redis, 8080 alt-http).

3.3 Access CTA behaviour

The public gateway has one and only one Access CTA — top-right of the nav bar and one repeat at the bottom of the landing.
Clicking Access sends the user to access.bsp1.io, which is a plane picker screen (a 4-card render matching the Canon §7 Nexus render: falcon · swan-nest · digital-swan · ai).
On the picker, the user selects a plane. Only then does the Entra flow initiate against that plane's app registration.
HSOS and LCGX do not appear on the picker (per Canon §7 — Nexus is a customer-facing launcher; HSOS is governed-nav; LCGX is not on the render).
The picker itself does not require authentication to view (it lists plane names only, no plane content).

3.4 Post-auth landing

After successful auth, the user lands on the chosen plane's own surface. The gateway hands off cleanly and does not proxy authenticated content. There is no gateway-side session — the gateway is stateless for authenticated users.

3.5 EOC·03 unblocking

The cmos-falcon-prod and aios-ai-prod TBD-EOC-03 markers left by CMOS EOC·02 (PR #45) resolve to the entries in the table above:

cmos-falcon-prod → https://falcon.bsp1.io/auth/callback
aios-ai-prod → https://ai.bsp1.io/auth/callback

Plus the matching localhost dev entries from §3.2.

CMOS EOC·03 may consume this decision directly. No further BGXS clearance required for that ticket.

3.6 Amendment record · ADR-013 (Arrival cinematic post-sign-in gate)

Ratified 11:35 BST · Saturday 25 July 2026 · sponsor: Mamadou Ly, Founder, Managing Partner & CEO.

ADR-013 activates the BGXS §4.3 v0.1 bespoke-swan video slot and inserts a /welcome step into the access journey. The ratified §3.1–§3.5 body above is not rewritten; this amendment adds the following behaviours:

Journey shape. Landing → Access → [Welcome] → Nexus → Plane. [Welcome] is a session-authenticated interstitial that plays the Arrival cinematic once per browser tab and then hands off to the Nexus launcher. It is not a stage in the pre-auth sequence — unauthenticated visitors are redirected from /welcome back to /access.
Sign-in redirect. The Access CTA's Entra sign-in now targets /welcome (not /nexus). The historical "post-auth landing" (§3.4) still applies once the interstitial hands off; there is no gateway-side session, and no plane content is proxied through /welcome.
Session-once semantics. /welcome uses a distinct session-storage namespace (blackswan-welcome-played and its URL-scoped video variant) so an authenticated user who watched the landing cinematic still sees the /welcome cinematic the first time in a fresh tab.
Fallback safety. Where the Release 1.1 video env var is unset, /welcome still gates on session and still plays a fallback still-frame reveal before handing off to /nexus. The gate is independent of the Release 1.1 video asset.
Accessibility. A keyboard-focusable Skip control lives on /welcome at t=0. prefers-reduced-motion collapses the cinematic to a courtesy delay before the handoff.

All other §3 clauses remain in force. No plane-side changes.

4. Question 4 — How is the cinematic Black Swan sequence integrated?

The Black Swan hero is the only expressive element on the entire gateway. It must earn that privilege.

4.1 What it is

A silent, ~6-second, autoplay-once cinematic sequence rendered as the full-viewport hero on the landing page:

Frame 0 (0.0s): Near-black surface. Nothing.
Frame 1 (0.5-2.5s): A single Black Swan silhouette resolves from the darkness at centre-left, in profile, matte-black on the base tone with a single gold accent along the neck curve.
Frame 2 (2.5-4.5s): The swan holds. Statement line fades in at bottom-third. Posture strip fades in at bottom edge.
Frame 3 (4.5-6.0s): The swan holds. Nav bar fades in at top edge. Access CTA becomes tappable.
Persistent (6.0s+): The still-frame remains. No loop. No further motion.

4.2 Constraints

Silent. No audio track, no ambient sound. Not even on interaction.
Autoplay once. Never restarts on scroll or nav. Session-persistent flag to skip on repeat visits (fade directly to still-frame).
prefers-reduced-motion fallback: static still-frame of Frame 3, no sequence.
Weight budget: ≤ 1.2 MB total (video + poster). If the highest-fidelity version exceeds budget, ship a compressed WebM primary + AVIF still-frame fallback.
No text baked into the video. The statement line, nav, and posture strip are DOM elements over the video, never inside it. Enables translation and iteration without re-rendering.

4.3 Format

Delivery: self-hosted from Azure Blob Storage via CDN. Not YouTube, Vimeo, or a third-party video host.
Encoding: two variants — WebM (VP9) primary, MP4 (H.264) fallback. Poster is AVIF with JPEG fallback.
Aspect ratio: 16:9 master, with a 9:16 mobile portrait variant. No stretched or letterboxed rendering on any viewport.

v0.1 hero rendition (sponsor-locked 2026-07-12): v0.1 launches with a pure typographic wordmark hero — a centred BLACKSWAN wordmark in a Didone-style serif over near-black, with the locked statement line as a centred tagline in dim grey. The v0.1 asset is docs/assets/blackswan_wordmark_hero_v0_1.png (16:9). The commissioned Black Swan photograph or 3D swan-silhouette render is deferred to Phase 2 Visual Design so the typography and colour system lock before art direction — the wordmark rendition satisfies the §4.1–§4.3 constraints without committing to an art-directed asset ahead of the typeface selection.

4.4 Where else the sequence appears

Only on the landing page. It does not repeat on /estate, /access, /contact, or any other route. Repeated exposure dilutes the effect.

5. Question 5 — How do institutional users discover the ecosystem?

Discovery is deliberately anti-viral. Institutional visitors find BLACKSWAN through direct introduction, regulatory filings, industry press, and word of mouth — not through SEO campaigns or paid acquisition. BGXS reflects this posture.

5.1 Public discovery affordances (minimal set)

The gateway supports discovery only via:

A single Estate page at /estate — a static, read-only view listing the five OS planes (CMOS · PMOS · HSOS · AIOS · TREICHTEC) and LCGX (marked separately as the constitutional plane, external, STANDBY · IN-MEMORY ONLY · HOLD · NO-GO). One paragraph per plane, no product screenshots, no metrics, no client references.
A single Contact page at /contact — an email address and a physical-contact line. The physical-address line reads “Contact via founder email until Wave 1 operational cutover.” No web form. No chat. No calendar embed.
Structured metadata (<title>, <meta description>, OpenGraph tags) so that shared links resolve dignifiedly. No blog RSS, no sitemap beyond three URLs.

5.1.1 `/estate` paragraph copy (v1.0 locked)

One paragraph per plane, in estate order, no metrics, no screenshots, no client references. The posture line is deliberately repeated across all seven paragraphs to reinforce the estate-wide invariant; it is not collapsed into a single header line.

CMOS · Falcon capital-markets execution plane

“Execution infrastructure for capital-markets operators — order flow, settlement, and post-trade reconciliation across the mandates of an institutional trading book. Currently in STANDBY · in-memory only · HOLD · NO-GO.”

PMOS · Swan Nest private-markets plane

“Private-markets operating system for fund launch, LP onboarding, capital calls, distributions, and portfolio-company reporting. Built for the operators of closed-end capital. Currently in STANDBY · in-memory only · HOLD · NO-GO.”

HSOS · Digital Swan hedge & sovereign wealth plane

“Hedge-fund and sovereign-wealth operations across mandate onboarding, NAV cycle, allocator stacks, and redemption gates. Mandate α is the first configured mandate profile. Currently in STANDBY · in-memory only · HOLD · NO-GO.”

Mandate placeholders. Public mandate references in gateway copy use Greek-letter placeholders (Mandate α, Mandate β, Mandate γ, …) assigned in first-mention order. Internal mandate profile identifiers (product codes, ticket IDs, LP shorthand, internal alphanumeric mandate names) never appear in gateway public copy, source fixtures consumed by public routes, or spec text. This rule applies to §5.1.1 paragraph copy and to any future public-facing surface that names a mandate.

AIOS · 24-app registry and Nexus card

“Twenty-four AI-anchored operator applications — the surface layer that operators use daily, launched from a single Nexus card. Currently in STANDBY · in-memory only · HOLD · NO-GO.”

Nexus · Hub-and-spoke launcher

“Single entry point across the estate. One identity, one access-control plane, one launcher — the operator’s home surface. Currently in STANDBY · in-memory only · HOLD · NO-GO.”

TREICHTEC DLT · Digital Swan distributed-ledger execution plane

“Distributed-ledger execution for cross-plane settlement, evidence retention, and inter-mandate messaging. Currently in STANDBY · in-memory only · HOLD · NO-GO.”

LCGX · Constitutional mega-system plane

“The constitutional layer beneath the estate — canonical registries, fixture invariants, and the LRM/GA governance model that keeps every operating plane bound to the same operator vocabulary. Currently in STANDBY · in-memory only · HOLD · NO-GO.”

5.2 What the gateway explicitly does NOT do

No public product screenshots
No public roadmap page
No public metrics or "customers we serve" logos
No public pricing
No public case studies
No public API documentation
No public press-release archive on v0.1 (deferred to v0.2+ if the sponsor decides)
No public job board (careers live off-gateway if at all)

5.3 What the AIOS `ai` card does NOT do here

The Canon §7 Nexus render includes an ai card as one of the four launcher tiles. On the public gateway, the ai card resolves to a plane-picker entry, not to any AI chat surface, agent surface, or public AIOS row. AIOS internals stay behind auth.

6. Information architecture and navigation

6.1 Public route table (v0.1)

Total: six routes. Anything not in this table is out of scope for BGXS v0.1.

Route	Purpose	Auth
`/`	Landing (cinematic hero + statement line)	Public
`/estate`	Static plane roster (one paragraph per plane)	Public
`/access`	Plane picker → Entra flow	Public (picker); Entra beyond
`/contact`	Email + physical address	Public
`/legal`	Terms, privacy, cookie policy	Public
`/404`	Standard	Public

No blog, no docs, no press, no careers, no product pages on v0.1.

6.2 Nav model

Top nav: Estate · Access · Contact (three items only).
No mega-menu, no dropdowns, no hamburger except on mobile.
Mobile nav collapses to a single icon → full-screen overlay with the same three items + Access CTA.

6.3 Component library scope

Navigation bar (desktop + mobile)
Cinematic hero container
Statement line component
Posture strip component
Plane-picker card (single reusable component; the four cards are data)
Static section (used for /estate and /legal)
Footer
404 template

That is the full component set for v0.1. Nothing else ships in Phase 2's component library without a BGXS amendment.

7. Accessibility, performance, and privacy baseline

7.1 Accessibility

WCAG 2.2 AA across the public surface.
All colour contrast pairs on the palette (§2.1) verified against AA before the palette is locked.
Keyboard-only navigation reaches every interactive element within 5 tabs from the top of any page.
Screen-reader-visible order matches visual order.
prefers-reduced-motion respected (see §4.2).

7.2 Performance

LCP ≤ 2.5s on 4G moderate.
Total public-page weight (excluding hero video) ≤ 350 KB.
Hero video weight ≤ 1.2 MB (see §4.2).
No client-side JavaScript required to render /estate, /contact, /legal, /404. Landing may use minimal JS for the hero sequence.
No third-party fonts on the public surface — self-host from Azure Blob.

7.3 Privacy

No analytics on v0.1. No Google Analytics, no Segment, no Plausible, no self-hosted analytics.
Cookie usage: regulatory-minimum only. If none is used, no cookie banner is shown.
No third-party scripts on the public surface.
Server logs retain IP + user-agent for 30 days for security only; no correlation for behavioural analytics.

8. Locked invariants (BGXS v0.1)

These are locked at v0.1 and cannot change without a BGXS version bump:

Six public routes only (§6.1).
Single accent colour palette — near-black + off-white + one gold + muted (§2.1).
Two type-family maximum (display + body); mono optional for posture strip (§2.2).
Single Black Swan hero, ~6s, silent, autoplay-once, landing-only (§4).
Gateway hosts SSO shell; per-plane subdomains for callbacks (§3.1).
Posture strip on every non-authenticated page: STANDBY · IN-MEMORY ONLY · HOLD · NO-GO (§1.2).
Sponsor line verbatim on the landing (§1.3).
Plane-picker is 4-card render matching Canon §7 (falcon · swan-nest · digital-swan · ai); HSOS and LCGX absent from picker (§3.3).
No analytics, no third-party scripts, no cookie banner beyond regulatory minimum (§7.3).
Component library scoped to the eight components in §6.3.

9. What BGXS does NOT do (in relation to the Canon)

Explicit non-overrides — BGXS may not:

Alter the plane roster (Canon §1).
Alter the AIOS row-vs-plane hierarchy (Canon §2).
Alter the vocabulary or add new forbidden phrases outside gateway UX scope (Canon §3).
Alter the tech stack (Canon §4).
Alter repository conventions (Canon §5).
Alter delivery cadence or estate posture (Canon §6).
Alter the Nexus render rule (Canon §7).
Alter the estate diagram (Canon §8).
Retire or reword any of the 16 prohibitions (Canon §9).

If a gateway design requires any of the above, open a Canon-amendment PR per Canon §0 first.

10. Versioning

BGXS follows the same v1.x additive vs vN.x breaking rule as the Canon (see Canon §0).

v0.x — draft phase; sponsor iterates freely before locking v1.0.
v1.0 — first frozen version, once sponsor approves.
v1.x — additive changes: new components, new routes, new copy variants, tightened invariants.
vN.x → v(N+1).0 — breaking changes: new accent colour, new route structure, new auth topology, cinematic hero replaced, discovery posture broadened.

Changelog

v0.1 — 2026-07-11 — initial draft: three-ring audience model, landing surface spec, feel adjectives, colour + type + motion, auth topology decision (subdomain-per-plane, gateway SSO shell) resolving EOC·03 TBD markers, cinematic Black Swan constraints, discovery affordances, IA + nav, six public routes, accessibility/performance/privacy baseline, 10 locked invariants, 9 non-overrides in relation to the Canon.
v0.2 — 2026-07-11 (DRAFT) — additive: §3.1 auth handoff extended with two logical stages (Institution Profile, Entitlements) inside the SSO subdomain; §2 reframed as BEDL v0.1 consumer; §12 Domain awareness added. No plane hosts, redirect allowlist entries, dev ports, or role assignments changed.
v1.0 — 2026-07-12 — sponsor decisions locked for §11 items 1, 3, 4, 6: statement line (“Institutional discipline for markets that cannot afford drift.”), /estate paragraph copy per plane, physical-address placeholder resolution, v0.1 pure-typographic wordmark hero with Phase 2 commissioned-asset deferral. Items 2 (typefaces) and 5 (legal copy) remain deferred by design.
v1.1 — 2026-07-14 — §5.1.1: confidential mandate profile identifier scrubbed from HSOS estate paragraph and replaced with the canonical Greek-letter placeholder Mandate α, matching the runtime fixture scrub SHIPPED in PR #20; new Mandate placeholder discipline rule added to §5.1.1 requiring Greek-letter placeholders for public mandate references and prohibiting internal identifiers in public copy, fixtures consumed by public routes, and spec text. No structural changes; no other sections modified.
v1.2 — 2026-07-14 — §3.1/§3.1.4/§3.1.5/§3.2/§3.3/§3.5: estate-wide identity domain substituted from unavailable blackswanpartnership.com to bsp1.io (sponsor-owned domain available at the registrar for immediate use while the .com acquisition path remains open for a future migration). All subdomain patterns preserved (access, falcon, swan-nest, digital-swan, ai) · all Entra app-registration identifiers preserved · all dev-port allocations preserved · no topology, redirect-URI shape, or handoff-chain change. Additive substitution only per Canon §0 version-bump rule.

11. Sponsor decisions before locking v1.0

Locked (v1.0)

Statement line wording (§1.2) — “Institutional discipline for markets that cannot afford drift.” Sponsor-locked 2026-07-12.
/estate paragraph copy per plane — Seven paragraphs locked in §5.1.1. Sponsor-locked 2026-07-12.
Physical contact address (§5.1) — “Contact via founder email until Wave 1 operational cutover.” Sponsor-locked 2026-07-12. Physical address decision deferred until domicile is confirmed via counsel-review loop.
Cinematic hero rendition — v0.1 ships with pure typographic wordmark hero (docs/assets/blackswan_wordmark_hero_v0_1.png). Commissioned Black Swan photograph or 3D render deferred to Phase 2 Visual Design alongside typeface selection. Sponsor-locked 2026-07-12.

Deferred by design

Final display and body typefaces (§2.2) — Family shape locked (serif display + geometric sans body, two families max). Exact type selection deferred to Phase 2 Visual Design.
Legal copy (/legal) — Deferred to counsel. Counsel-review loop initiated 2026-07-12 (see estate-wide counsel brief). BGXS locks only the route existence at v1.0.

12. Estate Domain awareness

Canon v2.2 §11 defines seven Estate Domains as an orthogonal capability view over the plane roster (content preserved verbatim from v1.1 per ADR-014). BGXS operates primarily at the Identity and Governance Domains and touches the Institution Domain via §3.1.4:

Identity Domain: BGXS §3.1 defines the auth handoff (Landing → Access → Institution Profile → Entitlements → Nexus → Plane). The Access stage IS Identity's enforcement artefact in the gateway.
Institution Domain: BGXS §3.1.4 introduces the Institution Profile stage. BGXS does not author institutional data models; it consumes them from Institution Domain implementations (PMOS, HSOS).
Governance Domain: BGXS §2's prototype banner, single-accent discipline, and constrained-landing rules ARE Governance enforcement at the gateway boundary.

BGXS does NOT operate at Capital, Settlement, Risk, or Intelligence Domains. Those are plane-plane concerns and any BGXS surface that appears to touch them is either a mistake or a legitimate gateway-to-plane handoff whose gateway-side must remain minimal.

BLACKSWAN Gateway Experience Standard · v1.2 · authored 2026-07-11 (v0.1) · amended 2026-07-11 (v0.2) · locked 2026-07-12 (v1.0) · amended 2026-07-14 (v1.1) · amended 2026-07-14 (v1.2) · sponsor Mamadou Ly, Founder, Managing Partner & CEO. Subordinate to the BLACKSWAN Estate Canon v2.2 — FROZEN (2026-08-30).

BLACKSWAN Gateway Experience Standard (BGXS)

0. What BGXS answers (and what it does not)

Position in the governance stack

1. Question 1 — What should visitors see?

1.1 Audience model (three concentric rings)

1.2 Landing surface (above the fold, first paint)

1.3 Below the fold (single scroll depth, three sections max)

2. Question 2 — How should the gateway feel?

2.1 Colour (consumes BEDL §2)

2.2 Typography (consumes BEDL §3)

2.3 Motion (consumes BEDL §6)

3. Question 3 — How do users move from public content into authenticated access?

3.1 Topology decision (locked at BGXS v0.1)

3.1.4 Institution Profile stage (post-Access, pre-Nexus)

3.1.5 Entitlements stage (post-Institution-Profile, pre-Nexus)

3.2 Local development callback convention

3.3 Access CTA behaviour

3.4 Post-auth landing

3.5 EOC·03 unblocking

3.6 Amendment record · ADR-013 (Arrival cinematic post-sign-in gate)

4. Question 4 — How is the cinematic Black Swan sequence integrated?

4.1 What it is

4.2 Constraints

4.3 Format

4.4 Where else the sequence appears

5. Question 5 — How do institutional users discover the ecosystem?

5.1 Public discovery affordances (minimal set)

5.1.1 /estate paragraph copy (v1.0 locked)

5.2 What the gateway explicitly does NOT do

5.3 What the AIOS ai card does NOT do here

6. Information architecture and navigation

6.1 Public route table (v0.1)

6.2 Nav model

6.3 Component library scope

7. Accessibility, performance, and privacy baseline

7.1 Accessibility

7.2 Performance

7.3 Privacy

8. Locked invariants (BGXS v0.1)

9. What BGXS does NOT do (in relation to the Canon)

10. Versioning

Changelog

11. Sponsor decisions before locking v1.0

Locked (v1.0)

Deferred by design

12. Estate Domain awareness

5.1.1 `/estate` paragraph copy (v1.0 locked)

5.3 What the AIOS `ai` card does NOT do here