CHASSIS: MECHANIZING AI OPERATIONS

Chassis moves procedure ownership out of the prompt and gives AI a bounded place inside a deterministic operation.

SUMMARY

Chassis is the deterministic operating frame underneath three FoundryOS operations: Auto, Cure v2 and Cure v3. It moves sequence, prerequisites, evidence requirements, retry budgets, durable state, decision routing and terminal conditions out of prompts and session memory. AI still performs the work that requires diagnosis, synthesis and implementation, but it performs that work inside an operation it does not control.

The strongest proof was AC-05, the final runtime acceptance criterion for the Cure v2 back-half work. One fresh Cure v2 operation completed all 49 gates from §0 through §7, coordinated 21 bounded AI dispatches, recorded 1,747 append-only decision-log entries and reached clean_certified with zero unverified gates. Of those entries, 1,740 were auto-resolved and 7 were elevated internally. None of the seven elevations became a human Cure-gate decision. One separate question reached me because finishing AC-05 required expanding the authorized implementation scope to build missing certify-half substrate. I approved that expansion once, and the operation completed without another question.

The run did not proceed flawlessly. It exposed defects in its own convergence and scorecard machinery, corrected them while preserving the fail-closed conditions and then re-entered convergence until the terminal requirements were genuinely satisfied. A separate CLEAN post-execution audit corroborated the merged implementation and archived trace, and Caliber criterion C192 now guards the structural back half against regression.

This is evidence of one complete governed close, not proof of universal applicability, fully unattended execution or a measured productivity improvement. The result is narrower and more useful: a large AI-assisted operation can keep legal progression, evidence, retries and authority boundaries outside the model, survive failures as explicit states and still reach an honest terminal condition.

Headline evidence

• 49 gates completed from §0 through §7
• 21 bounded AI dispatches
• 1,747 decision-log entries
• 1,740 auto-resolved entries
• 7 internal elevations across 4 fork types
• 0 human Cure-gate decisions
• 1 human project-scope authorization
• 0 unverified gates

clean_certified

• Chassis closed
• CLEAN post-execution audit

The Problem

Before Chassis, my AI development pipeline already had procedures.

It had planning stages, implementation stages, external audits, retry rules, evidence requirements and a close process.

The problem was where that operation lived.

Part of it lived in prompts. Part lived in procedural documents and scripts. The rest lived inside the active model session and in my memory as the operator.

The individual components could work while the lifecycle around them remained fragile. A model could complete an implementation but lose track of the next review. A pipeline could reach substantial progress without carrying the operation to a defensible close.

I still had to determine where the operation was, what came next, whether the prerequisites were satisfied and whether the work was actually complete.

I did not need a larger prompt explaining the workflow.

I needed the workflow to stop depending on memory.

So I built Chassis.

Remove the operation from the prompt

The obvious way to improve a complex AI operation is to improve the prompt.

Add the full procedure. Explain every exception. Repeat the important rules. Warn the model not to skip anything. Add another warning when it skips something anyway.

That approach reaches a limit.

A prompt can describe an operation, but it does not become the operation. It does not automatically provide durable state, legal transitions, persistent retry budgets, concurrency protection or mechanically verified prerequisites.

The more durable answer was the opposite:

Remove the operation from the prompt wherever possible.

Convert every step that can be known, performed or verified mechanically into deterministic code. Put sequence, prerequisites, state transitions, retry limits, evidence requirements and permitted outcomes into executable machinery.

Then introduce AI only where the operation reaches work that genuinely requires interpretation, diagnosis, synthesis or implementation.

That is the governing Chassis principle:

Automate everything deterministic. Constrain everything probabilistic. Elevate only the judgment that cannot be mechanized.

AI may still perform the hardest intellectual work. It can inspect code, connect evidence across files, diagnose defects, compare alternatives and implement repairs.

But it performs that work inside an operation it does not control.

A conventional agent prompt says: here is the goal and procedure; use your judgment and complete it.

A Chassis stage identifies the exact point in the procedure, the verified prerequisites, the required inputs, the valid outcomes and the evidence needed to continue.

After the model acts, Chassis takes control back.

It validates the result, records what happened and determines what is legally allowed to happen next.

The AI is not the operating system. It is a reasoning engine mounted inside one.

What It Is

Chassis divides the operation into three responsibilities.

The consumer profile defines the route:

• stages and dependencies
• valid outcomes
• decision forks
• retry policy
• reasoning contracts
• terminal conditions

Chassis Core supplies the operating frame:

• durable run state
• legal stage progression
• prerequisite and evidence validation
• semantic result normalization
• append-only decision history
• retry accounting
• concurrency claims
• terminal-state protection

AI workers receive bounded reasoning tasks:

• known inputs
• a defined scope
• permitted tools
• required evidence
• a controlled return contract

At the centre is a deterministic reducer. It takes the current state and a validated result, then returns the next legal state.

The reducer does not invent policy.

It applies the policy declared by the profile.

Current stage, evidence, retry consumption, dispatch history, decisions and terminal status live outside the model. A new session can resume the operation without reconstructing it from chat history.

One invocation may span multiple model calls or operator sessions. It remains one operation because the state, history and legal next step persist independently of any one conversation.

Chassis does not make a model session immortal.

It makes the operation independent of that session surviving.

Auto, Cure v2 and Cure v3 use different profiles over the same Chassis Core.

Three consumers over one core

Today, three FoundryOS operations run over Chassis:

• auto drives development plans through implementation, audit and close.
• cure-v2 operates a 49-gate application audit and remediation procedure.
• cure-v3 runs a recurring defect fix-pass.

They use different profiles over the same deterministic operating core.

Auto

Auto was the first Chassis consumer.

Its purpose is to take an approved development plan through implementation, audit, correction, convergence, paperwork and close.

Before Chassis, those mechanisms existed, but the operator still had to join them into one coherent lifecycle.

The Auto Chassis gave the sequence one persistent owner. The operation itself knew where it was, what evidence existed, what had already been attempted and what could legally happen next.

Auto proved the model.

It also exposed a later problem: once I could mechanize the operation, I began mechanizing too much of the orchestration around it.

Cure v2

Cure is the FoundryOS quality operator.

It scopes application surfaces, dispatches specialized investigators, aggregates findings, submits them to a source-grounded auditor, routes confirmed repairs, verifies the result and determines whether an application can be certified honestly.

Cure v2 represents that procedure as 49 executable gates grouped into phases §0 through §7.

Its assembled profile contains:

• 49 ordered gates
• 11 Cure-specific decision forks
• 8 shared Chassis control forks
• 19 active forks in total

Cure v3

Cure v3 demonstrates reuse in a smaller recurring operation.

Its remediation profile has four stages:

Detect -> Dispose -> Dispatch -> Finish

It uses the same durable state, claims, bounded retries, semantic outcomes and terminal handoff as the larger Cure v2 procedure.

Cure v2 shows that Chassis can govern a large directed operation.

Cure v3 shows that the same core can govern a compact recurring loop.

The stage count and business purpose change.

The need for durable state and controlled progression does not.

How It Works

The operator invokes a consumer:

auto
cure-v2
cure-v3

That command does not paste the complete procedure into a model.

The operation already exists.

Chassis loads the profile, validates its structure, determines the next eligible stage, performs everything it can mechanically and narrows the remaining AI work to that point.

Deterministic progression

The current stage and next legal transition are derived from persisted state and the declared consumer profile.

A stage cannot advance because the model remembers seeing a requirement earlier. The required artifact, state or attestation must exist in the form declared by the operation.

Results are normalized into a controlled semantic vocabulary before they reach the transition logic. Open-ended prose and raw process exit codes are not sufficient workflow decisions. A malformed, contradictory or undeclared outcome fails toward visibility rather than silently advancing the run.

Durable operation memory

Current stage, evidence, retry consumption, dispatch history, decisions, claims, handoffs and terminal status are stored outside the model.

A new session can resume the operation without reconstructing it from conversation history.

One invocation does not necessarily mean one model response, one process or one uninterrupted session. Some model actions still require an operator session with access to agent tools, so Chassis can persist a bounded handoff and resume when the required result exists.

The important property is continuity of the operation: one durable history, one declared profile, one state machine and one governing control path.

Retry and recovery

Retry budgets belong to the run rather than the current process or conversation. Starting another session does not create a fresh allowance.

A retry is meaningful only when the failed input can change. Repeating the same action against the same frozen evidence is activity, not recovery.

Meaningful routing decisions are written to an append-only log and tied to the specific fork instance. A later decision point cannot borrow an earlier answer because the labels happen to match.

Ownership and terminal state

Concurrent ownership is protected through an atomic claim. Two sessions cannot both read an unclaimed run and independently declare themselves the operator, and a non-owner cannot safely release another process's claim.

Terminal state is durable. A completed, elevated or otherwise terminal operation cannot silently restart as though nothing happened.

Profiles can also carry monotonic kill switches. Disabling an automated path can move a decision toward waiting or human elevation, but it cannot open a more permissive route.

Chassis controls the run. DO NOT STOP controls the session.

Chassis solved the operation-level problem.

It knows the current gate, the prerequisites, the permitted outcomes and what is legally allowed to happen next.

But some AI work still occurs through an operator session.

That creates a second control problem.

Even when the operation knows what should happen next, the AI operator can still try to end the turn early, wait unnecessarily or turn a recoverable fork into a question for me.

That is the session-level failure addressed in FoundryOS Field Note 01: DO NOT STOP!

The two controls govern different boundaries.

Chassis governs:

• legal progression
• evidence and state
• retries and elevations
• terminal closure

The DO NOT STOP pattern governs the operator session:

• do not end the turn while useful registered work remains
• do not export recoverable judgment to the human
• permit a human question only through a recorded authorization

The controls are coordinated so only one gate owns a given stop or question.

Chassis controls the run.

DO NOT STOP controls the session.

Evidence

What AC-05 means

AC-05, the fifth acceptance criterion in the Cure v2 back-half proof plan, was the final runtime requirement for that work.

The code and tests could prove that the individual mechanisms existed, but AC-05 required something stronger: run a fresh Cure v2 operation through the complete §0-to-§7 lifecycle, reach a clean terminal state, close the Chassis and leave no gate marked unverified.

It mattered because it tested the assembled operation rather than isolated components.

A passing unit test could show that a transition function worked.

AC-05 had to show that the whole system could actually finish.

One operation, 21 bounded AI dispatches

The completed AC-05 proof run used 21 bounded AI dispatches:

• 1 Scoper
• 14 investigators
• 2 Aggregator passes
• 1 Finding Auditor
• 3 fix agents

Chassis owned the sequence, prerequisites, state, evidence rules, phase boundaries and legal progression.

The AI workers performed the reasoning inside those boundaries.

Counting gates against model calls would produce a misleading percentage. A single gate can perform deterministic checks, dispatch an AI task and then mechanically validate the returned evidence.

The defensible split is a division of authority:

Chassis operated the procedure. AI performed the reasoning inside it.

The run completed all 49 gates from §0 through §7 and reached:

terminal_state: clean_certified
scorecard.clean_run: true
chassis.status: closed
unverified_gate_count: 0

It also passed a CLEAN post-execution audit.

One complete Cure v2 proof run progressed through all 49 gates, coordinated 21 bounded AI dispatches and reached clean certification with zero human Cure-gate decisions.

Operation

• 49 ordered gates
• §0→§7 gate progression
• 1,747 decision-log entries
• 1,740 auto-resolved
• 7 elevated
• 0 unverified gates

Bounded AI — 21 dispatches

• 1 Scoper
• 14 investigators
• 2 Aggregator passes
• 1 Finding Auditor
• 3 fix agents

Authority and closure

• 0 human Cure-gate decisions
• 1 human scope authorization
• clean_certified terminal state
• closed chassis
• CLEAN post-execution audit

Note: The one human authorization expanded the implementation scope. It was not a Cure gate decision.

The decision record

The AC-05 run produced 1,747 append-only decision-log entries.

That is the raw operating history, not 1,747 unique human-scale decisions.

Of those entries:

• 1,740 were auto-resolved
• 7 were elevated
• the 7 elevations represented 4 fork types

None of those Cure elevations became a human gate decision.

Elevation meant the deterministic reducer had reached the edge of its direct rules. The AI operator then resolved the recoverable fork under the declared decision policy.

The Stop and Ask controls prevented "elevated" from becoming an automatic instruction to stop and ask me.

One human authority crossing

Cure v2 contains a formal pre-fix fork:

§3 - MERGE_OR_ELEVATE

The matrix elevated it.

But elevation did not mean "ask Dan."

The proposed fixes were isolated, reversible branch changes with no production deployment. The AI operator applied the declared policy, selected the recoverable fix path and continued.

I did not approve §3.

The decision that reached me was different.

The run discovered that completing AC-05 required building a missing profiled certify-half: operating substrate that did not yet exist when the run began.

That changed the authorized scope of the project.

A one-shot escalation was recorded. I was asked whether to build the missing substrate and continue.

I answered:

"Let's do this."

The system resumed and completed §3.6 through §7 without consulting me again.

Seven internal elevations remained inside the governed operation. One authorized question reached Dan when completing AC-05 required expanding the implementation scope.

Two evidence surfaces

The AC-05 work used a disposable local environment so the complete audit could run safely.

But a clone reconstructed from migrations cannot be the only source of truth.

It proves what the repository says production should contain. It cannot prove what production actually contains after partial deployment, operational drift or an out-of-band change.

The run therefore compared two surfaces:

1. A local disposable clone reconstructed from committed migrations.
2. A separate read-only production introspection.

The comparison found real drift that a clone-only audit would have missed.

It also exposed the opposite risk.

Temporary configuration in the clone made one apparent path look reachable when the live production grants did not provide that capability. The Finding Auditor compared the claim against the real authority surface and downgraded it before repair.

The lesson is broader than databases:

A test environment is evidence, not authority.

The clone showed intended state.

Production showed deployed state.

The auditor determined what the difference actually meant.

What Went Wrong

The final result is useful, but the failures encountered on the way explain why the architecture mattered.

When the claim and artifact disagreed

An earlier Cure v2 run produced one of the clearest examples.

At gate §2.5, an investigator returned:

status: complete_with_findings
findings_count: 3
p0_findings_count: 1

The artifact saved to disk contained:

findings: []

The model claimed three findings, including one P0, but persisted none of them.

The integrity gate compared the return claim with the saved artifact and refused to advance the run to aggregation.

The investigator had to be re-dispatched. Only after the three findings were correctly persisted did the operation continue.

The AI said the work was complete.

The evidence said it was not.

Chassis trusted the evidence.

That earlier incident showed that Chassis could refuse a false finish.

AC-05 showed that it could also carry a corrected operation to an honest one.

When the machinery judging completion was wrong

The Finding Auditor confirmed six defects and grouped them into three repair clusters.

Each fix agent worked in an isolated branch worktree with bounded paths, required verification and a structured return contract.

The repairs were not deployed directly to production.

After the fixes, the run found defects in its own certify-half machinery. The convergence calculation and scorecard did not initially represent the verified branch repairs correctly.

That sequence creates an obvious objection: if the run exposed defects in the machinery judging convergence, and the same session corrected that machinery, what stopped the fix from merely teaching the system to pass?

The AI operator made both corrections in-session, but the changes preserved the fail-closed paths.

Convergence removed only findings tied to complete_verified fix manifests and mapped back to the dispatched finding IDs. Unverified, malformed or unmapped work remained open.

The scorecard accepted the in-place dispatch file only when it was the expected schema-2.0 classifier artifact. A missing or wrong-shaped artifact still forced clean_run: false.

The operation then re-entered convergence until the terminal requirements were genuinely satisfied.

A separate post-execution audit reviewed the merged implementation and archived trace, and C192 was added to prevent the structural back half from regressing.

That audit was corroboration, not a fresh independent rerun.

The final result was:

• all 49 gates completed
• zero unverified gates
• clean certification
• durable Chassis closure
• a CLEAN post-execution audit

Caliber, FoundryOS's structural regression system, now carries a permanent criterion, C192, that guards the Cure v2 back half against returning to unverified placeholder gates.

The architecture was not valuable because nothing went wrong.

It was valuable because failures became explicit states with governed consequences.

When mechanization became orchestration

Chassis moved the operation out of prompts and memory.

It did not guarantee that every mechanism added to the operation deserved to remain there.

Auto made that visible.

Historical pre-simplification evidence included:

• approximately 96 real Chassis launches for one plan across three days
• 22 launches for another plan whose authoritative post-execution review was still deferred
• 123 resumptions while driving five plans in one 22-hour session

Re-invocation can be legitimate.

The problem was what many of those invocations represented: the operator repeatedly crossing transport, review, correction, repository and close boundaries that the system had created for itself.

The reducer worked. The handoffs did not.

Two examples captured the problem.

A review-fold gate expected a changed artifact as proof that review findings had been incorporated. A clean review could correctly leave the artifact unchanged, making success mechanically indistinguishable from failure.

A repair loop could also perform work and then re-audit an older frozen implementation pin. That looked like a retry, but the evidence being tested had not changed.

A retry is only real if the failed input can change.

The correction was not to remove deterministic control.

It was to distinguish high-value mechanization from low-value orchestration.

High-value mechanization protects correctness, recoverability or observability.

Low-value orchestration mainly creates another mechanism the operator must operate.

Historical Auto evidence showed that the reducer usually knew what came next while the surrounding handoffs repeatedly required operator intervention.

What Auto removed and retained

The Auto simplification removed transport optimization paths that did not affect correctness, redundant review machinery and gates that routinely required bypasses.

It retained the controls that protected the real operation:

• durable run state
• deterministic progression
• fail-closed validation
• semantic outcomes
• persistent retry budgets
• append-only decisions
• atomic ownership claims
• terminal-state integrity

I did not reduce deterministic control.

I reduced incidental orchestration being treated as meaningful control.

The Auto simplification removed incidental orchestration while preserving the deterministic controls that protected the operation.

What the Evidence Does and Does Not Prove

The AC-05 run is evidence of one successful end-to-end governed close:

• complete §0-through-§7 progression
• zero unverified gates
• clean certification
• durable closure
• a CLEAN post-execution audit
• a permanent structural regression guard

It is also evidence that a large operation can complete with zero human Cure-gate decisions while preserving a human boundary for project-scope expansion.

The evidence is strongest for:

• control ownership
• procedural integrity
• recoverability
• bounded escalation
• failure containment
• honest terminal completion

It does not prove universal applicability.

It does not prove fully unattended execution. The AI operator still bridged several operating seams, and one expansion of implementation scope required human authorization.

It does not establish a measured productivity improvement. The July Auto figures are historical and pre-simplification, and I have not yet measured a clean before-and-after reduction in resumptions, operator interventions or elapsed time.

This was one run, not a statistical benchmark.

The complete proof ran in a local disposable environment, with separate read-only production introspection used to detect drift and correct authority assumptions. That is stronger than relying on a reconstructed clone alone, but it is not the same as running destructive remediation directly against production.

The CLEAN post-execution audit corroborated the merged implementation and archived trace. It was not a fresh independent rerun of the complete §0-to-§7 operation.

Chassis also does not make probabilistic reasoning deterministic.

A model can still diagnose incorrectly, implement the wrong repair or return inadequate evidence.

The framework narrows where probabilistic reasoning is allowed, constrains what it may return and prevents unsupported results from silently controlling the operation.

That is the honest boundary of the claim.

Lessons and Reusable Principles

The FoundryOS implementation is specific, but the design test is portable.

For each part of an AI-assisted operation, ask five questions.

1. Can code perform this?

File checks, ordering, validation, test execution, retry accounting and state transitions should not remain model responsibilities merely because a model can describe them.

2. Can code verify this?

A model saying it completed a step is weaker than an artifact, test result, state transition or deterministic validator proving it.

3. Can the outcomes be constrained?

A closed result vocabulary is easier to route, persist, test and inspect than open-ended prose.

4. What reasoning genuinely remains?

Give AI only the diagnosis, comparison, synthesis or implementation work that cannot be reduced safely.

5. Who should own the consequence?

Some outcomes belong to deterministic code.

Some belong to bounded AI judgment operating inside a declared and reversible authority boundary.

Some require a human because acting would expand scope, create an irreversible external consequence or resolve a genuinely underspecified requirement.

Those boundaries can move over time.

Repeated AI judgment can sometimes become deterministic policy. Repeated human decisions can sometimes become bounded automation.

But elevation should identify a change in authority.

It should not become a synonym for asking someone what to do.

The Chassis Test separates deterministic work, bounded AI reasoning and consequential human authority.

Build the operation, then invoke it

A prompt asks a model to remember what the operation is.

A Chassis invocation starts an operation that already knows what it is.

Field Note 01 addressed the session failure: an AI operator could state that work remained and then end the turn anyway.

Chassis addresses the larger operation failure: sequence, evidence, retries and legal progression cannot live in the session either.

AC-05 is where those controls met.

Chassis knew what had to happen next.

DO NOT STOP ensured the operator either did it, recorded a sanctioned escalation or kept working.

That is the difference between asking AI to follow a 49-step procedure and building a system that can walk AI through one.

The Auto audit added a second lesson.

Not every mechanism placed inside a governed operation deserves to remain there.

Both lessons now shape the system:

Mechanize the operation.

Then audit the machinery.

Code, Evidence and Sources

The companion Chassis package contains a small, runnable reference implementation of the control model described in this article.

The example operation:

1. inspects its input
2. validates prerequisites
3. runs deterministic checks
4. requests one bounded diagnosis
5. validates the returned evidence
6. closes or elevates the operation

The package demonstrates:

• durable state outside the model
• append-only decisions
• persistent retry budgets
• fail-closed result validation
• atomic ownership claims
• terminal-state protection

It also includes production-derived excerpts covering profile validation, stage construction, Cure v2 fork assembly and semantic result handling.

The public extract reports aggregate control evidence without publishing raw transcripts, credentials, customer information or detailed live defect reproduction.

Its purpose is narrower:

Show the mechanism.

Make the core invariants executable.

Provide enough code and evidence for another engineer to inspect, run, test and challenge the idea.

This article explains why I built Chassis.

The package shows what I mean by building the operation first.

Runnable · Verified from the extracted archive

Chassis reference implementation

A complete, self-contained implementation of the architecture described above. Extract it and run node --test — there is nothing to install, and nothing reaches the network.

node --test
npm run demo

↓ Download the package · foundryos-chassis-reference-1.0.1.zip · 153 KB

Completed Cure v2 AC-05 proof

system/cure/docs/plans/2026-06-25-cure-v2-backhalf-f-sweep-c192-proof.md

cure/runs/lens-verify-20260730T214536Z/action-trace.json

system/cure/docs/CUREV2_SUBSTRATE_HANDOFF.md

.postexec-attestations/2026-06-25-cure-v2-backhalf-f-sweep-c192-proof.postexec-clean.json

system/caliber/lib/c192-cure-v2-backhalf-driven.mjs

Two-surface evidence

cure/runs/lens-verify-2surface-20260730T190040Z/operator-evidence/

Earlier claim-versus-artifact incident

cure/runs/lens-20260621T230138Z/CUTOVER_GAP_LEDGER.md

That earlier run is used only for the §2.5 persisted-evidence example. Its incomplete-run statistics are not presented as the AC-05 result.

Historical Auto evidence

scratchpad-auto-report/A-run-forensics.md

auto-pipeline-assessment.html

The approximately 96-launch and 22-launch figures come from the run-forensics report. The 123-resumption figure comes from the separate pipeline assessment.

All Auto figures describe the historical pre-simplification pipeline.

Raw transcripts, credentials, customer information, detailed vulnerability reproduction and the complete private FoundryOS monorepo are not included.

Quick start

Running in about thirty seconds.

Node.js 18 or later. Nothing else, and nothing to install.

01 Extract and run the tests

unzip foundryos-chassis-reference-1.0.1.zip
cd foundryos-chassis-reference
node --test

76 tests, well under a second. There is no install step because there are no dependencies.

02 Watch an operation close

npm run demo

The deterministic stages advance, the run suspends at the stage that needs judgment, and the full decision trail prints — including the suspension and the resumption. No model is called at any point.

03 Watch it refuse a bad answer

npm run demo:reject

The same operation, given a confident conclusion with no citations behind it. It returns to waiting rather than closing, and re-submitting the identical result exhausts the retry budget and elevates — because a retry against an unchanged input cannot recover.

04 Read the evidence

evidence/   49 gates · 51 edges · 11+8=19 forks
excerpts/   9 production modules, byte-for-byte

Every structural number is generated by reading the live production sources, and the generator fails if what it finds no longer matches what this article claims.

About FoundryOS

FoundryOS designs, builds, hosts and maintains custom operational software for businesses whose work has outgrown spreadsheets, disconnected tools and manual coordination.

Strategy, implementation, infrastructure, maintenance and support come from one team.

This is FoundryOS Field Note 02, part of an ongoing series documenting the systems, failures and engineering decisions behind the platform.

Visit foundryos.ca to learn more and read the complete Field Note series.