On this page

Related reading

Blog By Barry

AI code governance starts at the requirement, not the policy.

The audit firms are building their own AI tools this year, and most published policies sit on top of engineering that produces nothing those tools can read.

PwC, Deloitte and EY are all building AI-native audit tooling this year. Internal audit assistants that read implementation trails and flag gaps against the standards those firms already enforce. The pressure has flipped direction. The question in the executive layer used to be whether AI-assisted work would eventually be acceptable to the auditor. It has become whether what your engineers ship this quarter produces the trail the auditor's tools are already expecting to find.

Almost none of the published material on AI governance answers that question. Nearly all of it sits at the policy layer. Guardrails. Acceptable-use documents. Review boards. Risk registers. Model-risk assessments. Useful documents, none of them in contact with the engineering underneath. The policy describes a discipline the code below has not been asked to produce.

The gap

That's what I keep coming back to when I read this material. A policy document that describes what your organisation intends to be true about AI-assisted work is not the same thing as an implementation that produces evidence that it is true. The auditor's tool reads structure. If the structure isn't there, the policy sat above it is a piece of paper on top of nothing.

The teams I have watched over the last year of shipping agentic builds are producing a lot of code and very little of what a governance tool can actually inspect. Pull requests that reference nothing, a Jira ticket if you're lucky. Tests that verify behaviour but do not link back to a stated requirement. Requirements that live in copy in some Confluence page somewhere, if they exist at all. When a bit of AI-assisted work goes wrong, the trace back to what it was meant to do runs into a wall inside three hops. That is the default state today, and it is the default state a policy layer on top does not fix.

The engineering underneath Two side by side panels compare the same governance stack. Both have three horizontal bands: policy at the top with three chips labelled Acceptable use, Review boards and Sign-off; an engineering layer in the middle; and a tests row at the bottom. On the left panel, titled THE GAP, the policy band sits above nothing. Short dashed stubs drop from each policy chip and break off, with a small caption noting no attachment points. The engineering layer below shows three loose scraps of text with no boxes, no identifiers, no order. The tests row shows three loose test names, also floating with no chain up to any requirement. On the right panel, titled THE CHAIN, the same policy chips have anchor dots at their base and continuous burnt orange lines run straight down through the whole panel. Each column passes through a structured requirement block with a stable identifier REQ-001, REQ-002 or REQ-003 and a short description, then through an acceptance criterion chip labelled AC-01, and lands on a test tick labelled T-01 at the bottom. The chain line threads through every element so the trail from policy down to test is visible and unbroken. The left panel is quiet in paper and ink; the right panel is quiet with restrained burnt orange only on the chain lines and acceptance criterion strokes. The engineering underneath Policy floats, or policy attaches The gap. The policy layer sits above unstructured engineering. Requirements have no identifiers, no acceptance criteria, no lines up to policy, no lines down to tests. The auditor asks which test verifies which policy obligation and no answer is available without a week of triage. The gap 01 Policy Acceptable use Review boards Sign-off No attachment points Engineering MFA for admin roles session times out sometimes password reset by email Tests test_admin_login_mfa test_pw_reset test_session_expiry The chain. Three vertical burnt orange lines thread from each policy chip down through a structured requirement block with a stable identifier and short description, then through an acceptance criterion chip, and land on a test tick. The trail is visible top to bottom. The auditor's question has an answer. The chain 02 Policy Acceptable use Review boards Sign-off Engineering REQ-001 Admin MFA REQ-002 Session TTL REQ-003 PW reset AC-01 AC-01 AC-01 Tests T-01 T-01 T-01 The engineering underneath (vertical layout) Two stacked panels compare the same governance stack. Top panel THE GAP shows a policy row of three chips floating above loose engineering scraps and loose test names, with dashed stubs breaking off between them. Bottom panel THE CHAIN shows the same policy row with anchor dots and continuous burnt orange lines threading down through structured requirement blocks REQ-001, REQ-002 and REQ-003, then through acceptance criterion chips AC-01, landing on test ticks T-01. Left panel is quiet paper and ink; right panel adds restrained burnt orange only on the chain lines. The engineering underneath Policy floats, or policy attaches The gap. Policy floats above unstructured engineering and loose test names, with no lines connecting any of them. The trail does not exist. The gap 01 Policy Acceptable use Review boards Sign-off No attachment points Engineering MFA for admin roles session times out password reset by email Tests test_admin_login_mfa test_pw_reset test_session_expiry The chain. Continuous burnt orange lines thread from each policy chip down through structured requirement blocks with stable identifiers, then through acceptance criteria, landing on test ticks. The trail is visible. The chain 02 Policy Acceptable use Review boards Sign-off Engineering REQ-001 Admin MFA REQ-002 Session TTL REQ-003 PW reset AC-01 AC-01 AC-01 Tests T-01 T-01 T-01
Policy layer · Engineering layer · Tests. The chain runs or it doesn't

The frame moves down

The tier the auditor's tools are very likely to read is upstream of the policy. It is the requirement.

A structured requirement, with acceptance criteria written down and a stable ID that survives into the tests and the pull requests, is the audit atom the policy has been reaching for. It is the smallest unit of a build that a machine can inspect and give a straight answer on. Either the requirement exists, is linked, and is verified by something downstream, or it isn't. There is no third state and nowhere to hide.

Traceability isn't a governance chore added on top of the engineering. It is a property of the engineering. Either the ID on the requirement survives into the acceptance criterion, and the acceptance criterion is verified by a test, and the test runs on the commit that ships it, or it doesn't.

That's the question the auditor's tooling is being built to ask. The tool isn't going to deduce a chain that isn't there. It's going to flag the empty space where the chain should have been, and the flag reads the same way to the auditor as it does to you. Nothing here. No requirement, no link, no verification, no defence. That's the finding, and it's the core exit-audit problem: existing tools can raise the flaw; most teams have no structured artefact to fix the flaw against. RCF is what I have spent the last year building to close that. The tool's job is to name the empty space. RCF gives the engineering underneath a structured artefact to fill it with, either before the flag fires or after the fact. Everything sat above it in policy stays aspiration until the fill exists.

What this looks like when it runs

I run a methodology called RCF against every build I do. Last week I finished the full authoring surface end-to-end on the toolchain that supports it. One binary, nine subcommands: initialise a document chain, view it, validate it, create documents, read them, update them, delete them, link them into a chain, and print help. Every one of those commands writes structured JSON that resolves against a published schema. Every commit runs a chain-integrity test that walks the document chain and fails the build if any link is broken.

The working system sits behind the methodology page today rather than in your terminal. What matters for the point I am making is that requirements-as-code has moved from slide to running system for me. I use the tool to author the requirements the tool is built against. If any of it broke I would have caught it. It hasn't.

I am not describing a research direction. I have built and shipped the mechanism I have been arguing for, and it runs on my own live builds every day.

If you sit in a CTO chair

The check is concrete. Pull ten requirements off your current build. Do they have IDs? Do the acceptance criteria under them have IDs? Does anything downstream, the tests, the pull requests, the release notes, reference those IDs? Can a machine walk from a business requirement to the test that proves it and back again? If the answer is no on any of these, the governance document sat above them is not doing the work it claims to do, and the auditor's tools are going to raise that flag before you get to defend it.

I am not saying this to sell tooling. What a machine can read is not up for negotiation. Either the structure is there and an audit tool has something to walk, or it isn't and no amount of policy language above it changes the finding. The direction of pressure has flipped, and the engineering below the policy is what is now on the hook.

Keep the policy layer. It is where the intent gets written down and the accountability gets assigned. But if the requirement layer below it is not structured, the policy layer is decoration. The auditor's tools are not going to read the policy. They are going to read the code.

Requirements-first is the governance

Requirements-first isn't extra process. It is the governance.

The policy layer records what your organisation intended AI-assisted work to look like. The requirement layer is where that intention is either made real or isn't. What the auditor's tools are being built to inspect this year, and next year, is the second one. And what your engineers are producing today, on the agentic builds you already have running, is either compatible with that inspection or it isn't.

The gap between the two is what I have spent the last year building the answer to. More on the methodology at stravica.ai/rcf-methodology.

Barry