AI Coding Governance

When a team permits AI-assisted changes, it needs an explicit answer to the engineering-lead question “how do we control this change?”: a declared rule, controls, evidence, and a named decision owner.

These figures were checked against Sonar’s survey materials on 17 July 2026. They describe its respondent sample and should not be read as universal adoption telemetry, an audit result, or proof that a governance workflow works. Separately, the EU AI Act defines duties by actor, system, and use; Article 4 addresses AI literacy for providers and deployers. Whether those or other duties apply is a legal assessment. A workflow record may be evidence for that assessment, but it is not a compliance determination.

A useful governance model keeps six different things explicit:

• Policy - which tools are sanctioned, for which code, with which data. This states the rule; it does not enforce it.
• Decision right - who may accept a technical change, approve an exception, or authorize a release, and where business or legal approval remains separate.
• Control - a mechanism such as a task boundary, branch rule, required check, or human gate that applies part of the policy. What such a gate looks like once it is built rather than written down is documented under protected files and stale approvals.
• Verification per change - the verification loop: a bounded comparison with declared intent plus selected checks. A pass says what those checks observed; it does not prove the change correct, secure, or approved for every purpose.
• Evidence artifact - reports that record inputs, commands, results, omissions, and decisions. A record is reviewable evidence, not a guarantee about its subject.
• Data control - knowing what leaves your environment, per tool. Local-first setups can make governance state and configured data paths easier to inspect. Teams still need to verify tool, model, network, and runtime behavior.

“One page, not forty” is meant literally - a working policy fits on a screen:

Tools:       Claude Code, Cursor (sanctioned) · others: ask first
Scope:       all repositories except infra/secrets/*
Data:        model APIs under company agreements only ·
             no source uploads to unsanctioned services

Per task:    goal + boundaries written BEFORE the run
Per change:  validation the model did not author (tests/types/build)
Per run:     evidence report stored with the code

Gate:        named code owner accepts or rejects the technical change
             · business/legal approvals stay separate · no auto-commit
Review:      this policy is revisited quarterly · owner: eng lead

1. Start with one team, one workflow. Written tasks and a named technical decision owner make the rule and decision right explicit; they do not guarantee decision quality.
2. Make evidence automatic. Capture command results and decisions in the workflow, then review whether the record is complete and relevant. Automation does not make an artifact accurate by itself.
3. Review the record monthly. Skipped validations, boundary findings, exceptions, and reviewer decisions are inputs for policy review, not proof of effectiveness.
4. Scale by adoption, not decree. Expand only after observing the first team’s workflow cost, evidence quality, missed cases, and decision clarity.

Reality Graph is designed to record task boundaries, validation results, and reviewable evidence with an explicit human gate. Its records support a decision; they do not make the decision or prove correctness, security, compliance, or approval quality. It is in private beta; talk to the founder or request early access.