Furth FortuneEngineering reference
TECHNICAL DOCUMENTATION

2027 · MerTek technology

On this page

Engineering reference / System overview

Release Assurance

Approved source in, a traceable release out

Release assurance turns one source commit into release bytes anyone can trace back. One flag table fixes every build choice, and one compiler launcher feeds a content cache. Derived inventories are rebuilt from the final source, and the release record ties each executable's hash to its commit, gates, components and proof host.

Worked example

An OpenSSL advisory on a Tuesday morning

The Tulsa depot runs MTK release 1.4.0 on 140 Windows kiosks and 12 Linux service nodes. At 08:40 an advisory names the OpenSSL 3.5 line. The platform release lead has to name the shipped builds that carry the library and publish a fixed release the same day. The record must let the depot's auditor check every step without trusting anyone's memory.

  1. Read the release record, not a spreadsheet. Each target row names its proof host and its executables' hashes, and the record lists the third-party components inside each target. The Windows executables link OpenSSL 3.5.9 statically; the Linux executables load the operating system's own libssl.so.3.

    {
      "schema": "mertek.tri.private-release",
      "version": "1.4.0",
      "sourceCommit": "9b2e4c71a0d58f36e1c7b90a4d2f8e63c5a1b7d0",
      "targets": [
        {
          "identity": "windows-x86_64-pe",
          "proofHost": "release-win-02",
          "tri": { "objectDigest": "4f9a07c2e81b3d65a0c4e7f19b2d83c6a5e0f71d4b9c2a8e3f6d0b1c7a5e9d24" },
          "components": [
            { "name": "OpenSSL", "version": "3.5.9", "linkage": "static", "license": "Apache-2.0" },
            { "name": "Unicode Character Database", "version": "17.0.0", "linkage": "compiled-in", "license": "Unicode-3.0" }
          ]
        },
        {
          "identity": "linux-x86_64-elf",
          "proofHost": "release-linux-01",
          "components": [
            { "name": "OpenSSL", "version": "3", "linkage": "system libssl.so.3", "license": "Apache-2.0" }
          ]
        }
      ]
    }
  2. Change the pin in one place. Compiler flags, per-node optimization levels and provider package roots are named lines in the checked-in build graph. The fix changes the provider pin where it is declared, and no workstation setting or environment variable can supply a second answer. A new pin is accepted only when two producing hosts rebuild the archives byte for byte.

    cflags = -std=c11 -fno-fast-math -fexcess-precision=standard -ffp-contract=off -fstack-protector-strong -fPIC -ftls-model=initial-exec -fdata-sections -Wall -Wextra -Wpedantic -Wvla -Walloca -Werror -I.
    mertektypes_optimization = -O3
    mercrypto_optimization = -O2
    merprim_optimization = -O3
    draft_optimization = -O2
    thalassa_optimization = -O3
    # The complete Windows TLS build provisions this exact static OpenSSL.
    openssl3510 = build/providers/openssl-3.5.10-static
  3. Rebuild through the one launcher. Every compile edge runs the same launcher. It keys each object by its inputs and returns a stored object when nothing it reads has changed. Only the TLS adapter objects compile again, and every Windows executable relinks because each Windows link takes the TLS archives.

    test_class_cc = build
    rule cc
      command = $python tools/compile_runner.py --compile $out --depfile $out.d --identity c24e8aacd89902a6 -- $cc $cflags $providercflags -fstack-usage -MD -MF $out.d -c $in -o $out
      description = cc $in
      depfile = $out.d
      deps = gcc
      restat = 1
  4. Rebuild what is derived, after the last rebase. Inventories such as the cross-node dependency graph and the type reference come from the final source state, never from a hand merge. Their generation lanes rederive each one and refuse a stale checked-in copy.

    git fetch origin
    git rebase origin/main
    # Regenerate each derived inventory with its own writer on this exact
    # tree, and land it with the change. Never hand-merge one.
    ninja -k 0 design-graph-test mertektypes-reference-test
    # Each generation lane rederives its inventory from the final source
    # and fails on a stale checked-in copy.
  5. Gate, bless, and publish the manifest last. Each proof host runs the full plan at the release commit, and the bless records an executable's SHA-256 only after that run exits 0. Objects publish first and the manifest last, so a half-published release never has a name.

    # The private release manifest, written after every object reads back.
    text schema = "mertek.tri.private-release"
    u16 schemaVersion = 2
    text releaseKind = "release"
    text version = "1.4.1"
    text sourceCommit = "5f0c2a91d4e7b3c8a6f1e0d9c2b4a7e3f8d1c6b9"
    text[] requiredTargets = ["windows-x86_64-pe", "linux-x86_64-elf", "macos-arm64-macho"]
    chest[] targets = [
        {
            text identity = "windows-x86_64-pe"
            text operatingSystem = "windows"
            text architecture = "x86_64"
            text objectFormat = "pe"
            text proofHost = "release-win-02"
            chest tri = {
                text kind = "tri"
                u64 size = 23511054
                sha256 objectDigest = "8a41c0f3d2b97e65a1c4f08d3e2b7a96c5d10e4f2a8b3c7d6e9f01a2b3c4d5e6"
            }
        }
    ]
What happened

By 17:00 release 1.4.1 was published with OpenSSL 3.5.10 in every Windows executable. The Linux nodes took the operating-system package after their native TLS lanes passed on the new library. The version came from the catalog rule, because the fix added no library surface. The auditor checked one record that named the commit, every hash and every receipt.

System diagram

Reproducible release record

The output stays tied to its source, resolved dependencies, and inventory.

  1. Approved source commit 7c2…
  2. Resolved inputs compiler + packages
  3. Build + gates artifact and verdicts
  4. Release record hash + SBOM + provenance

Inside the system

How the parts work together

Follow the data, decisions, and access boundaries. Each diagram explains a concept used by applications.

Map 01

One table of build choices

Target, profile, optimization and provider choices resolve from named lines in the checked-in build graph, never from a host default.

  1. Build request target + profile
  2. Flag table single authority
  3. Resolved choices complete inputs
  4. Compiler no private defaults
Map 02

One compiler launcher

Every compiling gate enters through the same cache and toolchain boundary.

  1. Gate compile request
  2. Launcher toolchain authority
  3. Cache content lookup
  4. Compiler miss only
  5. Artifact recorded output
Map 03

Repeat-build cache

Compilation splits into reusable objects, then links the requested result.

  1. Sources content hashes
  2. Object cache hit or compile
  3. Reusable objects stable inputs
  4. Link requested artifact
Map 04

Host dependency closure

The target resolves its required host substrate instead of listing files by hand.

  1. Target declared host
  2. Dependency graph required modules
  3. Resolved closure complete set
  4. Build no hidden file order
Map 05

Derived artifact freshness

A tree-wide inventory is rebuilt after the final source state is known, and its lane refuses a stale copy.

  1. Source tree changes new final state
  2. Derived catalog now stale
  3. Regenerate whole-tree input
  4. Verify catalog matches source

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.

One table of build choices

Compiler flags, optimization levels and provider package roots are named lines in the checked-in build graph. A host compiler's defaults never decide what ships, so two machines that build one commit read the same choices.

For example

The flag -ffp-contract=off is on every compile line. No compiler may fuse a multiply and an add and change the last bit of a result.

One launcher, one content cache

Every compile runs through one launcher that keys an object by its inputs. A hit returns the stored object; a miss compiles and publishes it. A header edit rebuilds only the objects whose dependency files name that header.

For example

Two worktrees of one commit share compiled objects through the cache. A cache or compiler failure leaves the earlier outputs in place and fails the edge.

A release record that names its bytes

Each target row names its operating system, architecture, proof host, executable hashes and gate and bless receipts. The record also carries the license bundle and the component inventory. Publication writes every object first and the manifest last.

For example

A manifest whose target names a different source commit, or whose digest does not match its object, is refused before the release name changes.

Code

Release Assurance in code

Each example is short and complete enough to read on its own. Hover a dotted word for its definition.

Shell

An object, an archive and a link

Each production .c compiles to its own object, each node publishes one archive, and an executable links archives. A header edit reruns only the compile edges whose dependency files name it.

# One object per source, one archive per node, and links that take archives.
build $builddir/merwire.o | $builddir/merwire.su: cc merwire/merwire.c | merwire/merwire.h chest/chest.h mertektypes/mertektypes.h
build $builddir/libmerwire.a: ar $builddir/merwire.o
build $builddir/merwire-canary.exe: link $builddir/merwire-canary.o $builddir/libmerwire.a $builddir/libchest.a $builddir/libmertektypes.a $builddir/libmerprim.a $builddir/libplatform.a
Shell

The host dependency closure is declared

Each image starts from one target-qualified import list and adds only what its own link closure carries. The image check holds the built executable to that list, so a stray system library is a red build.

# Every Host image starts from one target-qualified declaration. An image
# adds only imports its own link closure carries.
trident_selected_host_artifact_imports = --artifact-os-import pe=ntdll.dll --artifact-os-import pe=WS2_32.dll --artifact-os-import elf=libm.so.6
tls_host_artifact_imports = --artifact-os-import pe=CRYPT32.dll --artifact-os-import pe=ncrypt.dll --artifact-os-import pe=api-ms-win-crt-convert-l1-1-0.dll --artifact-os-import pe=api-ms-win-crt-filesystem-l1-1-0.dll --artifact-os-import pe=api-ms-win-crt-time-l1-1-0.dll
JSON

The legal bundle every package carries

The license record pins each legal file by size and SHA-256 and folds them into one bundle digest. A package that ships a changed notice fails that digest before publication.

{
  "schema": "mertek.license/1",
  "license_id": "FF-MERTEK-1.0",
  "license_version": "1.0",
  "licensor": "Furth Fortune LLC",
  "bundle_sha256": "afa3a17517679a42c3b853beace281a62b570f72613928e0a0ab2255b35c3d42",
  "artifacts": [
    {
      "role": "agreement",
      "package_path": "share/mertek/legal/LICENSE.txt",
      "media_type": "text/plain; charset=utf-8",
      "size": 37400,
      "sha256": "3ddda0bec15978b5fe8368ebd7131b39e41f5628aabf0682853fecba3115d345"
    }
  ]
}
Shell

Prove one change, then land it

The verdict grades the rebased tree you push. A conflict-free rebase carries that verdict, but never the build: when the incoming commits changed C, rebuild your objects before the push.

git fetch origin
git rebase origin/main
ninja -k 0 merwire-test
git push origin HEAD:main
git fetch origin
git merge-base --is-ancestor <sha> origin/main
Shell

Bless before package

A package never wraps a fresh build. It wraps an executable that passed the native gate and carries a bless, and its metadata repeats the blessed digest.

# For each executable, on each proof host, in this order:
# 1. ninja -k 0 test exits 0 at the release commit
# 2. the bless records the executable's sha256 as the host's pin
# 3. packaging reads the blessed bytes and digest from the cache
# 4. the package states that exact digest in its own metadata
# A packaging step that compiles, patches a source or blesses is refused.
ninja -k 0 test

Uses

Example uses

  • Answering a component advisory across deployed builds
  • Release records an auditor can recompute
  • Repeatable builds on several proof hosts

Review questions

What the team must decide

Which components each deployed target carries, and how they are linked

Which proof hosts must pass before a release publishes

How long release records and receipts are kept

Contact us
FURTH FORTUNE / ENGINEERING REFERENCEBack to top ↑