When I defined A3 fourteen weeks ago, I wrote: "The daemon runs continuously, the Blackboard clears, the codebase converges, and every action is visible." Today all four gates that operationalize that definition are closed. I want to be precise about what that means — and honest about where the evidence is still accumulating.
What A3 Actually Is
A3 is not a version number. It is a state the system either is in or isn't.
I defined it with four gates because "autonomous" is a claim that's easy to make and hard to prove. Each gate closes one dimension of the proof. You can't skip one and still make the claim honestly.
The four gates:
G1 — Loop closure. An autonomous fix lands end-to-end on a real example. Finding detected → proposal created → proposal approved → execution succeeded → re-audit confirms resolution. Not against a toy. Against the live codebase.
G2 — Convergence. Sustained state where the rate of finding resolution exceeds the rate of finding creation. This is what makes "autonomous" mean something rather than describing a system that runs forever without making progress.
G3 — Consequence chain. Every action is traceable. Finding → Proposal → Approval → Execution → File changes → New findings — all six edges materialized as queryable rows. The governor doesn't have to read source code to know what happened. The chain is the answer.
G4 — Governance in .intent/. No enforcement logic, path mappings, or policy thresholds live in src/. All of it lives in .intent/ — human-authored files, read-only to CORE at runtime, never written by autonomous workers. This gate is the reason the governor role is real rather than nominal.
All four are closed.
The One That Took Longest to Get Right
G3 closed first — May 1. G1 was proven during the 79-second self-heal I wrote about last week. G4 closed May 10, after a campaign that moved 32 operational config sections out of hardcoded src/ literals and into governed YAML, touching 113 files.
G2 was the last one, and the most careful.
The structural piece was a circuit-breaker. After N consecutive identical-signature proposal failures, the affected findings are marked DELEGATE and a hazard finding is posted to the Blackboard. What this does: it converts systematic errors — an LLM producing the same wrong output over and over, a rule with no valid automated fix — into governance signals rather than infinite churn. The system doesn't spin. It escalates.
That's the architecture of convergence. The daemon can't get stuck in a loop it can't exit. Every unmappable pattern eventually surfaces as a human decision.
I closed G2 on May 12. Band D — 107 issues, fourteen weeks of engine integrity work — closed the same day.
What the Audit Shows
Current state: core-admin code audit returns PASS, 20 findings.
Fourteen weeks ago, before Band D started, the audit returned findings in the hundreds across namespaces we didn't even have rules for yet. The findings weren't noise — they were governance debt we couldn't see because the instruments weren't built yet.
That's the counterintuitive thing about this kind of system. Adding a rule doesn't fix violations. It makes violations visible. When ADR-031 landed — no hardcoded runtime directory paths — it surfaced 40 pre-existing violations in one run. The audit went from PASS to FAIL. That FAIL was progress.
20 findings at PASS is not a clean codebase. It's a codebase where every remaining finding is known, tracked, and either queued for autonomous remediation or parked as a deliberate human decision. The difference between "has findings" and "has uncontrolled findings" is the entire value proposition.
The Governor Role, Fourteen Weeks In
I am not a programmer. I have not written implementation code during this project.
What I've done: defined constitutional rules, authored ADRs, reviewed proposals that required architectural judgment, held the line on decisions where the system wanted to go one way and the architecture required another. One example: when modularity.class_too_large kept triggering on PathResolver, the autonomous path wanted to split it. The architectural answer was an exclusion in governance config, with a documented removal condition. That decision belongs in .intent/. It takes three lines of YAML, not a code change.
The G4 gate is what makes this possible. When governance lives in src/, changing it requires a programmer. When it lives in .intent/, it requires a governor.
What "Done" Honestly Means
The machinery is complete. The empirical evidence is young.
G2's structural guarantee — the circuit-breaker — is real. What I don't yet have is weeks of daemon logs showing sustained convergence across diverse rule namespaces, under varied load, with a full autonomous approval cycle running. The gate is closed by architecture. The demonstration is still accumulating.
I'll write about that when the logs are there to show. The series has been honest about the distance between "designed to work" and "observed working." This is no different.
What's Next
The system is autonomous. The next question is whether it's legible — to someone who isn't its author.
That's Band E. The outward-facing work: making the consequence chain readable to a stranger, making the governor role demonstrable rather than described, making the case that a regulated-industry team could operate this without understanding the source code.
The 79-second self-heal was the internal proof. The external proof is what comes next.
CORE is a governed software factory, actively built by the method it describes — source on GitHub. If you're building in the governed-AI or regulated-software space and this resonates, comments are open.
Top comments (0)