BUILD NOTES / WORKFLOW CHECKS

Checks with the power to say no.

A workflow needs a clear next step when something fails. These two recorded examples show what the checks caught, and what remains outside their scope.

Published
Last updated ·

Illustration of a leafy workshop with two compact computers and a monitor on a wooden bench.
Workshop illustration.

PROMPT OS + RESEARCH OS / JULY 2026

A plausible handoff still has to pass.

A handoff is the package of findings and evidence passed to the next tool. Here, one stopped because its status field did not match the required wording. A later automated replay found seven filename mismatches against the package’s evidence list.

On July 22, a handoff used AUDIT_STATUS: PASS where the contract required the exact token PASSED. The manual return check halted it with E-UNAUDITED. The log says the audit had run; the status field did not match the contract.

The July 26 entry describes a later coded-validator replay against a pre-fix package. It recorded seven E-OFFMANIFEST findings for evidence filenames that did not match the allowed list.

The practical lesson: make the required format explicit and check the actual handoff before passing it to the next tool. A convincing explanation cannot fix a mismatched filename.

This is a redacted summary of the project incident log, not the original packet or raw validator output. The July 26 entry also records that the validator was built from an outdated specification. These historical findings do not establish current deployment correctness.

AEOS / SCRIPTED TEST / 10 SEPTEMBER 2026

Passing a check earns the next step.

AEOS stands for Agentic Engineering Operating System. AI coding workers propose changes, while separate checks control whether those changes can advance.

In the recorded test, two successful attempts reached the review stage. All seven intended negative attempts produced no acceptance seal or added collection reference. One check rejected a worker’s incorrect claim that its output was clean.

The acceptance test used trusted, scripted fixtures: prepared examples with expected outcomes. The recorded run was captured from 02:47:52 to 02:48:04 UTC on 10 September: seven cases, eight runs, and nine worker attempts.

Selected columns from the acceptance record
Test · setup · attemptTask stateWorking folder checkG-CLEANTest resultG-TEST
T01 · 0002 · a1NEEDS-HUMANPASSNOT-DECLARED
T02 · 0002 · a1PATCHPASSNOT-DECLARED
T03 · 0002 · a1NEEDS-HUMANNOT-RUNNOT-RUN
T04 · 0002 · a1REVIEWPASSPASS
T05 · 0002 · a1PATCHPASSFAIL
T05 · 0002 · a2PATCHPASSFAIL
T06 · 0002 · a1PATCHFAILNOT-RUN
T07 · 0002 · a1NEEDS-HUMANPASSREFUSED
T04 · 0022 · a1REVIEWPASSPASS

Reading the results: each row identifies the test, its setup (the recorded mask value), and the attempt. The working folder check (G-CLEAN) checks whether the working tree is clean; G-TEST records the test check.

REVIEW means the attempt reached review; NEEDS-HUMAN calls for human attention. NOT-RUN means a check did not execute, and NOT-DECLARED means no test was declared. A request for unsupported network isolation was recorded as REFUSED.

The practical lesson: test whether a workflow stops on the failures it is meant to catch, as well as whether a passing case can advance.

Redacted from the acceptance record prepared on 10 September. This demonstrates that recorded fixture run, not current deployment status. Real model integration, crash consistency, reviewer execution, and hostile-code isolation remained outside its accepted scope.

CURRENT REVIEW / 1 OCTOBER 2026

A correction still needs adoption.

The latest Prompt OS document review found conflicting instructions about which return-validator check comes first. A correction proposal is prepared, but has not been adopted. That review did not run the deployed validator, and the matching raw result for the original research packet is still missing.

A separate AEOS wrapper review passed eight focused package checks, including environment isolation, identity refusal, and preservation of earlier evidence. It did not establish fresh installation acceptance or live recovery. The historical table above remains the September 10 fixture result, not a new production run.

The next step is to reconcile the rules with the actual validator and test the exact correction before adoption. A clearer document and a passing package check are progress; neither changes the running system by itself.

Based on the 1 October read-only project review packet and reconciled tracker. No deployed instructions, runtime, installation, or acceptance authority was changed by that review.

Applying the idea to a small workflow.

Start with a task, sample inputs, and a result someone can inspect. Decide which rules software can check, where a person needs to review, and what happens when a check fails.

Related experiment: a local coding model whose output cannot approve itself.

Back to build notes ↑