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

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 gapCopy link

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 frame moves downCopy link

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 runsCopy link

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 chairCopy link

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 governanceCopy link

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.