Furth FortuneM9 reference

Assurance fabric / System overview

Evidence and Verification

Checks with explicit scope and verdicts

The gate system records what each check covers, what it ran, and whether it passed, failed, or was held. Aggregate profiles list the checks they include.

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

Five entries, one planner, no second copy

entry → driver.sh → evidence

ENTRY PLANNER EVIDENCE run-all.full.shfull release profile, all sections run-all.sh11 groups, per-group time budget run-group.sh <group>one subsystem group dev-testchanged-path developer loop thalassa/shader/run-all.shone declared suite each shell entry first sources scripts/use-build-cache.sh so $CC routes through one cache native/gates/driver.sh plan · execute · record · summarise --fullrelease authority --groupsordered phases + budgets --suiteone suite.conf fold --focusone leaf or suite member --incrementalchanged-path closure --dry-lanesnon-executing projection GATE_EXECUTION_ENGINE legacy shell (default) scheduler (native, gate_scheduler.c) one plan compiles for both READS gates/sections/*.conf · 106 gates.d/<sec>/<gate>/gate.conf · 1800 */run-manifest.conf · 58 files ordered plansection order × requires preorder leaf run.sh, own processGATE_ID · GATE_TMPDIR · artifact dir results.tsv · timings.tsvone typed row per leaf, per action run-record.txtreproducibility record for the run SUMMARY failed leaves counted, not checks unavailable reported apart from both
Plate 02

Anatomy of a gate leaf

gate.conf fields · run.sh fragment · the two sibling declarations

native/gates.d/<section-id>/<gate-id>/ gate.conf schema 2 · every leaf in the tree IDENTITY id · section · title owner · doc fragment run.sh GRAPH requires · covers inputs path: / product: products · productArtifacts productEnv EVIDENCE results · verdictChannel exerciseLayer exercises artifactPolicy · outputs EXECUTION POLICY · all required, no defaults lane · requiredBy platforms · capabilities coordinatorScope timeoutSeconds inputPolicy verdictPolicy seedPolicy retryPolicy resources · environment clockPolicy · networkPolicy renderPolicy outputs The strict parser refuses an unknown field, a duplicate field, an unknown enum value, a malformed resource claim, an unsafe policy pair, a cycle, and a cross-section requires. A path input that covers no tracked file is refused at plan time, not at run time. run.sh the fragment · the only executing part 1 · source gates/fragment-prelude.sh $CC line · build profile · embed TUs 2 · section "<name>" console heading, CI feed section 3 · run the script named in covers the real gate body lives there 4 · chk / chk_skip per declared result appends r or s to the observed file 5 · [ "$fails" -eq 0 ] terminal exit status SIBLING DECLARATIONS gates/sections/<id>.conf id · the section slug title · human heading order · position in the full profile groups · which group profiles reach it one per gates.d section directory <dir>/run-manifest.conf classifies EVERY runner beside it gate · covered · helper · developer deploy · benchmark · retired lane= id= owner= covers= nothing is inferred from a filename a leaf's gate.conf IS its classification THE TWO VIEWS AGREE A leaf id equal to a run-manifest gate id must list that runner in covers. A runner the metadata says is EXECUTED must hold something to run: an empty or comment-only file exits 0 and would record a green result asserting nothing.
Plate 03

Plan construction: sections in order, leaves in preorder

section order · requires forest · profile filters

1 · SECTIONS BY DECLARED ORDER order 1benthos-substrate order 2sanitizer-lane order 3trident-instant … 106 sections … order ntoolchain-matrix 2 · INSIDE ONE SECTION · requires IS A DAG EDGE, NOT A LIST A · requires - B · requires A C · requires B E · requires B D · requires - a second root is legal two leaves may share a parent PREORDER PLAN roots in declared order each branch's whole subtree first declared order = node directory path A → B → C → E → D The driver REFUSES a section whose plan misses any declared node. TWO THINGS requires IS NOT It is not a linked list. Set it to the section's last leaf id to append in order; forking is legal, not a hack. It is not a SELECTION edge. The selector emits every node as requires=- and carries it in order=. 3 · THE PROFILE SELECTS A SLICE OF THAT PLAN --fullevery section in ordernever reuses a verdict --groupssections whose groups matchphase budget, typed not-run --suitesuite.conf ordered membersplus each member's closure --focusone leaf or suite memberthe only reuse-eligible mode --incrementalchanged-path closureunknown path → full plan
Plate 04

Selection and the five identities

changed paths → dependency index → selector → closure · identity reuse

SELECTION changed paths staged · unstaged · untracked gate-dependency-index lookup path → owning nodes gate-selector --affected walks declared product edges exact node closure the gates this change can break unknown path → FULL plan fail broad, never zero, never release green A PRODUCT EDGE SELECTS IN BOTH DIRECTIONS producer leafproducts trident-cli consumer leafinputs product:trident-cli A producer change selects its consumers; a selected consumer pulls its producer. THE FIVE IDENTITIES toolchain-idcompiler closure, hashed once per install manifest-id plan · selector graphworkspace snapshotcontext-id An ordinary tracked-source edit reuses toolchain, manifest, plan and selector graph. Only the workspace snapshot moves. The corpus asserts BOTH reuse and reprojection, because asserting reuse alone would pass a driver that reuses everything always. VERDICT REUSE · THE BOUNDARY ALLOW --focus, or --incremental that did not expand keyed on full input closure + BUILD_PROFILE FORBID release and full profiles, GATE_REUSE=0 a volatile or flaky leaf is never reusable The controls are EXECUTED against the real driver: cold publishes once, warm reuses with zero attempts, and a rewarm proves the refusals.
Plate 05

Verdict resolution: a leaf cannot pass on silence

leaf execution → exit branch → non-vacuity → typed verdict

DRIVER PREPARES THE LEAF GATE_ID · GATE_RUN_ID GATE_TMPDIR · GATE_ARTIFACT_DIR GATE_RESULTS_OBSERVED_FILE GATE_UNAVAILABLE_EXIT=77 TERMINATION BOUND timeoutSeconds N bounds this leaf 0 inherits GATE_LEAF_TIMEOUT_SECONDS 7200 s default · in-tree mtk_bound_run run.sh · ITS OWN PROCESS chk 0 "…" → prints ✓, appends r chk 1 "…" → prints ✗, appends r, fails++ chk_skip "reason" → prints ~, appends s exit through [ "$fails" -eq 0 ] EXIT STATUS BRANCH 124 → timed-outa distinct red; the run continues 77 → unavailablecapability absent, never green other non-zero → failthe ordinary failure run.sh changed mid-run→ invalidated-by-churn 0 → keep goinga zero exit is NOT yet a pass NON-VACUITY · OBSERVED vs DECLARED observed = count of r plus s appended skipped = count of s appended declared = gate.conf results channel = verdictChannel, chk or exitcode channel exitcode AND observed > 0 → channel-mismatch observed − skipped = 0 → vacuous observed ≠ declared → results-mismatch otherwise → pass TYPED OUTCOME REFUSES GREEN fail timed-out vacuous results-mismatch channel-mismatch NOT PERFORMED unavailable invalidated-by-churn GREEN pass reused, on an exact key
Plate 06

Lanes, the shared machine, and the build-cache authority

four lanes · coordinator scopes · one cache authority

LANES · DECLARED, NEVER INFERRED automatic · 1,715 MUST be reachable from the full profile device · 113 dispatched to a matching device or OS only manual · 53 operator-run under a declared procedure approval · 4 performs an approval-gated side effect The other three lanes are classified WITHOUT a gates.d leaf. --dry-lanes projects them as explicit pending states, and can never emit a green verdict. AGENT COORDINATOR · SERIALISE THE HEAVY SCOPES repoaggregate gates · stale after 7200 s native-buildshared compiler cache · 3600 s trident-runtimetrident_rt.c-driven binaries · 3600 s external-toolsimport and conversion lane · 3600 s exit 75 · another live agent owns it read the printed owner and note, then go find other work, or rerun with --wait CLAIM BEFORE YOU WORK Co-located agents are invisible to each other otherwise. A claim expires on its own after 4 h, so a crashed agent cannot wedge a key forever. BUILD IDENTITY · ONE AUTHORITY PER RUN scripts/use-build-cache.sh strips any earlier launcher from PATH ccache · the current authority memoises compiler invocations gate-action · declared successor compile + link + runner artifacts, typed BUILDCACHE_OFF=1 · no routing at all used only to measure a cold build WHY IT MATTERS HERE Every compiling gate builds the whole trident_rt.c translation unit inside its own TU. Cold that is ~100 s per leaf. The win is on the REPEAT run, so keep CCACHE_DIR persistent across worktrees. A throwaway cache dir pays cold forever.
Plate 07

What the gates actually prove

conformance oracle · render parity · sanitizer lane · meta-gates

A · CONFORMANCE ORACLE 2,747 .tri programstop-level conformance cases trident_rt.cbuilt -static on Windows stdout4 or 8 parallel workers string-equal vs .expected2,747 frozen fixtures · any diverge = red B · RENDER PARITY · ONE IR, FIVE LOWERINGS Reef blockcanonical artifact is achecked GlintModule Glint IRsingle sourceof truth glint_soft · the CPU oracle glint_wgsl → wgpu, browser + desktop glint_hlsl → D3D11/12, HoloLens glint_spirv → native Vulkan glint_msl → native Metal pixel diff vs the oracle 1 to 2 channel tolerance, or typed parity renderPolicy CENSUS soft-oracle · 148 leaves gpu-preferred · 19 backend-parity · 2 none · 1,631 A feature lands in ALL FIVE backends in the same change. Count from the tree. C · SANITIZER LANE · FLAKE VERSUS REAL, AS DATA ASan then TSanserial, one lease attempt 1 failsrecorded, not judged standalone re-runthe flake rule as data passes → flaky=1, green fails → real, named, red gate_result + gate_attempt_event → D6 evidence fold D · META-GATES · THE INSTRUMENT CHECKS ITSELF manifest-check · source-naming · stranded-glob · assert-fatal decline-propagation · self-aliasing-copy · generator-drift-sweep Each plants a known-bad fixture AND a known-good one every run, because a scan that matches nothing reads exactly like a clean tree.

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.

Declared checks

Each check states what it covers, what it needs, and what result it produced. Silence is not treated as success.

Specific example

A network-loss test must show its verdict and evidence before a release can claim resilient operation.

Known review scope

The system records which checks were selected and why. Different review levels can share one evidence model.

Specific example

A pilot review can run a focused mission set while a release review includes the full approved profile.

Operational proof

Observable behavior can include images, video, data, or timing records. The proof matches the claim being reviewed.

Specific example

A display change can include a captured field-device view, while a data change can include an integrity record.

Uses

Example uses

Pilot questions

What the team must decide

Which claims require direct proof

Who accepts each class of evidence

How evidence should be retained and compared over time

Request a technical briefing