Imagine a pilot where a team guide permits dependency A, a central security policy prohibits it, and the AI reviewer reports no violation. A clean review cannot resolve conflicting policy authority.
Before accepting that result, the adoption lead needs to establish whether the guide contains an authorized exception, whether either document is obsolete, and who resolves the disagreement. Until then, do not rely on AI review to enforce or attest to this rule; retain existing controls and require human review. Unresolved AI context does not suspend the underlying security restriction.
More context does not settle authority.
Company knowledge needs an approval chain
Supplying a document makes it available to the reviewer. Approval establishes when the organization is willing to rely on it. A local style guide and a mandatory security restriction carry different authority, even if they arrive through the same context mechanism.
As a supporting example, OpenAI describes Qodo bringing company knowledge and coding standards into Codex to help developers catch P0 issues across repositories before opening a pull request. The approval process below is a governance recommendation, not a claim about product capabilities.
Separate policy approval from tool approval
I would require two explicit approvals before using AI review findings as evidence of policy compliance:
- Policy approval: The relevant authority confirms the source, scope, revision, and exception process. A designated security authority approves a security restriction; a team’s coding-standards owner approves its local conventions.
- Use approval: The engineering leader accountable for adoption approves whether findings are suggestions, evidence for a human reviewer, or inputs to an enforcement workflow.
The person configuring the tool can maintain the context register without having authority to approve every rule in it. Control of the integration should not make a tool administrator the default arbitrator of security-versus-team-policy disputes.
A document author is not automatically its approval authority.
Use a policy-context register
Keep a small register alongside the pilot’s adoption decision.
| Field | What to record |
|---|---|
| Source | Canonical document or rule identifier and its location. Distinguish approved policy from examples, discussions, and historical notes. |
| Scope | Repositories, components, languages, environments, and change types to which the rule applies. |
| Accountable owner | Named person or role responsible for keeping the rule accurate. |
| Approval authority | Person or body authorized to approve the rule and any exceptions. |
| Approved revision | Version, commit, or dated approval record, plus execution evidence linking the review to that revision. |
| Review trigger | Events requiring reconsideration, such as a policy update, ownership change, or newly discovered conflict. |
| Conflict authority | Who decides precedence when applicable sources disagree, including any existing precedence rule. |
| Fallback | If scope, revision, authority, or applicability is unresolved, do not rely on AI review to enforce or attest to this rule; retain existing controls and require human review. |
The register turns “the reviewer knows our standards” into claims someone can inspect, without requiring leaders to inspect every prompt or implementation detail.
Do not silently classify every retrieved document as policy. A migration proposal, an old incident note, and an approved architecture standard can contain similar language while carrying different authority.
Link the dependency decision to the review execution
For dependency A, confirm both sources’ scopes and approved revisions, then check for a documented exception. Do not assume the newer document wins or that a local guide overrides a central restriction. Apply the approved precedence rule; if none exists, send the conflict to the designated policy authority.
Suppose that authority confirms the restriction applies and no exception exists. Assign the team-guide owner to update or withdraw the conflicting guidance. Keep the decision and execution evidence together in one compact record:
Dependency A pilot record
Source: SEC-DEPS, policies/dependencies.md
Conflicting source: TEAM-DEPS@r3, team/dependencies.md
Scope: dependency additions and updates in pilot-service
Owner: security policy owner
Approval and conflict authority: designated security authority
Approved revision: SEC-DEPS@r7
Recorded authority decision: restriction applies; no exception
Review trigger: either source changes, ownership changes, or new conflict
Fallback: do not rely on AI review to enforce or attest to this rule;
retain existing controls and require human review
Execution evidence, captured by the review runner:
Run: <execution identifier>
Change: <reviewed commit>
Approved artifact: SEC-DEPS@r7
Approved artifact digest: <digest from approval record>
Context submitted for this run: <retained context artifact>
Submitted artifact digest: <digest matching approved artifact>
Authority decision: <link to recorded decision>
Superseded guidance: TEAM-DEPS@r3
Finding: <result linked to this execution identifier>
The execution portion must come from captured review inputs and logs, not someone copying the intended revision into a form. Check that the submitted artifact’s digest matches the approved artifact and that the finding belongs to that execution. If the system transforms or extracts context, preserve the submitted material and its link to the approved source.
A manually entered revision alone is insufficient. Without execution evidence, keep the result advisory and use designated human review for the rule.
Until the conflict is resolved, the reviewer can still offer other advisory observations. Its silence on dependency A is not evidence that the dependency is allowed.
Decide what the pilot is allowed to do
Approved authority and verified context establish which rule was supplied, not whether the reviewer correctly interpreted it or examined every relevant change. Validate detection accuracy and coverage separately before considering enforcement.
| Context condition | Recommended use | Required boundary |
|---|---|---|
| Sources have owners, approved revisions, clear scope, resolved precedence, and verified execution context; detection and coverage are validated for that scope | Consider policy-enforcement use within the validated scope | Preserve required human approvals and the evidence connecting each review to its applicable context. |
| Some context is missing, but gaps can be disclosed | Allow advisory use | Present findings as suggestions; absence of findings is not compliance evidence. |
| Applicable sources conflict or lack an approval authority | Do not rely on AI review to enforce or attest to this rule; retain existing controls and require human review | Have the designated authority resolve the conflict. The underlying security restriction remains in force. |
| The applicable rule or reviewed revision cannot be established for a change | Do not rely on AI review to enforce or attest to this rule; retain existing controls and require human review | Give the human reviewer the unresolved question and relevant sources, rather than only the AI verdict. |
Try one rule before approving the policy set
Spend five minutes selecting one consequential rule from a pilot repository. Record its source, scope, owner, approval authority, and approved revision. Find the execution evidence that would connect a review result to that revision.
Then run a tabletop test: introduce a conflicting team note in the exercise, without editing live approved policy, and identify who would decide which instruction applies.
If the answer depends on an undocumented assumption, keep AI findings advisory for that rule, retain existing controls, and require human review until authority is recorded. This exercise checks whether the approval chain is usable; it is not an enforcement-readiness test.