Furth FortuneM9 reference

Assurance fabric / System overview

Controlled Deployment

Separate paths for application and platform updates

Trident and configuration updates use a live application path. Compiled runtime and device changes use a staged node rollout. Both paths retain state and rollback information.

Inside the system

Architecture plates

Each plate preserves the internal layout, paths, boundaries, and highlighted decisions. Use the short label first, then follow the lines through the system.

Plate 01

Two paths, and only one of them replaces a node

trigger · mechanism · where it lands · what it costs

PATH A · APP .tri · LIVE-EDITED IN THE STORE an operator edits .triMerTek.io console, MCP, or UI t.edit.proposecommit, then validate merdb module historyhead, active, rollback the host swaps generationno rebuild, no node replaced This path is the daily driver. It covers every app, including the platform's own MerTekStak and MerTek.io. The repository is the bootstrap seed. Once a system runs, the live .tri in the store is the source of truth. PATH B · COMPILED-CORE C · NEW GOLDEN AMI an engineer edits core Ctrident_rt.c, merdb_engine.c rebuild fathom -static/opt/mertek/fathom/fathom a new golden AMIcloud_account.bootstrapAmi blue/green replacementmertek.startRollout, 11 phases A compiled-core change is the only change that needs a rebuild. MerTekStak orchestrates an app cluster's roll as a durable state machine; the control plane's own node rolls through the operator release scripts. WHAT BOTH PATHS SHARE durable state sharded MerDB on EBS, reached through the peer matrix, never in the binary the connection matrix no cap: the target holds the declared serving node set; cm_drain moves first the wire contract MerBuf fingerprints plus the call/event capability set. Plate 04 draws it.
Plate 02

The live-edit path: a commit is not a generation

the durable store · one propose · the four outcomes

THE DURABLE STORE merdb _sys_modules one row per Trident module head the newest commit active the commit now served rollback the revert pointer audience who may fetch it a commit row is append-only _sys_module_launches four phases, one row per attempt 0 validate 1 activate 2 launch 3 rollback it carries the TridentFault code, so a fault reads from data alone REACHED FROM TRIDENT db.entity.moduleCommit db.entity.moduleActivate both gated by CAP_MODULE_WRITE ONE PROPOSE, END TO END t.edit.proposethe admin handler's endpoint stale-parent checkexpectedParent must equal head the commit appends firsta bad commit is stored, never lost th_live_edit_validateparse plus load on an isolated host build a fresh generationlaunch it before any live swap the scheduler quiet pointswap when live_inflight reaches 0 WHY THE SWAP WAITS Work already in flight finishes on the old generation. Only new work sees the new commit. THE FOUR OUTCOMES TH_LIVE_ACTIVATED launched, then swapped now TH_LIVE_PENDING swap deferred to the quiet point TH_LIVE_FAULT_ROLLBACK the launch faulted, so the prior generation and pointer both stay TH_LIVE_REFUSED unbound module, stale parent, a failed validation, or a pending swap ROLLBACK IS A FORWARD MOVE t.edit.rollback makes a prior commit live again by building a fresh generation from it. It never rewrites the history it reads.
Plate 03

The compiled-core rollout: a durable state machine, one transition at a time

eleven phases · the rollback branch · what moves during the drain

THE ROLLOUT STATE MACHINE · ONE TRANSITION PER mertek.rolloutStep 1 · pending capture the BLUE incumbents; enqueue the GREEN provision 2 · green_provisioning enact the provision, then poll until GREEN counts active 3 · green_health mertekNodeHealthProbe: fresh heartbeat plus applied version 4 · dns_include GREEN joins the ownership map and the healthy A-set 5 · blue_draining set each BLUE to draining; poll until every one is drained 6 · dns_exclude republish the A-set with GREEN only; BLUE drops out 7 · blue_retiring targeted teardown of the BLUE instances only 8 · done GREEN serves alone; the job row is terminal rollback tear GREEN down, restore BLUE to active, republish BLUE rolled_back terminal; the step returns done = 1 and does no work failed terminal; pending could not enqueue the GREEN provision WHAT MOVES DURING blue_draining 1 · the drain waits on the node The step sets each BLUE to draining, then polls its drainState. It advances only when every BLUE reports drained, not on a timer. 2 · the scene authority moves sf_failover promotes the best live replica and fences the old master. With no live replica it returns SF_RECONSTRUCT, and the new master rebuilds from the checkpoint cursor. 3 · clients move first cm_drain migrates a target to a backup BEFORE the node stops, and never re-selects the drained one. A stale route that still lands on a non-owner gets call.redirect. NEVER BLACKHOLE TRAFFIC GREEN enters DNS only after the health gate passes. BLUE leaves DNS only after GREEN serves. A publish with an empty healthy set refuses.
Plate 04

The enforceable discipline: BLUE and GREEN serve at the same time

the mixed-version window · fingerprint · capability · the refusal

MID-ROLL · BOTH FLEETS SERVE THE SAME CLIENTS BLUE · the old-AMI fleet the incumbent compiled core: trident_rt.c, merdb_engine.c, the renderer and the Fathom hosts as they were built drainState active until phase 5 orders the drain one wire GREEN · the new-AMI fleet the same systems rebuilt from a newer tree, baked into a new golden AMI and booted from cloud_account.bootstrapAmi in the healthy A-set from phase 4 onward WHAT KEEPS A BUMP SAFE 1 · MerBuf fingerprints the schema mb_schema_hash folds every column name, type and parameter, in declared order, into one identity. A bump yields a different fingerprint, so a v1 frame can never decode as v2 by accident. The per-runtime registry keeps resolving the OLD fingerprint after the bump, so a GREEN node still reads a frame that a BLUE node wrote. 2 · call/event negotiates the capability A client advertises {hashOnly:1} in its sys.connect hello. That sets hashonly_ok on the connection. The host strips the schema section only on the SECOND and later frames of a fingerprint that this connection has already received. A peer that never advertises always gets the self-describing form, so an old client keeps working. THE ONE THING TO AVOID, AND THE GATE THAT WATCHES IT a breaking wire change Mid-roll it puts a GREEN node and a BLUE node on contracts that cannot read each other. The roll then needs a version-gated drain: take the whole old fleet out before the new fleet serves. That is the expensive path, and this discipline exists to avoid it. fathom.tests.wire-compat 19 checks over the real surfaces: a frozen-fixture fingerprint that stays stable, a bump that collides with nothing, an OLD fingerprint that still resolves after the bump, and a client that never advertises hashOnly proved to keep self-describing frames.
Plate 05

Genesis, and the floor underneath both paths

the one manual step · the two-phase boot · the recovery floor

GENESIS · THE ONLY HAND-PROVISIONED STEP 1 · one manual EC2 launch A human boots one node from the golden AMI, tags it genesis and never-stop, and sets FATHOM_GENESIS_BOOTSTRAP=1. Nothing else is provisioned by hand. 2 · the two-phase boot The host arms CAP_MODULE_WRITE and CAP_FILE_IO, then runs importBootstrap over native/seed/manifest.tri BEFORE it opens the socket. 3 · six production seeds plus one admin MerTekStak and MerTek.io each import an app, a schema and a handler. The host mints the first admin as a hash-only bootstrap_principal. No credential lives in the tree. 4 · separate and expose Through the live control plane, MerTekStak provisions a public node for mertek.io, isolated from the private mertekstak.com, then binds both domains. 5 · the platform maintains itself From here every change to either product is a live edit in the store. The repository is the bootstrap seed; the live .tri is the source of truth. THE FLOOR UNDER EVERY FAILURE a second boot is idempotent A re-boot in genesis mode imports 0 and skips 6. The bootstrap seam answers deny_already_bootstrapped, and exactly one admin still exists afterward. The gate tests.genesis-bootstrap drives both passes. the seed is the recovery path The repository seed plus the manifest re-bootstraps a region from nothing. It is the disaster-recovery floor and the new-region floor. A bad platform edit rolls back through generations, so recovery does not depend on the version in use. STATE OUTLIVES THE BINARY genesis-bluegreen-migrate.sh copies BLUE state and config onto GREEN and KEEPS GREEN's binary. It reads a read-only snapshot, so BLUE is never touched, and the operator flips DNS only after GREEN serves.

Key parts

What the system does

These are the main boundaries, inputs, outputs, and failure rules. The examples show a specific use of each part.

Application change path

Mission logic and configuration can move through a governed live-update path. A published generation remains distinct from an unapproved edit.

Specific example

A logistics approval rule can change without replacing the complete software node.

Platform rollout path

Changes to the compiled foundation move through a durable staged rollout. The system records each transition.

Specific example

A new device driver can reach a pilot group before the larger fleet receives it.

Side-by-side service

Current and incoming releases can serve during transition. Compatibility is treated as an operating requirement.

Specific example

An operational unit can keep service while nodes update in planned waves.

Uses

Example uses

Pilot questions

What the team must decide

Which changes qualify for each path

What rollback time the mission requires

How old and new releases must work together

Request a technical briefing

Connected references

Mission foundation Fathom Open reference Platform product MerTekStak Open reference Assurance fabric Evidence and Verification Open reference
Return to the M9 reference library