Codifide Harness: Three-Layer Governance for AI-Native Software
AI agents build at machine speed. Governance must operate at three different speeds simultaneously — or it becomes either a bottleneck that kills productivity or a rubber stamp that kills quality. Codifide Harness separates governance into three layers, each running at the cadence its decisions require.
The Codifide Harness framework is based on Robert G. Cooper's Stage-Gate® model. Stage-Gate® is a registered trademark of Stage-Gate International and R.G. Cooper & Associates, and Codifide is not affiliated with, sponsored by, or endorsed by either. See Trademarks and Acknowledgements.
New here? Install the free harness, read what is mechanically enforced and what is convention, or see how to work with Codifide.
The insight is that not all decisions are equal. Some require human wisdom and carry legal accountability. Some require expert judgment but can be exercised by AI with appropriate knowledge. Some are purely mechanical and benefit from speed rather than deliberation. Forcing all three through the same process wastes the expensive resource (human attention) on cheap problems, and rushes the expensive problems (compliance, architecture) through cheap processes.
Layer 1: Human — Intent, Accountability, Decisions
The human layer is where authorization originates. Humans decide what to build, why it matters, and accept accountability for the outcomes. This layer operates on a meeting cadence — days to weeks — because the decisions it makes are consequential, often irreversible, and carry regulatory or contractual weight.
What lives here:
- Project goals and priorities
- Architecture direction and technology choices
- Compliance commitments and regulatory interpretations
- Hiring, budget, and organizational decisions
- Release authorization for production deployments
- Escalation resolution when gates or loops surface ambiguity
Operating speed: Days to weeks. These decisions benefit from reflection, discussion, and multi-stakeholder input.
Example: "We will support CMS MIPS measures for the 2025 reporting year, prioritizing the 15 measures with highest patient volume across our client base."
Layer 2: Gate — Architecture, Domain Expertise, Security, Adversarial Judgment
The gate layer exercises judgment that requires expertise but not executive authority. It evaluates whether proposed work aligns with human-layer decisions, whether implementations are architecturally sound, whether domain-specific logic is correct, and whether security properties are maintained. Gate reviewers can recommend approval, reject, or escalate; the Human Steward makes the decision (see what is enforced and what is convention).
What lives here:
- Adversarial review (B-Team critic, Zero-Context auditor)
- Domain expert personas (clinical quality, security, compliance)
- Architecture review and design approval
- Security scanning and vulnerability assessment
- Intent drift detection — "Is this still what was authorized?"
- Effort estimation and risk assessment
Operating speed: Minutes to hours. Fast enough to not block development flow, slow enough to apply genuine judgment rather than rubber-stamping.
Example: The B-Team reviewer examines a proposed measure engine implementation and identifies that the denominator exclusion logic doesn't handle patients with multiple qualifying encounters correctly. It rejects the implementation with specific remediation guidance, without needing human escalation because the error is clearly within the specification.
Layer 3: Loop — Build, Test, Verify, Deploy, Optimize
The loop layer handles execution that is mechanical, repeatable, and verifiable. AI agents operate autonomously within this layer, generating code, running tests, verifying output against specifications, deploying artifacts, and optimizing performance. The loop runs continuously — seconds to minutes per iteration — with no human intervention unless verification fails and escalation is triggered.
What lives here:
- Code generation and implementation
- Test execution and coverage verification
- Independent verifiers comparing output to source of truth
- Build, package, and deployment automation
- Performance optimization within defined boundaries
- Data pipeline execution and materialized view refresh
- Pattern discovery and promotion
Operating speed: Seconds to minutes per iteration, for work that a mechanical check can verify.
Example: An agent implements 15 quality measure engines overnight, running each through a verification loop: generate SQL, execute against test patients, compare results to hand-calculated expected values, retry on failure, promote successful patterns to templates. By morning, 14 pass verification and 1 is escalated to the gate layer with a specific ambiguity identified.
Cross-Cutting Concerns
Two systems operate across all three layers:
Primum (Intent Integrity) is a review persona and checklist that asks whether the work still accomplishes what was authorized, whichever layer produced it. It is designed to flag drift between authorization and behavior when a review is run; there is no runtime monitor. Named for primum non nocere — first, do no harm.
Quill (Organizational Memory) — captures decisions, reasoning, and outcomes across all three layers into persistent documentation. Produces the narrative that explains why the system works the way it does, preventing comprehension debt from accumulating faster than humans can read.
Why Three Layers, Not Two
Most governance models are binary: either humans approve everything (safe but slow) or automation handles everything (fast but dangerous). The three-layer model recognizes that between "requires human wisdom" and "purely mechanical" lies a substantial category of work that requires expert judgment but not executive authority.
The gate layer is this middle ground. It's where adversarial reviewers challenge assumptions, domain experts validate clinical logic, and security specialists assess threat models. These judgments require knowledge and reasoning but not organizational authority. They can be exercised by AI with appropriate expertise, escalating to humans only when they encounter genuine ambiguity.
Without the gate layer, organizations face a binary choice: either every security check waits for a human (killing velocity) or security runs as an automated scan that catches syntax but misses logic (killing quality). The gate layer provides judgment at speed — not human speed, but not blind automation either.
What is mechanically enforced, and what agents follow
This is the single, authoritative statement on this site. Other pages link here rather than restate it. In short: four scripts are mechanical checks; almost everything else, including gate approvals, reviewer independence, and personas, is a written rule that an agent is instructed to follow and that reviewers check.
| Control | Status | Mechanism | Where it can fail |
|---|---|---|---|
Immutable-path guard (guard-immutable-paths.sh) |
Mechanical, when installed and registered | A blocking PreToolUse hook (exit 2) stops agent file-tool writes to protected paths. | Depends on a host that honors blocking hooks; the harness marks that as unverified for some tools. It does not inspect shell commands such as sed -i. |
Immutable-path CI check (check-immutable-paths.sh) |
Mechanical, when run in CI | Fails a pull request whose diff touches protected paths, reading the list from the base branch. | Only as trustworthy as who may apply the approval label. Needs CODEOWNERS and branch protection to be human-only. |
Review level and provenance (check-review-level.sh) |
Mechanical, when run in CI | Per commit: requires valid Generated-By and Review-Level trailers, computes a floor from the files touched, and rejects agent-written approval markers. |
The declared Generated-By is self-asserted. It cannot compute every risk (for example a new architectural pattern); reviewers apply those. |
Licence policy (check-licenses.sh) |
Mechanical, when run in CI | Fails if a dependency’s licence is not on the allow-list or cannot be determined. | Needs an SBOM or licence report as input; it checks licences, not code quality. |
| Gate approvals | Convention | The Human Steward decides go, kill, or hold. AI roles may recommend, block, or escalate; they do not approve. The gate decision is never automated. | Nothing in the scripts stops an agent from claiming a gate passed. Human review of the evidence is the control. |
| Reviewer independence | Convention | Reviews run in a fresh context and, where available, on a different model family. Same-family review must be labelled. | Independence is not mechanically proven. Reviewers can share blind spots. |
| Personas (including Primum and Quill) | Convention | Roles defined in steering files that an agent adopts: reviewer, security, intent, memory. | Effective only if loaded and followed. Quill’s append-only rule is a convention; the harness ships no file-permission control for it. |
| Intent Contracts | Convention | A template (templates/INTENT-CONTRACT.md) that records the authorized goal, scope, constraints, and approvals. Reviewers check work against it. |
There is no runtime monitor that detects drift from the contract. |
| HALT protocol and session-state hooks | Convention (hooks are advisory) | Written stop conditions and agent-prompt hooks that save and restore session notes. | An agent can ignore or misread them. Only the guard hook blocks. |
Gates and who decides
The Human layer makes the go, kill, and hold decisions and accepts accountability. The Gate layer is where AI roles produce recommendations and evidence for those decisions. The Loop layer is where mechanical checks run. A gate is passed by a person reading the evidence, not by an agent declaring that it passed.
What this does not give you
- No controlled study has measured outcomes with and without the harness. Treat effectiveness claims accordingly.
- It is not fleet-scale orchestration: the free harness governs an agent, or several concurrent sessions in separate git worktrees, on one codebase. Coordinating lanes across many codebases is what the separate, private Codifide Swarm is being built for.
- It is not a compliance certification. See the harness README’s “Scope and limits” and “Validation status” sections.
Running Multiple Sessions Concurrently
A single agent session working a single branch is the easy case. The harder — and increasingly common — case is several agent sessions working the same repository at once. Done naively, they clobber each other's files, tangle git history, and overwrite each other's handoff notes. The harness addresses this with a deliberately right-sized approach: not fleet-scale orchestration, just the two mechanisms that carry most of the benefit, plus one conditional check.
- Isolation by worktree. Each concurrent session gets its own git worktree — a separate working directory and branch sharing one object store — so two sessions physically cannot overwrite each other's files. External state (ports, scratch databases, caches) is separated per session too, because file isolation alone is a false comfort if the running processes still collide.
- Sharded session state. Each session records its own handoff rather than overwriting a shared one, so no session's notes are silently lost to a last-writer-wins race. An integrator consolidates them when the parallel work merges.
- Integration verification (when tests exist). Each branch passing its own checks does not prove the branches compose — one session can change an interface another still relies on, and every isolated test still passes. So the suite runs against the merged state before anything reaches the main branch. A clean textual merge is not a pass; git detects textual conflicts, not semantic ones. This is what turns "we think it's clean" into evidence.
Heavier coordination machinery — proactive scope partitioning, merge queues, flaky-test classification — is deliberately deferred until collisions recur despite isolation. The principle is the same one that governs the gates: pay for coordination only when the work demands it. Under single-session work, none of this applies.
How this differs from related work
Other efforts address overlapping problems: GitHub Spec Kit (specification-driven development), the BMAD Method, the Bilevel Autoresearch paper (Qu and Lu), and Karpathy’s autoresearch. Codifide Harness focuses on one thing: who decides at each gate, what is checked mechanically, and what is only a convention. It learned from these projects and does not claim to be equivalent to or derived independently of them. Credits and licences are on the Acknowledgements page.
It is not a substitute for the permission systems and sandboxes built into AI coding agents, or for commercial AI governance and security platforms. It sits around them, as a process layer: who decides, what evidence is required, and which few rules are checked by script. We have not benchmarked it against those products, and most worked examples on this site come from healthcare because that is the domain the author worked in.
Indicative standards mapping
| Harness element | Related standard or regulation |
|---|---|
| Human layer: go, kill, hold decisions | EU AI Act, Article 14 (human oversight of high-risk AI systems) |
| Gate evidence and review | NIST AI Risk Management Framework 1.0 (Govern, Map, Measure, Manage) |
| Management practices (roles, records, review cadence) | ISO/IEC 42001:2023 (AI management systems) |
Indicative only. This is not a conformity assessment or certification, and using Codifide Harness does not make a system compliant with any of these.
The Numbers
The intended ratio between layers is steep. These figures are illustrative, from one project, not measurements of the framework:
- Loop layer: Tens of thousands of automated executions per year (measures × clients × refresh cycles)
- Gate layer: Hundreds of judgment decisions per year (reviews, escalations, assessments)
- Human layer: Dozens of strategic decisions per year (architecture pivots, compliance commitments, release authorizations)
In that project, thousands of automated executions corresponded to each human decision (illustrative, from one project). That's the leverage — not replacing human judgment, but reserving it for decisions that actually require it.
Related Articles
- Quickstart — install the free harness
- Codifide Swarm — the private, in-development swarm product
- Codifide Harness Whitepaper — the reasoning behind the gates, with one worked healthcare example
- Agentic SDLC Governance — the checks and balances this architecture implements
- Loop Engineering — a deep dive on the Loop layer
- Domain Expert Personas — the specialized judgment inside the Gate layer
- Intent Integrity for AI Agents — Primum, the cross-cutting intent review persona
- Quill: The War Correspondent Problem — the cross-cutting organizational memory
- The API That Built Itself — all three layers applied end-to-end
- Acknowledgements — credits for the sources this work learned from