The question before the prompt

An AI assistant can produce a polished brief from a folder of documents, a web search, a meeting transcript or a client email. It can also produce a neat list of citations.

Neither fact tells you whether the work was responsible.

The first question is not: “Can the model find sources for this answer?”

It is: What is this system allowed to know, use and retain for this particular task?

That question sits before prompting. It requires an organisation to make deliberate choices about data, evidence and accountability — choices that are often left implicit when a team starts experimenting with AI.

This is where a practical Trusted AI approach begins. Trust is not a property of a model’s answer. It is a property of the evidence policy, control boundary and review practice around the work.

PathPatron calls this the Evidence Route: a visible route from permitted input, to appropriate source, to a named human decision. It makes the same Compass move as the One-Page AI Briefing and the Data Boundary Protocol: clarify the people who own the decision, put the check into the process where work happens, and give people a usable tool or instruction rather than a vague warning.

Grounding is only half the job

Grounding prompts are useful. They ask a model to work from named material, distinguish facts from assumptions and expose claims that still need checking. That makes an answer more reviewable.

But source grounding alone does not answer a more basic question: should the material have entered this AI system at all?

An organisation may have an internal policy, a legal obligation, a client commitment or a contractual restriction that changes the answer. A customer’s confidential strategy document, an employee record, a commercially sensitive pricing model or a dataset containing personal information cannot simply be treated as “helpful context.” The relevant decision is not only whether the output is accurate. It is whether the input is permitted, under what conditions and in which tool.

The same applies to external evidence. A company may pay for respected research, industry data or specialist legal and technical services, yet staff may ask a general-purpose AI tool to rely on whatever it finds on the open web. That is not an AI capability problem. It is an evidence-governance problem.

The invoice-automation decision: a route we can follow

Consider the same accounts-payable team that has already mapped what may enter an AI tool. Their finance director now asks a more consequential question: Should we invest in AI-supported invoice-exception handling this quarter?

A weak request is easy: “Research invoice automation tools, estimate the savings and recommend the best option.” A fluent assistant will happily return a business case: vendor claims, generic benchmarks and a confident recommendation. The problem is not that it has no citations. The problem is that it may have turned marketing claims and a guessed internal baseline into a leadership number.

The PathPatron Evidence Route changes the task. The team first decides that live invoices and bank details remain out of scope under the Data Boundary Protocol. They allow a redacted process map, approved internal volume and exception-rate figures, the company’s existing security requirements, its licensed analyst research, official regulatory guidance where relevant, and current vendor security documentation. The finance-operations lead owns the internal baseline; procurement checks commercial claims; security reviews the tool conditions; the finance director owns the investment decision.

The output is no longer “the best tool.” It is a decision brief that separates confirmed internal facts, supplier claims, independent evidence, open questions and a recommendation for a scoped discovery or pilot. The scenario will return throughout this article, because it shows the difference between asking AI to research and building a route for evidence to support a decision.

Start with an evidence boundary

An evidence boundary is a simple, practical rule set for a given use case. It clarifies what may enter a system, what may enter only under stated controls and what must stay out.

There is no universal list. The boundary needs to reflect three things:

the organisation’s own policy and risk appetite;
applicable legal and regulatory requirements; and
contractual or client obligations.

For a low-risk internal brainstorming task, approved public material and non-sensitive internal context may be appropriate. For a client proposal, HR decision, regulated process or vendor selection, the boundary will usually be narrower and the review stronger.

The useful question for a team is not “Is this data confidential?” in the abstract. It is: May this category of data be put into this specific AI system, for this purpose, with these settings and controls?

That forces the right follow-up questions. Where is it processed? Are prompts, attachments or outputs retained? Who can access them? Are they used for model improvement or exposed to subprocessors? Can the system retrieve more data or trigger an action elsewhere?

Those are leadership decisions about control, not details to hide in a tool’s terms of service.

Start with data categories — then make the route reusable

Teams do not need to solve this question from scratch every time someone opens an AI tool. For recurring work, the practical starting point is to map the data categories that actually appear in that workflow — for example, public material, internal working information, client-confidential content, personal data or restricted records — and agree the approved route for each.

The companion Data Boundary Protocol shows how to build on an organisation’s existing classification scheme and turn it into a reusable Data Boundary Card: a named owner, an allowed purpose, an approved tool route and an exception path. It separates the one-off set-up work from the quick daily check before someone pastes or uploads material.

That distinction matters. An evidence policy defines the standard for the material and claims; a data-boundary protocol makes the input decision repeatable at the point of use. One asks, what quality and verification does this evidence need? The other asks, may this material enter this system at all?

Know your evidence estate — before the assistant searches

Before asking AI to research or write, an organisation should know what evidence it already has and which sources it trusts.

This does not need to start as a vast knowledge-management programme. For a recurring workflow, a usable evidence estate may be a short approved-source register:

internal policies, signed-off process maps, decision records and approved data;
licensed research, data subscriptions and specialist services the organisation is already entitled to use;
primary external sources such as regulators, standards bodies, original research and source organisations;
credible secondary analysis that has named authors, traceable references and a clear editorial or research standard; and
material that is useful for exploration but must never be presented as established fact.

This is not about pretending every source has equal authority. It is about making the hierarchy explicit before a fluent model blurs the differences.

For the invoice-automation decision, the evidence estate may include the signed-off invoice-exception baseline, a current process map, the existing supplier-risk standard, a paid analyst report, the vendors’ current documentation and an independent source on relevant legal requirements. A vendor case study can explain a claimed capability. It cannot, by itself, prove the saving the company will achieve.

An external source can be current, interesting and still be unsuitable for a high-stakes claim. An opinion piece, a vendor blog, an AI-generated reposting site and an original regulator publication do not carry the same evidential weight. Geography can matter too: a source may be authoritative for a US market question but not for a European regulatory or operational decision.

Define what “good evidence” means for this decision

The right quality standard depends on the decision. It should be chosen deliberately, rather than inferred from the first search result.

A practical source-quality standard can ask:

Origin: Is this primary material, original reporting, accredited analysis, vendor marketing, commentary or reposted content?
Traceability: Can a reader reach the original source and see what it actually says?
Freshness: Is it current enough for this decision? Has a regulation, market condition or product changed since publication?
Relevance: Does it apply to this geography, sector, customer group and use case?
Independence: Is there a commercial, political or institutional interest that should be made visible?
Completeness: What important perspective, source type or counter-evidence may be missing?

The point is not to create an approved list of news brands. A respected broadcaster can be useful for context, but not necessarily the final authority for a legal claim. A specialist trade publication may be valuable for operational insight, but should not silently become a primary source. The standard must match the claim being made.

In the running example, a vendor’s published ROI number can be recorded as a supplier claim. The team’s own exception-rate data can support a baseline. A licensed benchmark may help set a range, while the proposed pilot is what tests whether the range is plausible in this organisation. The Evidence Route protects the finance director from a familiar failure: treating a promotional number as a forecast.

Verification needs a level and an owner

“A human will review it” is not yet a process.

Which human? Review what? To what standard? And how thoroughly?

Verification should be proportionate to the consequence of getting the claim wrong. A low-stakes internal research note may need a spot check of the most important assertions. A board brief, client deliverable, regulated statement, procurement decision or financial claim may require every material number and factual assertion to be checked against its source.

A useful operating model separates four roles, even if one person plays more than one of them:

the author, who prepares the AI-assisted output;
the evidence owner, who knows whether the internal material is current and authorised;
the reviewer, who checks the cited source, claim and interpretation; and
the accountable decision owner, who accepts the output for the next action.

This is not bureaucracy for its own sake. It prevents a very common failure: an AI draft becomes a decision document because everyone assumes someone else has checked it.

For the invoice-automation brief, the team might spot-check a low-stakes market-context paragraph, but verify every material internal number, supplier security claim and ROI assumption. That is a PathPatron People decision: clarity on who knows the evidence, who interprets it, and who accepts the consequence of acting on it.

Keep the evidence trail with the output

For consequential work, the source material should not disappear once the document is written. Keep the evidence trail with the output: source, claim, date, confidence or limitation, reviewer and unresolved question.

That makes the work inspectable later. It also turns recurring errors into useful signals. If the same source is repeatedly outdated, unavailable or misunderstood, the fix may be a new source subscription, a clearer policy, a better internal repository or a different workflow — not a longer prompt.

That broader portfolio view is the future PathPatron AI Control Map: a way to decide how much control a use case needs across data sensitivity, action authority, evidence standard, external dependency and human oversight. The Evidence Route is one practical component of that map. It answers a further control question: what evidence may inform this decision, what standard must it meet, and who verifies it?

A practical evidence-boundary protocol

Before an AI-assisted task begins, ask:

What decision or action will this output inform?
What data and sources are permitted for this task — under policy, law and client commitments?
Which tool or model is approved for those inputs, and under what conditions?
Which approved internal repositories, subscriptions and external sources should the work use?
What source-quality standard applies to the material claims?
Which claims need full verification, and which can be spot-checked?
Who is named to review the evidence, and who is accountable for the next decision?
Where will the source pack, output, limitations and review record be retained?

This protocol is deliberately short. It is a technique that turns “please be accurate” into an operating practice.

Set the Evidence Route up once — then use it repeatedly

The full eight questions are not a ritual to repeat from a blank page. For a recurring decision type, the set-up work happens once and is reviewed when the process, tool or risk changes. Create a short Evidence Route Card that records:

the decision type and its named decision owner;
permitted data/source categories and the approved AI environment, drawing on the Data Boundary Protocol;
the preferred internal repositories, licensed services and primary external sources;
the evidence standard for material claims;
what requires claim-by-claim verification versus a spot check; and
the evidence owner, reviewer, retention point and exception path.

This is a PathPatron Process decision: put the standard beside the recurring workflow, not in a policy archive. For the invoice team, it belongs with the investment/pilot workflow, not as a generic instruction pasted into every conversation.

The use step is then much lighter. The person preparing the brief selects the approved source pack, asks the assistant to distinguish fact, inference and open question, and follows the defined review level. They only escalate when the decision, source, tool or claim falls outside the normal route.

Start small if nothing exists

If there is no evidence policy today, do not start with every source the organisation has ever used. Pick one recurring, consequential decision — such as invoice automation, a client proposal, a procurement shortlist or a board metric — and run a 90-minute Evidence Route session.

Bring the operational owner, the person who knows the internal evidence, the policy/security or privacy owner where relevant, and the decision owner. List the claims the decision needs, identify the sources people currently use, decide which are acceptable for which claims, and name the reviewer. The first route may be provisional. Its value is that it replaces invisible judgement with a visible, reviewable default.

This is where People, Process and Power meet: the right people set a usable standard, the workflow makes it repeatable, and the approved tool configuration supports rather than substitutes for those choices.

Encode the route so people do not have to remember it

Once agreed, make the route reusable in the environment where work happens. Depending on the tool landscape, that may be:

a prebuilt AI-tool skill or workspace instruction that restricts work to named source types;
a template prompt that asks for the decision, source pack and review level before drafting;
a source register or retrieval collection containing current approved materials;
a structured intake card that assigns the evidence owner and review level; or
a verification checklist attached to the investment, client or procurement workflow.

For the invoice-automation example, an approved assistant instruction could say: “Use only the supplied internal baseline, named licensed research, current vendor documentation and official sources. Label supplier claims as supplier claims. Do not calculate ROI from assumptions not present in the source pack. Produce an evidence table for Finance Operations and Security review.”

That instruction is not the policy. It is the Power layer that helps the agreed People and Process controls survive a busy Monday morning.

A prompt pattern that follows the policy

Once the boundary is clear, the prompt can support it:

Use only the approved source pack supplied for this task. Treat the following categories as out of scope: [insert data and source restrictions]. For every material claim, identify its supporting source and distinguish confirmed fact, reasonable inference and open question. Do not use general web knowledge to fill gaps. Flag any evidence that is outdated, not traceable or unsuitable for this decision. Prepare an evidence table for review by [named role].

The prompt is not the policy. It is the final expression of a policy that has already been decided by people with the authority to decide it.

Responsible AI is visible control

The goal is not to make every use of AI slow or legalistic. It is to make the relevant controls visible before a useful convenience becomes an unmanaged dependency.

Some tasks can move quickly with public information and light review. Others need tighter data boundaries, named evidence, specialist sign-off and a durable record. The leadership skill is knowing the difference.

That is why responsible AI work is more than citation. It is the discipline of deciding what may enter the system, what standard it must meet, who checks it and what happens when the evidence is not good enough.

Before You Ask AI for Sources, Decide What It Is Allowed to Know