Trustworthy velocity
Merge agent output at agent speed, because green means correct: every rule is bound to something that can fail — a test that goes red, a hook that denies the action, a gate that blocks the merge.
Governance framework Agentic software development
Ship agent work faster.
Prove it was correct.
Aitia Code is a governance framework for large-scale agentic software development: an enforcement layer that installs as a Claude plug-in and makes a green build mean correct again.
- requirementmerged before implementation starts
- decisionnumbered record, dated, with a named test
- claimtyped identifier derived from the record
- guarda rule bound to a test that can fail
- reviewlocal, pre-PR, weighted by what the paths can break
- mergeacceptance evidence lands on the merge
An agentic codebase is opaque by default. The reasoning that produced any given change is buried under the volume of generated code around it, the requirements it answered drift as the code moves, and the judgement calls that shaped it live in chat transcripts nobody will reopen.
Six months on, the people accountable for the system cannot answer the questions an owner, an auditor, or the next engineer will ask of it.
Questions Aitia Code answers on demand
- What requirement was this code meant to satisfy?
- Where is the proof it was correct?
- Where is the proof that the proof itself is correct?
- What decision is behind this code?
- How do I know the feature is fully implemented, not just merged?
Provable cause
Every change retains its exact causes and its proofs — the specification or decision that caused the work, the identifier derived from that record, and the verification that proved it — walkable from numbered requirement to merge with no vendor database.
Controlled adoption
No lock-in by construction: it arrives as a Claude plug-in, and what it writes into a repository — where you choose to have it write anything — is version-controlled files you own. Leaving is uninstalling the plug-in and deleting those files. Two recorded arrangements keep a repository unwritten entirely.
What breaks without it
Agents now write code faster than a conventional review can judge it, and the first thing to break is the meaning of a passing build.
A rule written into prose instructions is read once and drifts as the code moves under it; orchestration without governance scales the defect rate with the fleet. Speed was never the scarce resource. Trustworthy judgement about what was produced is.
Seven failure classes, each with the published figure that measured it — or a label saying none has — and what holds it here.
-
1Spend on work that never lands
What breaks: Developers’ leading frustration with AI output is “almost right, but not quite” — 66% of respondents, with 45% losing significant time debugging it — and one published month-long agent trial landed 3 of 20 tasks, salvage dominating its cost.123
What holds it here: Nothing large starts before its requirement is merged, work is sized to fill one assignment so a wrong direction costs a turn rather than a wave, and ambiguity escalates to the owner instead of being guessed at.
-
2Green stops meaning correct
What breaks: Strengthening SWE-bench’s tests invalidated “passing” patches behind 40.9% of Lite and 24.4% of Verified entries, and the gap between visible and held-out tests widens about 28 percentage points per tenfold increase in code size.456
What holds it here: Every enforcement test must itself be shown able to fail — break the rule it enforces and the test goes red — and completion is the verification output the change’s risk level requires, read in full.
-
3Requirements drift Named, not yet measured
What breaks: Specification drift is now classified as a first-class agent misbehaviour, though divergence under sustained agentic development remains essentially unmeasured.78
What holds it here: Verification failures return to the implementation, never to the specification — rewriting a requirement to match the code is how a specification stops being a gate — and a decision that changes what a feature must do amends its specification before the code lands.
-
4Untraceable work Self-apparent
What breaks: Operational typology rather than a research finding, and it needs no study: if a change cannot name the requirement it satisfies, nothing downstream distinguishes delivered from abandoned.
What holds it here: Every change claims a typed identifier derived from the record that carries it, and a shared check refuses a claim whose supporting evidence is absent.
-
5Unrecorded decisions
What breaks: The provenance and accountability literature observes that agent-facing summaries abbreviate or obscure the agent’s actual decision-making, but no study measures how fast decision-recoverability decays.9
What holds it here: A policy question answered during review becomes a numbered decision record — a dated file stating why a rule exists — with a named test, kept in the repository rather than in a thread.
-
6Concurrent agents colliding
What breaks: A taxonomy over more than 1,600 conversation traces found multi-agent failure to be mostly system design rather than model capability, and isolate-then-merge defers conflict rather than solving it.1011
What holds it here: One issue means one branch, one isolated working copy and one pull request, with file ownership assigned explicitly and hooks denying the crossings.
-
7Senior review attention rationed by the wrong thing Self-apparent
What breaks: The scarce resource is senior reviewer attention, and today it is rationed by diff size and the hour of the day rather than by what the change can break.
What holds it here: Review weight is computed from the changed paths by a classifier in code, re-derived per change, and is the highest weight any changed path earns.
Survey work finds AI adoption raising delivery throughput and delivery instability together.12 That is the bill without an enforcement layer: green builds you re-verify by hand, drift met at integration when it is expensive, spend on work that never lands, and a review bottleneck that returns the moment you add agents. None of it arrives labelled as a defect you can point at.
How it works
The product is named for what it retains: aitia, Greek for the cause.
- Cause
- Aitia Code tracks the exact causes of generated code and of the tests that proved it — the specification or decision that caused the work, the implementation that answered it, the verification that proved it — and retains the proof points along the way.
- Claim
- Requirements merge before implementation starts, and every change claims an identifier derived from the record that caused it. A shared check refuses a claim whose evidence is absent — at claim, at local verification, and at merge readiness — so a feature counts as implemented when its requirement’s checks pass, not when its code merges.
- Guards
- The rules are guards — rules enforced by tests that can fail — and each guard is held to its own standard: a proof must break the rule it enforces and show the test catch it, or review blocks the change. A guard that cannot fail is precisely the defect the layer exists to prevent.
- Review
- Review runs locally, before the pull request opens. It reads the tree rather than the author’s summary — the artifact most likely to be confidently wrong — is asked for findings rather than approval, and its weight follows what the changed paths can break.
- Inheritance
- The enforcement files an adopter inherits carry the framework repository’s heaviest review weight, human review mandatory, because a defect in them is copied into every adopting repository wearing the authority of a safety mechanism.
- Records
- Authority sits in records, not prose: requirements, decisions and task state are files under version control, byte-pinned copies of ingested sources sit beside them, acceptance evidence lands on the merge, and the failure log is append-only. A clone carries the work graph, the rationale and the evidence together — no chat log, database or wiki needed to reconstruct how the tree reached its state. Review verdicts are retained in a ledger of their own, a limit stated below.
The shape
Four kinds of material, measured on the tree on 2026-09-03 and rounded. Re-derive any of them with find and wc rather than trusting them.
Guards
76decision modules
≈ 25,000 lines of plain ECMAScript
The enforcement itself: each one a rule bound to something that can fail.
Tests
104klines
≈ 160 test files · about two thirds of all code
The proof of the guards. Most of the codebase is the verification of the rest of it; in a layer whose product is enforcement, that ratio is the offering.
Skills & tooling
30skills
≈ 10,000 lines of instruction · 34 CLI tools ≈ 20,000 lines · 16 hook adapters
The workflow surface an agent session actually uses, mirrored across both harness surfaces and the plug-in. Hooks intercept actions rather than requesting compliance.
Records
62decision records
15 specifications · ≈ 29,000 lines of Markdown
The durable memory, which also carries the manuals, the process log, and the byte-pinned provenance of everything vendored in.
Two of those facts belong in front of a risk committee. The manifest declares no runtime or development dependency at all — no third-party supply chain to audit, pin, or patch on a disclosure; plain ECMAScript on the platform’s own test runner, no build step, so what is reviewed is what runs. And the test share above means a green run is most of the repository exercising the rest.
Rollout in three steps
-
Install your repository owner
Add the Claude plug-in; its installer writes the enforcement layer into one repository as files under version control, gated by the framework’s own verification in your tree, and asks where records will live before it writes anything.
-
Verify any engineer
Run the framework’s verification gate in your tree. Value is first visible here: the gates now judge every change, and the run’s duration is in its own output.
-
Calibrate your engineering leads
Adjust review weights and rules to your risk profile; the framework repository applies the process to itself and is the working reference implementation to measure against.
One consequence is worth hearing at the outset: in an adopting repository the weighting inverts, your business code becoming the heaviest review tier while the inherited enforcement files sit below it. The framework is deliberately not the most important thing in the repositories that use it.
What an auditor gets
No certification is claimed or implied. The mechanisms produce the evidence a change-management audit asks for.
- An append-only trail of process deviations, each row carrying a severity and a disposition.
- Provenance from numbered requirement to merge.
- Per-change review evidence scaled to what the change can break.
- Decisions as numbered records in version control.
Nothing to export and no vendor database — the audit trail travels inside the clone.
What we will not claim
Read this before the sales call you will not get.
We break it too. The register that ships in the clone — an append-only log of our own process failures — carries changes merged with one review pass where two were owed; a green host status accepted in place of an approved verdict; a rule enforced in CI resting on a decision record nobody had approved; and an agent session whose report described a proof its committed diff did not contain. Several rows were written by the session that caused them.
Nothing proves a review happened. Review is local and pre-PR, and the host refuses a review submitted by the pull request’s author, so on a self-authored pull request that field cannot carry the verdict at all; the verdict lives in a ledger version control does not carry, and the control on review occurring at all is the owner sampling merges, not a guard.
One project, a related party. The field evidence comes from one large production project inside the author’s own organisation — one project and a related party, not a market. It ran its own verification campaign against released trees and returned measured defects; each finding is kept as a byte-pinned copy, the changelog records its disposition by release, and some remain open.
Where research is silent, the ledger says so. Two classes carry the label “self-apparent” and one “named, not yet measured” instead of a borrowed figure, and one figure in the sources could not be paired to a publication and is flagged there.
What this costs you, and how you leave
- When a rule is wrong
- A false red does not strand you: guards are repository-local files you own and amend under the same discipline, and a blocking question escalates to your owner as a recorded decision, not a vendor queue. The register carries a shipped test that reddened every adopter tree, with its disposition.
- What adoption costs
- Enforcement runs on the platform’s runtime, so no new infrastructure. The weight you feel is the review discipline itself: the product, not overhead around it.
- How you leave
- The plug-in uninstalls like any other, and everything installed into your repository is files under version control, so leaving is deleting files you own. Records and history stay readable Markdown: nothing to export, no service, no data held elsewhere.
- Or never commit to it at all
- Two zero-residue arrangements are recorded for adopters who will not have the worked-in repository written to: records kept in a records repository designated for the module, the worked-in repository receiving nothing; or records kept as Confluence pages, the repository receiving a repo-level setup file and no record copies. The install flow asks which arrangement applies where the setup file declares none, writes nothing without an explicit confirmation, and refuses rather than guessing when a declaration is broken. Tree mode — records beside the code — is what an adopter installs today; both zero-residue arrangements are approved decision records whose implementation is still open.
- Will it fit your topology?
- Review weight, the file fences that keep parallel agents apart, and ownership of each assigned unit of work are already decided per path rather than per repository: the review classifier reads each changed path and takes the highest weight any of them earns, and parallel work is fenced by path, so weighting and fencing inside one tree is the normal case rather than a special one. What still assumes a single repository is the artifact layout — today’s install owns the repository it is installed into, and one install serving a large mono-repo, with records designated per module at the build boundaries that repository already declares, is an approved decision record whose implementation is open.
- Releases to date, and open to contribution
- Dated release entries run through 2026-08-30. A licensee may fork and modify the framework within the scope of its agreement, and licensees are encouraged to contribute non-proprietary enhancements upstream rather than carry private forks, so a correction to a shared fixture reaches every adopter of it; acceptance is never promised. Contribution is a signed-off licence grant and not an assignment: contributors keep ownership of what they write, and your own specifications, decision records, task rows and business logic sit outside that grant entirely — the license grants no right in them.
Two ways to start
Alone, with the reference implementation
The framework repository applies the process to itself; its README calls it both the distribution and a working reference implementation. Run npm run check against it — the same gate every change there passes, on a tree with nothing to install first.
In conversation
Aitia Code is proprietary; no license is granted by access alone, and adoption runs under a separate written license agreement with the copyright holder. Start that conversation when the reference implementation has earned it.
Start the conversationSources
Published figures are the cited work’s own reported numbers, to be verified against these primary sources before reuse.
- Stack Overflow 2025 developer survey.
- Answer.AI, a month with Devin — practitioner-published.
- METR’s randomised controlled trial, arXiv:2507.09089, cited for its design and direction only: its own authors’ later uplift update supersedes the headline figure with a wide range it calls weak evidence.
- UTBoost, arXiv:2506.09289.
- SpecBench, arXiv:2605.21384.
- Test smells in generated suites, arXiv:2410.10628 (TOSEM), over 20,500 generated suites: generated tests carry pervasive assertion smells.
- Specification-drift classification, arXiv:2602.17037.
- Drift-enforced spec-code coupling, arXiv:2606.27045.
- Agent provenance, arXiv:2608.02329, and accountability, arXiv:2605.11027 — position papers, no failure-rate data.
- MAST, arXiv:2503.13657.
- Concurrency-control position paper, arXiv:2608.18092, which states that it lacks empirical validation.
- DORA 2025 — survey scale, vendor-published.
One figure is recorded here rather than argued from, because no publication identifier could be paired to it: a mutation-based evaluation of 22,374 test-generation tasks reported that over 99% of generated tests which failed on mutated code passed on the original program. Locate the primary source before reusing it.