Dream Machine can now evaluate its own improvements without being allowed to approve them

What this is about

Dream Machine runs improvement work on a schedule: it looks at a project overnight, proposes changes and reports what it found. The obvious next step is to let it judge whether its own changes are better, and that is also the obvious way to get a system that approves everything it writes.

This change takes the first half and refuses the second. The loop can now evaluate, and the evaluation is structurally prevented from granting approval.

What changed

Pull request #123 was merged on September 20 as commit aa931caa. It adds an optional evaluation boundary to compiled improvement routines, a receipt verifier with no dependencies of its own, and a read-only preflight check. The default prompts and the merge policy are unchanged, and the pull request states plainly that evaluation cannot grant merge or deployment authority.

What makes a receipt worth anything here:

• It binds the exact executed commits along with digests of the source, the evaluator, the workload and the environment, plus the policy, a nonce and a freshness bound.
• It requires independently collected evidence rather than the loop's own account of itself.
• A missing observation returns an inconclusive result. It does not degrade into a pass. Mismatches and failures reject.
• Paired comparisons are measured against frozen quality, cost and latency limits, so a change cannot pass by moving the goalposts.

The pull request is explicit about what hashes do and do not prove: they are integrity, not authentication. The command-line entry point refuses irregular files and symbolic links and bounds input size, and the interfaces reject getters, inherited objects, unknown fields and malformed metrics. An independent review found regressions in two of those defences during development and they were retested. The recorded validation is 785 tests passing against 697 on the parent commit, with a clean dependency audit and no new dependencies, no production credentials, no network listener and no merge interface added.

Get started

Prerequisites: a clone of the repository and a current Node.js. The pull request records its validation on Node 24.19.0, and the project's own check script is the documented entry point.

npm run check

Expected result, as recorded in the pull request: the full check passes, covering 645 unit tests and 140 governance tests. If governance tests fail, the evaluation boundary is not behaving as specified and its receipts should not be relied on.

Commands quoted from the pull request validation notes; not executed here. The evaluation boundary is optional, and enabling it is a configuration decision for the operator of a loop, not a default.

Use it today

Practical case: an overnight loop proposes a performance change. Input is the change plus a frozen set of quality, cost and latency limits. The workflow is to run the paired comparison and collect the receipt. Output is a rejection, an acceptance, or an inconclusive result when the evidence was not actually gathered.

Reader acceptance test: withhold one required observation and confirm the result is inconclusive rather than a pass. A system that passes on missing evidence is not gating anything.

Push it further

Experimental commentary. Separating evaluation from authority is the part worth copying into any self-improving pipeline. The moment the thing that measures can also approve, the measurement becomes a formality, and that happens without anyone deciding it should.

Limitation, in the project's own words: hashes provide integrity, not authentication. A receipt proves a set of inputs produced a set of outputs; it does not prove who produced them. Depends on the optional boundary being enabled and on the evidence actually being collected independently. Falsifiable test: replay a receipt outside its freshness window and confirm it is refused.