How to Scope a Governed AI Engagement

This framework is for determining whether a specific AI system problem is reviewable before committing to a review. It extracts the claim under examination, maps the trust boundary around it, and identifies whether the available evidence is sufficient to produce a verifiable finding — or whether the problem needs to be restated first.

When This Framework Applies

• A system has shipped and a stakeholder is asking whether its outputs can be trusted
• A vendor has made governance claims in a contract or architecture document and you need to evaluate whether those claims are checkable
• An AI system is producing decisions with downstream consequences and there is no agreed method for auditing them
• An internal team has completed a compliance review but the findings are not tied to specific system behaviors
• A procurement or legal team needs to know what evidence exists before signing off on an AI deployment
• An incident has occurred and the question is whether the governance layer recorded enough to reconstruct what happened

What Makes a Problem Reviewable

A problem is reviewable when it has a defined system boundary, a specific claim, an evidence artifact (or a clear absence of one), and a question that is answerable with current information. Remove any of those four elements and the problem may be real, but it is not yet reviewable.

Defined system boundary. The review has to be about something specific — a model, an agent pipeline, a governance layer, a decision surface. "AI governance in the organization" is not a boundary. "The approval workflow for the procurement agent in the vendor's deployed stack" is.

A specific claim. The system, the vendor, or the documentation must be asserting something. The claim can be affirmative ("all agent actions are logged") or structural ("the governance layer is independent of execution"). If there is no claim, there is nothing to evaluate against.

An evidence artifact or its documented absence. Evidence does not have to exist for a problem to be reviewable — a well-documented absence of evidence is itself a finding. What cannot be reviewed is a situation where neither evidence nor its absence has been established.

An answerable question. The question has to be resolvable with information that exists or can be requested. "Is this AI system safe?" is not answerable. "Does the signed receipt record include the authorization token at execution time?" is.

Reviewable example: The system documentation states that all agent actions produce a signed execution receipt. A sample of receipts has been provided. The reviewable problem is whether the receipts contain sufficient fields to reconstruct the authorization chain for each action.

Not reviewable (as stated): "We want to understand whether the AI is making fair decisions." This is a real concern but not a reviewable problem until a specific decision surface is identified, the fairness claim is stated explicitly, and there is an artifact (model card, output log, decision record) to evaluate against.

Step 1: State the claim under review

Extract the actual claim before doing anything else. Claims are often embedded in documentation, architecture diagrams, contract schedules, or compliance certifications. Surface them explicitly.

• What is the system asserting it does? (Quote it directly if possible.)
• Where does the claim appear — documentation, contract, diagram, verbal assurance?
• Who made the claim — the vendor, the internal team, the compliance function?
• What would it mean for the claim to be false? What breaks downstream?
• Is the claim about behavior ("actions are logged"), structure ("governance is independent"), or outcome ("the system cannot take unauthorized actions")?

Claims about outcome are the hardest to verify directly. If the claim is outcome-based, identify the structural or behavioral claims it depends on and review those instead.

Step 2: Map the trust boundary

Identify what the system controls, what it delegates, and what it assumes. Every trust gap in this map is a potential gap between the claim and the evidence.

See: Authority Is Not Execution — the distinction between a system that holds authority and the system that executes under it is where most governance claims break down.

See: Delegation Is Not Disappearance — delegating execution to a third-party model or tool does not remove accountability from the delegating system.

Flag every component in the boundary map where the system asserts governance but delegates execution. Those are the high-priority review points.

Step 3: Identify the evidence artifacts

For each claim identified in Step 1, determine what evidence exists and what that evidence can actually prove.

For each artifact:

• Is it independently verifiable, or does verification depend on trusting the same system that produced it?
• Is it current — does it reflect the system as deployed, not as designed?
• Does it cover the specific claim, or is it a general attestation that the claim leans on?

If no artifact exists: document that absence explicitly. "No signed receipts exist for the actions in scope" is a finding, not a gap in the review.

Step 4: Scope the gap

The reviewable problem is the gap between what is claimed and what is verifiable. State it precisely. A well-scoped gap statement has three parts: the claim, the evidence state, and the specific question the review will answer.

Structure:

The system claims [X]. The evidence base is [Y]. The reviewable gap is: [Z].

Worked example:

The system claims all agent actions are governed. The governance layer is documented. No signed execution receipts exist. The reviewable gap is: the claim exceeds the evidence — governance is asserted structurally but there is no artifact that records whether the governance layer was applied at execution time.

Well-scoped gap: "The vendor's architecture diagram shows a policy enforcement layer between the agent and the external API. No execution receipts are available. The gap is: there is no artifact that confirms the policy layer was active during the actions in scope."

Poorly-scoped gap: "We don't know if the AI is really governed." This is not a gap statement — it is a concern. Convert it by identifying the specific claim, the available evidence, and the precise question.

A poorly-scoped gap produces analysis. A well-scoped gap produces a finding.

What a Scoped Engagement Produces

A properly scoped engagement produces a specific set of outputs. Not a report in the abstract — these items:

• The claim under review — stated verbatim or reconstructed from source documentation, with a citation
• The trust boundary map — a list of what the system controls, what it delegates, and what it assumes
• The evidence inventory — each artifact in scope, its type, its currency, and what it can and cannot prove
• The gap statement — the precise distance between the claim and the verifiable evidence, stated as in Step 4
• The finding — a single, bounded conclusion: the claim is supported, the claim exceeds the evidence, or the claim cannot be evaluated with current artifacts
• The residual trust assumption — what the finding still requires the reviewer to take on faith, stated explicitly
• The recommended next step — one specific action: obtain artifact X, restate the claim, or escalate to a different review surface

If an engagement cannot produce all seven of these items, the scope is not complete.

The Principle

A review that cannot be checked is not a review — it is an opinion with formatting. The value of a scoped engagement is that it separates what is verified from what is assumed, and it states both explicitly. An engagement that moves accountability produces a finding that a second reviewer could evaluate independently. An engagement that adds paperwork produces a document that terminates scrutiny instead of enabling it.

See also: How to Review a System for Trust Boundaries — the broader trust-boundary review framework this scoping method feeds into.