Runtime governance: the closed loop

Rebuilding a system deterministically solves day one. The harder problem is day one hundred: developers experiment, dependencies change, AI agents generate code, and every environment drifts. FalconSmith governs that evolution as a closed loop - change is free at the edge, verified at the center, and converged everywhere, with an audit verdict at every step.

The console excerpts below are condensed from the reference system's live proof transcripts. Package and crate names are from the reference build.

Station 1: experiment freely

A developer on a branch installs whatever the work needs - Python packages from PyPI, or new Rust crates for a native unit. Nothing asks permission. On the next activation, the additions are recorded automatically: Python packages into a git-tracked branch record, crate demands into a local free-roam record. The approved runtime is untouched; an abandoned branch leaves zero trace in it.

Station 2: the team catches up

A teammate pulls the branch. Activation reports what the branch gained, with attribution, and one command installs it - no administrator, no central access, no waiting.

[TEAM] windows-x64/py313/core/dev: 1 package a teammate added to this
       branch is not installed here - run 'forge add-missing'
> forge add-missing
[OK] installed what the branch declares

Station 3: verified promotion

When the branch is reviewed and merged, an administrator promotes its additions into the approved runtime with one command, no flags. Every artifact is independently re-fetched and sha256-verified - never trusted from a developer's machine. Python wheels and Rust crates are handled in the same pass: wheels enter the verified pool, crates are vendored into the runtime as tree-hashed sources.

> forge admin promote
+ tqdm==4.68.3 -> role/dev.in
1 crate(s) vendored
[OK] promotion recorded; approved manifest updated

Promotion is atomic: a failure at any point restores the previous approved state, and a re-run completes cleanly. The registry is append-only - every promotion is logged, nothing is ever silently rewritten.

Station 4: everyone converges

After the promotion is pulled, every machine converges with one command. forge sync consumes the reconcile diff and fetches exactly what is missing from the internal share - verified against the local, git-tracked manifest, never against the share's own word. For native dependencies, the vendored source tree is fetched the same way and forge smithery rebuilds the affected units offline from the verified sources. No full environment rebuild.

> forge sync
[GET] + hex==0.4.3
[OK] rust vendor verified against the approved manifest (37 crates).

Station 5: re-grounding - provenance converges too

The subtle gap most systems never close: the machine where the experiment began still runs the bytes it downloaded from the public index - bytes that predate their own approval. FalconSmith detects exactly that state and replaces those bytes with the verified artifacts.

[TRUST] windows-x64/py313/core/dev: 1 package you installed from PyPI
        is now approved - run 'forge sync' to re-ground it to the
        verified wheel:
        -  tqdm==4.68.3
[TRUST] rust: 1 native unit was built from crates.io bytes the vendored
        runtime now covers - run 'forge smithery' to re-ground it:
        - ascii_csv_reader_rs (hex==0.4.3)

After the re-ground, the free-roam records are cleared and every machine - including the original experimenter's - runs the same verified bytes. Versions converge in any lockfile system; here, provenance converges.

The audit: every activation, every surface

forge reconcile runs read-only on every activation: it re-hashes the live system - environments, embedded components, and the vendored Rust source tree - and compares it against the approved manifest. Every run is retained in an append-only audit history. The verdict distinguishes additive lag (with the exact command to converge) from modification and tampering:

[ OK ] rust vendor : 37 crates match the approved manifest

[DRIFT] rust vendor : 1 approved crate not vendored locally yet -
        run 'forge sync'

[FAIL] rust vendor : DRIFT - tampered or locally extended vendor
        (indistinguishable by design)
        vendor changed : hex

The tamper case above is the deliberately hard one: the source of a vendored crate was edited while its lockfile still matched. The lockfile alone would have passed. The tree hash caught it.

The enforcement layer is itself under test

The reconciliation, convergence, and promotion logic ships with its regression suite inside every delivered library and runs at every rebuild, on your machines. The trust layer is not vendor-asserted - it proves itself in your own test runs. The access boundary is visible in the same report: on a developer clone, maintainer-tier tests skip with a printed reason, because the maintainer machinery is not shipped there at all.

What the cycle deliberately does not do

• It never removes a developer's own experimental packages - the freedom lane is never punished, only reported.
• It never changes the version of an already-approved pin on its own - that is a deliberate, manual administrator decision, flagged as a conflict rather than auto-resolved.
• It never trusts the distribution channel - the internal share is a byte source, not an authority; every byte is verified against the git-tracked manifest on the receiving machine.

The verbs involved are described in Engine workflow; the verification model behind the verdicts in Verification.