This guide gives you a reusable starting pattern. It is designed to help you see the work more clearly; it is not a substitute for judgment, source checking, or responsibility for the result.
Prepare the inputs before you ask for output.
The model only sees what you give it. Spend a few minutes naming the reader, desired result, and uncertain information. This makes a first draft easier to assess and reduces the need for decorative rewriting later.
Make the evidence trail reviewable.
Create a claim-level inspection surface before a reader compresses evidence into a brief or recommendation.
Inputs required
- Specific decision. A choice that makes it possible to judge which claims are decision-critical.
- Source register. Source label, publisher or author, date, location, type, scope, and access context.
- Atomic claim notes. One proposition per row, kept separate from inferred meaning and recommended action.
Method sequence
- Split. Turn compound statements into atomic claims.
- Classify. Record source type and directness of support without false numeric precision.
- Challenge. Add limitation, counterevidence, scope risk, and freshness risk to every material row.
- Verify. Investigate the rows whose reversal could change the decision before drafting a brief.
Public sources used in this guide
- National Institute of Standards and Technology (NIST): NIST AI RMF PlaybookPublic-source walkthrough: voluntary guidance, suggested actions, and source-type classification.
Public-source walkthrough
One public framework can support a narrow claim while leaving other claims open
The record uses NIST’s published description only to demonstrate claim boundaries and source classification.
- Direct support
- NIST describes the Playbook as voluntary guidance with suggested actions and references for four AI RMF functions.
- Context only
- A secondary implementation guide can explain how one organization interprets the framework, but does not replace the primary source.
- Not established
- Legal compliance, a product’s safety, or an organization’s adoption status.
- Human next step
- Check the applicable rule or internal control directly with the appropriate qualified reviewer.
This is a public-source walkthrough, not legal advice, compliance validation, or a finding about any system.
Original working artifact
Claim-level evidence matrix
Copy this original matrix before drafting a brief; it is intentionally structured to show why a row is weak rather than assign a decorative score.
# Claim-level evidence matrix ## Decision boundary - Decision question: - Decision owner / reviewer: - Consequence if this decision is wrong: ## Source register | Label | Publisher / author | Link or file | Date | Source type | Scope / limitation | | --- | --- | --- | --- | --- | --- | | [S1] | | | | | | ## Claim rows | Atomic claim | Exact source label | Direct support: Direct / Partial / Context only / Not supported | Limitation or counterevidence | Freshness / scope risk | Impact if wrong | Next verification | Reviewer status | | --- | --- | --- | --- | --- | --- | --- | --- | | | | | | | | | | ## Decision-critical rows 1. Row and exact record needed to change it: 2. Row and exact record needed to change it: 3. Row and exact record needed to change it:
Give the task a useful brief.
Build an evidence matrix from the labeled record below. Preserve the distinction between what a source says, how directly it supports a claim, and what still must be checked. Decision question: [specific choice] Decision owner / reviewer: [if known] Source register: [label | publisher / author | link or file | date | source type | scope] Claim notes: [paste each observation with its source label] Create one row per claim using these columns: claim; exact source label; source type; direct support in supplied record; limitation or counterevidence; freshness / scope risk; impact if wrong; verification step; reviewer status. Use only “Direct”, “Partial”, “Context only”, or “Not supported in supplied record” for the support field. Do not create numeric confidence, citations, owners, dates, evidence, or conclusions. After the table, name the three rows most likely to change the decision and say what exact record would change them.
Replace every bracketed field with your real context. Read the output before reuse.
Four steps that keep the result usable.
- 1
State the decision question and what a wrong answer would affect before creating rows.
- 2
Create a source register with publisher, date, type, scope, and location before you rate any claim.
- 3
Use one atomic claim per row; split a sentence when it combines a fact, an inference, and a recommendation.
- 4
Classify directness of support without turning it into a made-up confidence score.
- 5
Prioritize verification by decision impact, then reopen the original material for the highest-impact rows.
A matrix has a different job from a research brief
A research brief compresses the decision-relevant record for a reader. A matrix slows the work down before that compression. It gives each claim a row, preserves its source type and limitation, and names the verification work. Use it when multiple sources conflict, when a claim could reverse a choice, or when a summary would hide where the conclusion began. Do not use it merely to make a thin record look rigorous.
Write atomic claims before you score support
“The policy applies to our use and blocks launch this quarter” contains at least three claims: what the policy says, whether it applies, and whether it affects timing. Put those in separate rows. An atomic claim lets a reviewer challenge the correct thing instead of accepting a broad sentence because one part is true. It also stops an AI system from using evidence for one proposition as though it proved the next.
Classify source type before evaluating directness
A primary standard, a publisher’s implementation guide, an internal observation, and an unverified assertion do different jobs. First record what kind of source you have and its scope. Then state whether the supplied record directly supports the claim, partially supports it, provides context only, or does not support it. This is deliberately plainer than a numeric confidence score: a number can look objective while concealing why the row is weak.
Public-source walkthrough: voluntary guidance is not a compliance finding
NIST describes its AI Risk Management Framework Playbook as voluntary guidance with suggested actions and related references across Govern, Map, Measure, and Manage. A matrix can record that primary public source, then separately record an implementation guide or an internal policy claim. The rows make visible that the NIST material describes a voluntary framework; it does not by itself prove legal compliance, a product’s safety, or what a specific organization must do.
Use support labels that explain their limit
“Direct” means the source speaks to the exact claim within its stated scope. “Partial” means the source supports a related part but leaves a material leap. “Context only” means it informs background but does not establish the claim. “Not supported in supplied record” is a valid result. Attach the next verification step to the gap: open a primary document, check the applicable date, reproduce a calculation, or ask a named reviewer to define the term. Do not let “medium confidence” substitute for this explanation.
Prioritize rows by the cost of being wrong
A missing comma in background context may not change a choice; a wrong assumption about scope, authority, cost, or timing can. Mark the rows whose reversal would alter the decision, a dependency, or the responsible owner. Verify those first, even if they are inconvenient. The matrix should help allocate attention, not encourage the team to fill every cell before anyone is allowed to think.
Illustrative composite: three sources, three different roles
Consider a fictional AI-use review with a primary public framework, a vendor implementation article, and an unlabeled internal note. The framework row can be Direct for the statement that the framework is voluntary guidance; the vendor article may be Context only for a claim about the framework’s intent; the unlabeled note may be Not supported in supplied record until its author and date are known. This is an illustrative composite, not a compliance assessment or a claim about any organization’s controls.
Stop the matrix where judgment begins
A matrix can make the record reviewable, but it cannot decide the acceptable trade-off or remove the need for qualified review. Move to a research brief when the highest-impact rows are understood. Move to a decision record when someone with authority has selected an option. If the matrix still contains a decision-critical “Not supported” row, its correct output may be a verification request rather than a recommendation.
Run a human check.
- Does every material claim have an exact source label or a visible “Not supported in supplied record” status?
- Is each claim atomic rather than a fact, inference, and recommendation fused together?
- Are source type, directness of support, scope/freshness risk, and limitation kept distinct?
- Which three rows could change the decision, and does each have a specific verification step?
- Has a human reopened the original source for decision-critical rows before the matrix supports a recommendation?
- Did the draft avoid inventing citations, dates, owners, numeric confidence, or certainty?
Keep your human check visible.
Mark the checks you have personally reviewed. This is a local reading aid—not evidence that a claim, commitment, or decision is correct.
This checklist is stored only in this browser when storage is available. It is not sent to Knexio or used for analytics.
AI is strongest here when it makes missing information, structure, and options easier to see. The moment an output becomes a claim, commitment, or decision, bring a person back into the loop.
What this page specifically establishes
This page explains how to keep claims, source labels, limitations, and verification work visible before a summary becomes a decision input.