Furth FortuneM9 reference

Platform product / System overview

MerTekStak

The control plane for applications and releases

MerTekStak stores application definitions, release state, test evidence, and rollout decisions. It runs as a MerTek application and follows the same rules as the software it manages.

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 products, and everything else is authored at runtime

the two product roots · the gate that refuses a third · the Applications that are not here

native/apps · EXACTLY TWO DEPLOYABLE PRODUCT ROOTS native/apps/mertekstak MerTekStak.com · private control plane users: Furth Fortune administrators it manages the infrastructure native/apps/mertek-io MerTek.io · identity and authoring users: everyone, builders included it authors and manages the apps NOT PRODUCTS, ALSO UNDER native/apps lib · the shared package library servicedebug · conformance fixture tracestudio · conformance fixture 3 directories, each named explicitly THE GATE THAT REFUSES A THIRD apps.product-root-shape native/apps/run-product-root-shape.sh the root set must equal exactly mertekstak and mertek-io each root carries 5 declared leaves config server client shared tests no bare product .tri at a root no compiled source outside tests/ every declared appC is 0 6 retired roots stay refused It plants a known-bad fixture in a scratch copy on every run. AUTHORED AT RUNTIME, NOT HERE BitsOfUs · IntoTheStrand ReefStudio · every user app config plus Trident modules in the live data and module store MerTek.io authors and manages them MerTekStak provisions their infra no source tree in this repository WHAT THIS REPOSITORY MAY HOLD generic platform capabilities, and conformance fixtures that prove them never the production implementation of a runtime-authored Application servicedebug and tracestudio are two WHO DOES WHAT FOR ONE RUNTIME-AUTHORED APPLICATION MerTek.io authors and manages the modules holds the one identity per user mints the scoped provision grant the Application config plus .tri in the store its own users, scenes and schema a MerTekStak tenant, always MerTekStak provisions the infrastructure binds the domain, places the nodes owns the deploy, shard and scale policy
Plate 02

The control plane is config plus .tri, and nothing else

the tree census · the two gates that refuse app C · the reachability claim

native/apps/mertekstak · WHAT IS ON DISK 171 .tri modules config · server · client · shared boot, schema, handlers, lib, ui, tests 0 compiled files outside tests/ no .c .h .cpp .cc .hpp .cxx 6 compiled files, all under tests/ test drivers and harnesses only EVERY MANIFEST DECLARES appC 0 9 declarations in this tree furth.mertekstak.server 1.5.0 furth.mertekstak.console 1.1.0 a non-zero value fails both gates TWO GATES, BOTH FAIL-CLOSED apps.app-shape native/apps/run-app-shape.sh scans EVERY app root at once refuses compiled source outside tests/, and any appC not 0 lane automatic, in the full profile apps.product-root-shape native/apps/run-product-root-shape.sh the same scan, narrower and stricter, over the two roots only plus its own planted refusals run-no-app-c.sh the app's own scan of its own tree run-deployer.sh runs it first run-audit.sh runs it again THE PRODUCT'S OWN GATE LEAVES 9 leaves · id apps.mertekstak* deployer · audit · provision-grant handler-entry-shape · client-generation live-edit-activation · sanitizer-lane toolchain-matrix · mertekstak-console every one: exerciseLayer trident WHY THAT FOLLOWS exerciseLayer records the layer at which a leaf drives the capability. trident means the leaf names tracked .tri paths and drives them. No leaf of this product declares c-only-hold, because there is no app C for a hold to attribute. The rule proves itself here. WHEN THE PLATFORM LACKS SOMETHING MerTekStak NEEDS NOT app-specific C in this tree that is the defect the three scans refuse a GENERIC platform primitive a reusable C verb, or a Trident lib on the shared shelf
Plate 03

What it owns, and the one guard every write passes

the declared surface · two streams, not one log · the guard cascade

DECLARED SURFACE · 18 SCHEMA MODULES, 136 ENTITIES Applications and domains application · app_domain · app_admin module_set · project_model mertek.provision · mertek.bindDomain Placement and nodes fathom_node · placement_policy shard_map · rebalance_lease deployment_profile · apply_job Live edit and rollout app_generation · rollout_job published_release · release_pin schema_plan · plate 04 draws it Cloud and secrets cloud_account · platform_secret mertekio_key · deployment knobs provisionCluster · drainCloud Metering and earnings usage_by_app · usage_by_user usage_by_peer · rate_card embed_rate · embed_agreement Telemetry and evidence telemetry_snapshot · gate_result gate_attempt_event · evidence_run evidence_claim · plate 05 draws it TWO STREAMS, NOT ONE LOG WITH A STATUS COLUMN audit_event records an accepted mutation, with its prior and its new version. denial_event records a refusal. MerDB is not SQL, so a refusal is a distinct entity. 80 control-API endpoints 42 declared control scopes 9 declared console scopes EVERY CONTROL-PLANE WRITE PASSES ONE GUARD · mertekAdminGuardAt one call/event request callKey plus a typed MerBuf payload principal and secret ride in it the host stamps the clock at entry mertekAdminGuardAt revoked, then expiry, then secret sha256 compare through constEq, and only the hash persists; scope last SEVEN NAMED REFUSALS deny_no_config deny_bad_args deny_revoked deny_expired deny_bad_secret deny_no_scope deny_no_principal each refusal appends one denial_event row ok, then the op runs mertekAudit appends one audit_event row
Plate 04

Live edit: validate, claim, publish, and a rollback that replays bytes

guard, build, validate, claim, publish · the compare-and-swap · rollback and readopt

ACTIVATE ONE GENERATION · mertekActivateGeneration 1 · guard mertekAdminGuardAt scope live.edit 2 · build the product's own artifact producer, resolved and verified 3 · validate t.edit.validateGeneration build, verify, COMPILE only 4 · claim one app_generation row genClaimKey is unique ANY STEP REFUSES BEFORE THE NEXT ONE RUNS deny_no_scope · deny_no_app · deny_validate · deny_publish · deny for a producer refusal No ledger row on a validate refusal. No publish on a lost claim. Each refusal writes one denial_event. 5 · publish t.edit.activateGeneration then one audit_event row THE CLAIM IS A COMPARE-AND-SWAP, AND THAT IS THE WHOLE CONCURRENCY STORY genClaimKey = appKey#(expected+1) the column carries a declared unique two operators on the same base both compute the same claim key the second save faults Conflict the loser reads verdict deny, code superseded The denial stream records deny_superseded. It is not a retry loop and not a lock: the row either exists or it does not, so a lost update cannot quietly overwrite a landed generation. The ledger row is immutable once written, and a rollback appends. ROLLBACK REPLAYS BYTES, NEVER SOURCE mertekRollbackGeneration reads the generation it supersedes copies envelopeWire verbatim a NEW immutable row rolledBackToGeneration names it then publish that same wire mertekReadoptGeneration republishes the active row at boot and after a restart
Plate 05

The CI plane: green is data, and its provenance is a hash chain

trigger and drain · attempt and flake · verdict · the hash-chained fold

A · A PUSH BECOMES A DRAINED TRIGGER ciWebhookRoute the http.request bridge no new host verb ciRunnerAuthorize deny_undeclared_gateset deny_no_runner_policy ci_trigger, permanent ci_trigger_pending, the queue drained by PREFIX, then deleted the shell wrapper execs run-ci-runner.sh the Application never execs B · EACH ATTEMPT IS RECORDED, AND FLAKINESS IS DERIVED telemetry.gate.gateRecord one call per ATTEMPT appends gate_attempt_event upserts the gate_result row gateIsFlaky reads every attempt event of one gateRunId and gate pair more than one distinct status means flaky = 1 fail, then a standalone pass: flaky, latest pass a cleared concurrency artifact does not block green fail, then fail: the latest status stays fail a declared mustPass gate refuses green, and is named C · THE VERDICT IS A CROSS-CHECK, NOT A COUNT OF GREEN LINES gate_manifest one row per DECLARED gate owner · mustPass · mustBeReachable a gate_result outside the manifest is reported undeclared, not blocking ci.gate.ciRunVerdict for each declared gate: no gate_result row means notRun mustPass and status not pass: failed mustBeReachable and reachable 0: unreachable from run-all.sh green notRun, failed and unreachable all empty not green every offender is NAMED in the verdict D · THE VERDICT FOLDS INTO A HASH CHAIN evidenceBeginRun chainHead starts at the genesis one producer, class gate ttl30d, signedByProducer evidenceAttachGate, per gate evidenceHash covers runId, seq, producer, class, subject, policyHash, payload AND previousHash evidenceVerifyChain walks seq 1 to n, recomputes every hash and compares each previousHash to the one before it. brokenAt names the first break.
Plate 06

Server, client, shared: exactly one module may cross

three declared module sets · the one named grant · two transports, one service seam

THREE DECLARED MODULE SETS, ONE PRODUCT server · 11 modules furth.mertekstak.server 1.5.0 locality server, product-private entries: request.handler + schema orchestration · backup.aws · control console.operations · console.dispatch api.dispatch · registry.handshake application-infra service + transport client · 5 modules locality client, product-private the operator console only client.boot · client.console client.console-render client.web-boot · client.web-console it owns t.ui.form and the toolkit the server console carries neither shared · 1 module contract.mertekstak.application-infra locality both, shared-contract 5 endpoints, exact field sets 27 declared refusal verdicts 3 declared live-edit intents a definition-only service client no handler, no schema, no credential WHAT CROSSES, AND WHAT THE RESOLVER REFUSES MerTek.io a declared consumer product names ONE exact visibility grant the shared contract module the only thing that may cross the grant is what makes it auditable MerTekStak owns its own rows the contract names an app by NAME it carries no entity or column name grantModuleUndeclared a grant naming any other module of that package refuses before the graph walk Nothing reaches MerTekStak by spelling a namespace. The named grant is the door. TWO TRANSPORTS, ONE SERVICE SEAM remote adapter the real call/event wire, over a socket co-located adapter same process, no socket, no frame stakInfraServiceInvoke The co-located adapter invokes exactly the function the wire dispatcher invokes. It cannot skip the admin guard, the grant validation, the audit write or the denial write. Both return the same typed result, and an unrouted key yields unknown_endpoint on both.

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 control

Authorized teams can manage application source, configuration, and release state through one governed surface.

Specific example

A program office can see which approved application generation is assigned to a test or field environment.

Controlled live change

A change is checked, claimed, published, and kept with a recoverable prior state. Rollback is part of the normal model.

Specific example

An urgent workflow update can be tested in a bounded environment and returned to the last approved state if needed.

Evidence as data

Test results and their source identity are stored as platform records. A green result is tied to what was actually reviewed.

Specific example

A readiness review can connect an application release to the checks and source used to produce it.

Uses

Example uses

Pilot questions

What the team must decide

Who may approve and publish changes

What evidence is required for each environment

How rollback authority should work during operations

Request a technical briefing