ArXiv Amendment 38: ForgeLivingProof — Proof That Stays Alive

ForgeChainOS · Node Zero (Jack Mosel) with Junior · 2026-11-02

An agent saying "done" is a claim. ForgeLivingProof makes it a measurement.

Abstract

Teams now hand real work to AI agents and then spend their days checking it. The bottleneck is no longer writing code or posts. It's trusting them. Most systems answer "did it work?" with the agent's own report, a green checkmark, or a document that says what should be running. All three can be wrong while looking right.

This paper describes ForgeLivingProof, a ForgeChainOS DApp for enterprise. It keeps three ledgers of a system (what is declared, what is wired, and what is observed) and reports every gap between them. A task isn't done until an independent observer proves it. Each proof records who saw what, when, with a hash. A proof expires when the thing it proved changes. The product's measure of success is blunt: the system should find its own faults before the owner does.

We wrote it after our own system failed in exactly these ways in one week. Section 5 shows how.

1. The problem: three versions of the truth

Every running system exists three times:

Nobody keeps them in agreement. Documents drift from code. Code ships without being seen working. And the checks themselves can lie. We call every disagreement between the three a missing cable, and there are four kinds:

1. Declared, not wired. Promised but not built.
2. Wired, not declared. Running, but invisible to anyone reading the docs, including other agents.
3. Wired, never observed. Running, but nobody has proven it works.
4. Observed wrong. The verifier reports a false result.

The fourth is the dangerous one, because it turns a safety check into a source of errors.

2. The standard

ForgeLivingProof scores claims against a standard taken from ForgeChainOS canon. A claim passes when:

1. LOGOS — it is true and sourced. Every statement is true, its provenance is given, no inference is dressed as an observation, and every citation credits its real author.
2. LOTUS — it uses what is already known. If the record already covers it, the claim draws on that record and cites it. When the record and a live observation disagree, the observation wins and the record is corrected.
3. DETENTE — nothing unmeasured is stated as fact. DETENTE = f(IMMUTABLE TRUTH). A claim that asserts something unmeasured is itself the breach.
4. The Truth Gate — where a chain copy exists, it matches. The hash of what the chain serves must equal the hash of the file on disk: MATCH passes, DRIFT fails. Where no chain copy exists, the measurement is a live observation.

Three rules sit on top of the standard:

• Vantage. Every agent proves only from what it can observe itself. One agent's report is never another agent's proof.
• Order of trust. First live observation, then the record, then anyone's say-so.
• Check the checker. Every verifier is tested against a case known to be true and a case known to be false. A verifier that can't tell them apart gets no vote.

There is no badge. A claim that passes is written to the owner's private index with its observer, time and hash. The index is the record. Permanence comes from an on-chain stamp, which only the owner fires.

3. How it works

1. Feature map. One file per user-facing feature: what it is, how to reach it, how to drive it, and the end state that counts as "works". It also lists the controls an automated prover must never touch (send, publish, approve, pay, delete), and those stay manual.
2. Prover. An isolated, read-only browser session drives the client's app the way a person would. It records the DOM, console errors, a screenshot, and the hash of the served page compared with the source. It writes PASS, FAIL or SKIPPED for each feature, and says why for every skip, for example "needs a physical iPhone GPU".
3. Cable audit. A read-only sweep compares the three ledgers and lists every gap by kind.
4. Proof tile. One number, gaps outstanding, with each gap listed red or green in the client's dashboard. Status goes in front of a person, not into a log.
5. Loop and graph. In an agent team, a task returns to its worker until its proof passes (the loop). A passed proof, not the worker's word, travels to the next worker (the graph). Unproven work sits in a visible UNVERIFIED lane, so it is neither passed along nor lost.

Proofs run when something changes or when a worker asks, not on a timer. A proof is true as of when it was taken, and it says so: "RUNS as of 14:10".

4. Prediction and productivity: On-Parr

A language model is a next-token predictor, so its work can be metered. On-Parr, ForgeChainOS's prediction engine, reads the local model's own count of predicted tokens and the power drawn while producing them, giving joules per token. It also checks the meter against the rider: if the gauge improves while joules per token do not, it reports DECOUPLED instead of a win.

ForgeLivingProof uses prediction in two places, and never as proof:

• Triage. On-Parr predicts the expected outcome. A large prediction error, meaning the observed result surprised the model, sends that claim to the front of the proving queue. Surprise tells you where to look.
• Verified productivity. Tokens are effort, not output. The measure is proofs passed per thousand tokens, and per kilojoule: proven work divided by what it cost to produce. An agent that writes a lot and proves little scores low, however busy it looks.

Prediction can't certify a claim, because a fluent wrong answer is exactly what a predictor expects. Our marketing agent's "success" report (section 6) was perfectly predictable and false. The prediction says where to look; the proof says what's true.

5. What runs today, and what doesn't

We hold this paper to its own standard.

6. Case study: one week, all four kinds of fault, in our own house

• Observed wrong. Our marketing agent posted the same announcement five times in six days. Each post went out, but the confirmation step hit an error afterwards and reported "not run". With no record of success, every pass tried again. The verifier was the fault. The fix records an attempt before posting and never retries an unconfirmed post automatically.
• Wired, not declared. A peer AI reviewer audited our system from its own word list and reported five subsystems as missing or only planned. All five were running. The reviewer reasoned correctly from a record that was wrong.
• Declared, not wired. An announcement claimed more than the system yet does: a component described as living on chain is still planned. The Truth Gate would have stopped that sentence.

• Wired, never observed. One page went black on a phone, and another left the user with no way back. Both ran without errors, and both were found by the owner, not by the system.

• First run. On its first pass the prover found a live-data panel failing behind a proxy pointed at the wrong address: a fault no person had reported. That is the product working.

The owner found every one of these. That is the failure ForgeLivingProof exists to end.

7. Who it is for

• Teams running AI agents in production that need "done" to mean proven.
• Companies whose documentation, product catalog and real system have drifted apart.
• Anyone who publishes on chain and needs to know their stamps say what they think they say.

8. Limits and dangers

• A prover sees what a browser sees. Hardware-specific faults (a particular phone's graphics chip, a payment provider's real checkout) are reported as SKIPPED with a reason, never as PASS.
• A proof is a point in time. It expires on change and can't vouch for tomorrow.
• Proving can be gamed by a worker that writes its own test. That's why proof comes from a separate vantage and every verifier carries a known-false case.
• The ledgers are private. A map of what you run and what is weak is a gift to an attacker. ForgeLivingProof keeps the index, feature map and audit on the client's own metal and never publishes them.

9. Availability

• Included in SOVEREIGN ($499/mo) and IMPERIAL ($999/mo) as part of the assurance stack, at no cost to onboarded clients.
• Standalone: $99/mo for one system up to 50 features. Org: $399/mo for up to 5 systems, with the agent-team loop and graph.

10. Conclusion

Verification isn't a step at the end. It's a ledger kept alive alongside the system. ForgeLivingProof replaces "trust me" with "here is what I saw, when, and its hash", and it counts success by one thing: faults the system finds before you do.

A whitepaper from ForgeChainOS · NODEZEROINSIDE

ForgeLivingProof for your systems: see Enterprise →