Building the six-layer operating harness

The structure around the work

The local reference package combines a work contract, context routing, a permission gateway, state and receipt contracts, verification rules, and recovery. These six layers organize the implementation. They are not six employees, six deployed services, or evidence that the whole studio runs unattended.

A work order names the objective, source material, owner, acceptance checks, action class, and exact candidate. The context map points the task toward relevant records. A very capable builder with the wrong source can produce a beautifully finished answer to the wrong question.

Permission and progress need their own records

The gateway treats unknown action classes as a hold. A local write needs a resolved scope and allowed path. External actions carry their own authority requirements. Calling something the ‘next logical step’ should not quietly turn permission to draft into permission to publish or send.

State has to outlive the conversation for restart-safe operation to be a credible claim. The package specifies versioned records, idempotency, and transactional persistence requirements. It does not pretend that writing those requirements created durable storage. The restart replay remains a test to perform against a connected runtime.

Let the checker disagree with the builder

The reference checks reject self-review, a changed candidate digest, missing acceptance evidence, and failed evidence. The point is to stop a successful test of yesterday’s candidate from becoming a receipt for today’s changed one.

The evidence ladder also limits the language. Proposed, observed, built, independently verified, externally verified, and measured are different claim levels. A task to produce a draft can finish with a checked draft. A task to publish needs external readback. A claim about business impact needs outcome evidence. There is no automatic escalator between them.

Recovery is part of the design

Transient reads get bounded retries. Explicit denials and ambiguous writes do not simply repeat. Unknown failures hold. Recurring failures should produce a smaller reproduction and a better check, not a longer loop of increasingly hopeful attempts.

The September 29 local verification checked reference paths, role and process links, permission behavior, candidate verification, and retry limits. It did not prove authenticated production dispatch, transactional persistence, backup restore, or a fault-injected restart. A weekday schedule was separately recorded as active; that did not prove a successful unattended run.

The next useful proof is one synthetic job through the full loop, including interruption and replay, followed by one authorized real job. Small is a feature here. A system that can explain one completed job is a better foundation than a diagram promising fifty.