The practical verification guide

Start with one draft

This toolkit helps you check AI-assisted writing before you publish it. Use it for job listings, company entries, and news. You read the sources, check the claims, and make the decision. The worksheet keeps your record.

Paste your draft in Draft and sources. Add the sources you will check. Then check the claims and record your decision. Each step shows what you still need to do. The completed example shows a Hold, a correction, a new check, and Ready. Practice opens a draft that still needs your work.

ArizonaAI.com publishes this resource. Cenk Brown is the project lead. The workflow rules are this project’s choices. The NIST links show related guidance. They do not mean NIST approved or certified the toolkit.

Draft and sources: add your draft, say who it is for, and record the sources you read.
Check claims: list the statements that matter. Check what each source says, whether it is the right source, and whether its date fits.
Decide and save: fix or remove problems, check the final words, and record your decision and reason.

You do the check

The worksheet does not read links, find all errors, prove a source is real, or publish your draft. A person must open the sources, read them, and record what they found.

Say what the draft is for

Record the kind of content, its title, and the original draft. Keep the proposed final text too. Say who will read it and how they may use it. State whether it describes today or an earlier time.

What will you publish, and where?
Who will read it? What choices might they make?
What date or period must the facts fit?
What is outside this review? What information is missing?

Name the reviewer and describe the check they did. Record the real time of the check. Arizona time uses a -07:00 offset. Do not use the review date as a source’s publication date. Mark that date unknown if the source does not show it.

NIST AI RMF MAP 1.1 asks users to understand the setting and intended use. These fields help with that limited part of the guidance. They do not assess the whole AI system.

Sources: SRC05.

Sources: SRC05: AI RMF 1.0, Section 5, Table 2, MAP 1.1; printed page 26, PDF page 31..

Make three separate source checks

Make three separate source checks
Check	What to ask	Made-up example
Source support	Does this source back the exact claim?	A job page says three days in the office. It does not back a claim that the job is fully remote.
Source suitability	Is this the right source to prove this point?	A company can describe its own speed claim. Its announcement alone does not prove it is the fastest.
Timeframe fit	Does the evidence fit the date or period?	An old job posting can show what was offered then. It may not show that the job is open today.

A real source can still be the wrong source. It may describe a different branch of a company, an old offer, or a claim it cannot prove. Several pages that copy one announcement are still one source of evidence.

Keep facts, claims, estimates, opinions, and your own conclusions distinct. Write who made a claim when that matters. If a source does not mention something, say “not stated.” That does not mean the thing does not exist.

A claim is not proof

In a made-up case, Mesa Ember says its prototype used less energy in an internal test. That supports a report of what the company said. It does not prove the result holds for all products or settings.

Keep a source trail others can follow

Read the actual source. Check the nearby text, table notes, and other details that may change its meaning.
For a web source, keep the address you were given and the final address that opened.
Record the publisher or source owner and the title.
Say where to find the evidence, such as a heading, page, table, or short quote. Keep enough text to explain your check.
Record the source date, if known, and who checked it and when.
Note limits, conflicts, and pages that repeat the same original source.

Choose a source with direct knowledge of the point you are checking. A trusted website is not proof of every claim. If sources disagree, keep both positions and explain the conflict.

If a page is gone, a dated copy of the actual source may help. Record when and how it was saved, what it shows, and what it cannot show. Your summary alone is not a saved copy of the source. Check any replacement source before using it.

NIST AI 600-1 action MS-2.5-003 concerns checking sources and citations. These steps support that part of the guidance. They do not prove that every source is real or correct.

Sources: SRC06.

For a document, interview, or email, choose a non-web source. Give a useful record reference, source owner, and place to find the evidence. Do not invent a web address. Short names and titles are fine if another reader can identify the record.

Sources: SRC06: NIST AI 600-1, Section 3, MEASURE 2.5, MS-2.5-003; printed page 31, PDF page 35..

Check each statement that matters

List each claim that could change a reader’s choice. Split claims that need different evidence. “The factory opened and created 400 jobs” needs checks for both the opening and the job count. Read the full draft for claims you may have missed.

Keep the original words and the final words for each claim. Link the source and say where the evidence is. Check source support, source suitability, and timeframe fit separately. Explain how much the claim matters. Include headlines, captions, links, and missing details that could mislead.

Check words that change meaning, such as “not,” “may,” “up to,” and “planned.”
Check numbers, units, totals, date ranges, and who or what each number describes.
Do not fill gaps with guesses. Mark missing facts as unknown or leave them out.
After editing, check the exact final words. Read the whole final draft again for other claims.

Your claim list needs a human check

The tool cannot know if your list is complete. Confirm it only after you have read the full draft and listed all claims that could affect a reader’s choice.

You can select words in the draft to start a claim card. It starts unchecked. You may discard a blank card. To remove a claim or source you have used, give a reason. Earlier saved versions and related issues stay in the history. Do not mark a claim removed if its words are still in the final draft.

Use checks that fit the content

Job listings

Check the employer, role, job ID, and application link. Check the work location, pay, and who may apply. Keep required skills separate from preferred skills. Check whether the job is still open. An old posting is not proof that it is open today. This toolkit does not screen job applicants.

Company entries

Check the exact company and any branch named. Separate products it sells from AI it uses inside the business. Check claims about location and customers. Keep plans separate from current work. A prototype is not the same as a product for sale.

News summaries

Separate the date of an announcement from the date of the event. Plans, funding promises, building work, and an open site are different stages. Say who made each claim. Check numbers, units, estimates, and limits. A forecast is not a promise of what will happen.

Decide how much a claim matters

A material claim is one whose error could change a reader’s choice. Employer names, application links, who may apply, pay, location, dates, and current status often matter. Decide in context. Do not rely on a score.

If you are unsure whether a claim matters, choose Unsure. This choice can keep the review on Hold. If you choose Small effect: explain why, say why an error would have little effect. Saved records call this Minor. Do not use this choice just to pass the checks.

A Minor claim still needs a checked source, all three source judgments, a reason, and a check of the final words. There is one narrow exception for source suitability: you must explain it, and the source must still support the words and fit the time. The summary lists this exception. It cannot excuse missing evidence, a conflict, or an old check.

What matters depends on the reader. The wrong nearby city may change a job seeker’s choice. A small spelling error may not. Several good claims do not cancel out one serious error.

Name the reviewer and the next person to ask

Name the person who checked the work and the person who approves it. They may be the same person. For a hard or high-risk claim, ask someone with the needed knowledge to review it. Record only work they actually did.

If you work alone, a second pass is still your own check. Do not call it independent review. AI or agent help is not human approval.

If you cannot settle a claim, write a clear question and keep the evidence. Ask a person with the right knowledge, narrow the claim, remove it, or keep the review on Hold. Record who will act, what they will do, and when to check again.

NIST AI RMF GOVERN 2.1 and MAP 3.5 address roles and human oversight. Naming reviewers and follow-up owners supports a limited part of that guidance.

Sources: SRC05.

Sources: SRC05: AI RMF 1.0, Section 5, Table 1, GOVERN 2.1, printed page 23, PDF page 28; Table 2, MAP 3.5, printed page 27, PDF page 32..

Fix the issue before changing the decision

Fix the issue before changing the decision
State	What it means
Work in progress	You are still working. No Ready or approval decision has been recorded for this version.
Hold	An issue or missing check blocks Ready. Keep the draft on Hold while you work.
Ready	The required checks are complete and a reviewer recorded Ready for this exact version. It still needs a human approval decision.
Approved	A named human recorded approval for this exact reviewed version.
Withdraw	Do not use this draft. Keep the reason and review record.

Each Material or Unsure claim that stays in the draft needs a checked, suitable source and a clear place to find the evidence. Record who checked it and when. Missing, partial, conflicting, or unchecked support keeps the review on Hold. An unknown or wrong timeframe does too. Choosing a positive answer is not proof.

Correct the words to match the evidence. Then check the final words.
Narrow the claim or say who made it. Then check that exact wording.
Remove the claim from the draft. Keep the issue and the record of its removal.
If the issue stays open, keep Hold or choose Withdraw. Explain why.

Writing a note about an unresolved material issue does not fix it. Check the final words before recording Ready or Approved. Publishing elsewhere while the worksheet says Hold does not turn Hold into approval.

Tie approval to the version that was checked

Each decision belongs to one exact version of the draft, sources, claims, and context. An edit creates a changed version. The old decision stays in the history, but it does not approve the changed draft.

The record keeps a full copy of the inputs used for each decision. It also saves the current version when you save the review. After changing the full draft, check the claim list again.

The workbook needs manual version records

Before a decision, save a dated copy of the whole workbook. Use its Revisions sheet to record the version and decision. After an edit, clear the old approval, do the checks again, and save a new dated copy. The workbook formulas do not enforce the web worksheet’s rules.

JSON review files and workbooks can be edited outside this tool. Their history helps you inspect the work. It does not prove who did it, prove the date, or prevent tampering.

Choose Save on this device to keep this review in this browser. The page says saved only after the save finishes. Choose Open saved reviews to return to a copy; saving then continues for that review. Choose Private session to stop new device saves. That does not remove a copy already saved: removing it is a separate choice. Nothing is uploaded. Clearing this browser’s site data can erase its copies. Keep a separate backup file. Where supported, Link a backup file updates a file you choose while this tab is open. Otherwise use Download backup. Keep that file so you can reopen it if the browser copy is lost.

You can open version 1.0.0 review files. Their original decisions and saved versions stay in the record. The repaired rules check current readiness again. An old approval that fails those rules is marked as history and cannot approve the current draft. Keep the original file as a backup.

Fix published errors and learn from close calls

Keep separate records for an error, a close call caught before harm, and actual harm. Preserve the original and corrected words. Do not present a planned fix as finished work.

Limit further use of wrong information when you can.
Check the report and the source evidence. Record what you find.
Look for the same error in related content.
Tell the right people when needed and authorized. Keep private details out of public notices.
Record what was actually corrected, who did it, and when.

A public correction should say what changed, why, and when. Use clear words and include only the personal details needed to explain the change.

NIST AI RMF MANAGE 4.3 and NIST AI 600-1 action MG-4.3-002 address documenting and sharing incidents and errors. These prompts support the part related to publishing corrections.

Sources: SRC05; SRC06.

Sources: SRC05: AI RMF 1.0, Section 5, Table 4, MANAGE 4.3; printed page 33, PDF page 38.; SRC06: NIST AI 600-1, Section 3, MANAGE 4.3, MG-4.3-002; printed page 45, PDF page 49..

Set a time or reason to check again

Name an owner and set a date or event for the next check. Match it to the risk. A job may need a check before you share it again. A planned project may need a check when it is due to open. A forecast may need a check when its period ends. These are project choices, not NIST deadlines.

Give readers a way to report an error. Decide who reads reports and which need quick action. Checking a sample of content can find problems. It cannot prove that every item is correct.

Are review owners and correction contacts still current?
Which records are due for a check, and why?
Are the sources still available and suitable?
Do repeated errors show that the review steps need to change?

NIST AI RMF GOVERN 1.5 and MANAGE 4.1, and NIST AI 600-1 actions GV-1.5-001 and MG-4.1-002, address ongoing review. These prompts support only the publishing tasks named here.

Sources: SRC05; SRC06.

Sources: SRC05: AI RMF 1.0, Section 5, GOVERN 1.5, printed page 23, PDF page 28; MANAGE 4.1, printed page 33, PDF page 38.; SRC06: NIST AI 600-1, Section 3, GV-1.5-001, printed page 16, PDF page 20; MG-4.1-002, printed page 44, PDF page 48..

Measure a clear question

Choose a question that helps you manage a real risk. Use observed data. State the period, what you counted, what you left out, and what is unknown.

Measure a clear question
Measure	What to record	Limit
Material issues found	Count reviewed items with a material issue and all items reviewed.	This describes the reviewed set, not all published content.
Checks past due	Count records past their planned check date. Note missing dates.	A missing or late check does not by itself prove the content is wrong.
Time to fix an issue	Record when the issue was found and when it was fixed.	List open issues separately. Do not hide them in an average.
Issues first found after publication	Count reports first found after release and describe the reporting process.	No report does not prove there was no error or harm.

Keep the counts, dates, exclusions, and method with the result. Leave fields blank until you measure them. Compare like periods and tasks. A change at the same time as a new process does not prove the process caused it.

NIST AI RMF MEASURE 1.1 concerns methods and measures that fit the risks. These examples are publishing-process measures. They do not measure the reliability of an AI system.

Sources: SRC05.

Sources: SRC05: AI RMF 1.0, Section 5, Table 3, MEASURE 1.1; printed page 29, PDF page 34..

Decide which records to keep

Use the record-keeping template to name an owner. State how long to keep records, who may see them, and why. Check duties, disputes, and other needs before deleting evidence. This guide is not legal advice.

A public source is not automatically free to copy or share. Keep only the evidence you need. Separate your summary from a source quote. Protect private information and respect source rights. If you cannot keep the source, record that limit.

Choose who may access browser copies and backup files. Keep stable IDs so records can be matched. A Private session stops new device saves but does not delete an earlier saved copy. Remove saved copies only when you mean to. Browser data can be cleared, so keep a separate backup where needed. A file hash can show that bytes match. It does not prove the content is true.

NIST AI 600-1 action GV-1.5-003 addresses record-keeping needs. It does not set one retention period for every publisher.

Sources: SRC06.

Sources: SRC06: NIST AI 600-1, Section 3, GOVERN 1.5, GV-1.5-003; printed page 16, PDF page 20..

Keep a full, readable record

The JSON backup keeps the full review and its history. An audit CSV helps you inspect it but cannot replace that backup. The workbook needs its own manual record of versions.

Before sharing, check whether the draft is still on Hold and whether private text remains in its history.
Keep linked sources, claims, issues, and saved versions together.
Keep unknown answers marked unknown. Do not change them to a positive answer to finish a form.
Remember that an older saved version may still contain words you removed from the current draft.

CSV downloads protect against common spreadsheet formula use by adding an apostrophe to risky cells. The JSON backup keeps the original text. Normal page requests still reach the site host, which may keep access logs. The toolkit does not upload your review text.

You may save unfinished web addresses and dates as draft text. They do not become usable evidence until checked. The full review file is limited to 8 MiB (8,388,608 bytes), including history and file formatting. The tool checks that limit before accepting an edit. If it is full, download a backup, then start another review. Name the earlier review in your notes. Do not delete decision history just to make space.

Explain what the review did

Readers may mistake a rewrite for an independent check, a current fact, or a complete report. Explain what was checked and its limits. Name the publishing owner and a correction contact. Do not leave a “verified” label on changed or out-of-date content.

Say how AI helped when that matters to the reader. Name the publisher, sources, check date, and limits. Provide a correction route. Do not claim independent proof if you used only the subject’s own announcement.

Made-up publication note

This summary describes the company’s October 1 plans. It does not confirm that the project is open. This is a teaching example. Change every detail to match your own evidence before using a note like it.

NIST AI RMF MEASURE 2.8 concerns risks linked to transparency and responsibility. These notes support a small part of that work. Source links alone do not cover all of it.

Sources: SRC05.

Sources: SRC05: AI RMF 1.0, Section 5, Table 3, MEASURE 2.8; printed page 30, PDF page 35..

Know what each kind of test can show

Keep made-up practice, dated examples from real pages, software tests, agent checks, and actual human studies separate. Each can answer different questions.

For a test, record the version, task, materials, steps, kind of reviewer, result, and limits. These examples do not show an error-detection rate, time saved, less harm, or model reliability. Do not claim those results without the right study.

NIST AI 600-1 action MS-2.5-001 supports focused checks of outputs. The toolkit connects to that limited task. NIST AI RMF MEASURE 2.1 and 2.5 are broader. These examples do not test an AI system’s reliability.

Sources: SRC05; SRC06.

Sources: SRC05: AI RMF 1.0, Section 5, Table 3, MEASURE 2.1 and MEASURE 2.5; printed page 29, PDF page 34.; SRC06: NIST AI 600-1, Section 3, MEASURE 2.5, MS-2.5-001; printed page 31, PDF page 35..

Know the limits

The mapping uses AI RMF 1.0, NIST AI 100-1 (January 2023), and the Generative AI Profile, NIST AI 600-1 (July 2024). It marks selected parts the toolkit supports, broader related ideas, and gaps. It is not a claim of compliance with either document.

Sources: SRC05; SRC06.

The toolkit does not provide tamper-proof source history. NIST AI 600-1 action MS-2.8-003 is marked Not covered. It also does not test instructions given to users of a generative AI system, so MS-2.8-004 is Not covered.

Sources: SRC06.

The tool cannot guarantee a complete claim list, real sources, honest reviews, correct facts, or safe future use. It does not cover all AI risks. Guidance and sources may change. Check the official sources again before reusing a dated mapping, and keep the version of the evidence you used.

Sources: SRC05: AI RMF 1.0, title page and Section 5.; SRC06: NIST AI 600-1, title page; Section 3, MS-2.8-003 and MS-2.8-004, printed page 34, PDF page 38..

Forms you can reuse

Use these questions in your own records or workbook. A blank form does not mean a policy is in use or a task is done.

Who checks, decides, and helps

Name the people who check evidence, approve work, fix errors, and answer hard questions. ArizonaAI suggests this approach. Filling out a plan does not prove that anyone has done the work.

Work covered: What kinds of content will these people review? Who will read it, and how will readers use it?
Person who runs the review: Name the person who checks the evidence and keeps the review record.
Person who can approve: Name the human allowed to approve the checked version. Say if this is also the person who runs the review.
Who checks the work: Will you check your own work, make a separate second pass, or ask another person to check it? Describe any AI help on its own.
When to ask for help: Which claims could affect a reader's choice? Which are disputed or outside your knowledge? Say when you need another source or person.
Who can help: Name a real person or role and how to reach them. Do not invent a team or an expert.
If no one can answer: Will you Hold, remove the claim, narrow its wording, or withdraw the item? Record the choice and who can review it again.
Who fixes errors, and their backup: Who reads error reports, checks related content, and makes sure each fix was done?
When to review these roles: Choose a date or change that will prompt a review of these roles. Use Arizona time when you record a time.

Problem and fix record

Keep the problem, evidence, response, and result. Make clear which fixes are planned and which are done.

Linked records: Enter the issue ID, review ID, claim IDs, and version with the problem. Keep these IDs the same.
What happened: Choose an error report, an error caught before release, or harm you observed. Explain any other type.
When it was reported or found: Record the real time in Arizona time. Keep the time reported by someone else separate from when you found the problem.
Content with the problem: Give the draft or public page location, version, original words, and readers who may be affected.
Problem and its importance: Say what may be wrong and who it could affect. Choose Material if it could change a reader's choice, Minor, or Unsure. Do not claim harm you have not observed.
Evidence and open questions: Link the source IDs and exact places to read. Name who checked them and when. Include evidence that disagrees and questions still open.
Person in charge of the next step: Name the person in charge and when, or after what change, they will check again.
What to do now: Record any Hold, wording change that narrows the claim, removal, or withdrawal. Say whether it is planned or done.
New wording: Keep the original words. Add the proposed fix or record a removal you have checked.
Check the fix: Who checked the new words or confirmed removal? When, and using which evidence? Choosing a status does not count as a check.
Other content to check: Could the same source, prompt, or rewrite have caused errors elsewhere? Record what you checked and what you found.
Who needs to know: Who needs a notice, why, and how are you allowed to contact them? If no notice is needed, say why.
What was done: Record the corrected public page, notice, or withdrawal, with its version, location, and Arizona date and time. Keep unfinished work marked as pending.
Status and problems still open: Choose Open, Awaiting evidence, Awaiting recheck, Resolved, or Retained as a disclosed limitation. A limit that could affect readers keeps the item on Hold. To clear it, the changed claim must fit its use and pass a new check.

How to keep and remove records

Choose how to keep review records and write down the rules. This toolkit does not set one time limit for every record.

Person in charge of these rules: Name the person in charge. Add the rule version and the date it takes effect.
Records to keep: List what you will keep: original drafts, final text, sources or copies you may keep, claim checks, decisions, saved versions, fixes, and test records.
How long to keep each kind: Set a time limit or event for each kind of record. Say when a rule is unknown or not yet decided.
Why these rules apply: Explain what the work needs and any duties that apply. Name who will settle open questions. This form does not tell you what the law requires.
What source material you may keep: What source material may you keep, and why are you allowed to keep it? How must you credit the source, and who may see it?
Where records are kept: Where will you keep the records? How will you find sources by ID and the saved version linked to each decision?
Who may use the records: Who may read or change records? Leave out personal or private details that the review does not need.
When records may be deleted: Who may approve deletion, and how will you record that it was done? What open dispute or other duty requires you to keep a record?
When to check these rules: Set a date or event for checking these rules. Record what the next check finds after it happens.

Plan follow-up checks

Assign follow-up checks and find out whether they help. A planned date does not prove that a check was done.

Content to check: Name the group of content, dates, and readers. List claims that may change and affect readers' choices.
Person in charge and backup: Name who will handle source changes, reader reports, and open problems.
What to check first: Which risks need attention first? Think about their impact, what is unknown, how often facts change, and past problems.
When to check: Choose the next check date or event and explain why. Show dates and times in Arizona time.
Which items to check: Will you check every item or a sample? Record how you choose, how many you checked, what you left out, and the limits of the check.
How to check sources: Name the original sources, claims, exact passages, and evidence records to check again.
How readers report errors: What real contact or form accepts error reports? Who reads them, and how are they recorded?
What the checks found: Record checks that are done, sources you could not open, changed facts, late work, and linked issues. List planned work separately.
Did the checks help?: What did the checks miss? Were key changes found before readers might use old facts? Did the people in charge act? Give evidence for each answer.
What to improve next: Record changes to when or what you check, the evidence you need, when to ask for help, or who does the work. Name the person in charge.

Tell readers how the work was checked

Explain how the item was prepared and checked. Use words readers can understand. Fill in every blank and describe only checks that took place.

Publisher in charge: Name the group that publishes this item and the person or role in charge of its review.
How AI was used: Describe what AI did, such as drafting, making a summary, or rewriting. Be clear about what people checked and what was done without them.
Sources and findings: Name the source material and what the check showed. Saying what a source reports is different from confirming it with separate evidence.
Check date and time covered: When were these claims checked? What time period do they describe?
Limits readers need to know: Could readers mistake a plan for a finished event, an old offer for a current one, or a summary for separate reporting? Explain the limits that matter.
Where to report an error: Give a real contact or form controlled by the publisher and checked by someone. Do not invent an email address.
Who checked this note: Name the person who checked that every statement in this note is true for this version.

What to measure and what you found

Define what you will measure before using the results. This form contains no test results, comparison scores, proof of success, or target percentages.

Question and reason: What risk to readers will you measure, and why does it matter?
What to measure: Name what you will count or time. Examples include serious issues in reviewed items, late checks, time to fix an error, or serious issues first found after release.
What counts as one: Will you count items, claims, issues, checks, or time? Say when something counts, and avoid counting it twice.
Count for this event: Define the event you will count. Leave the result blank until you measure it.
Total used to find a rate: For a rate, define the full group that could qualify and how many you checked. If you checked a sample, do not use all published items as the total.
Dates covered and report date: Give the start, end, and report dates in Arizona time. Say when you gathered the evidence.
What was chosen or left out: Record how items were chosen. List excluded items, missing facts, sources you could not open, and open problems separately.
Steps and evidence used: Name the records, release or work-method version, reviewer types, and math used. Describe the steps you took so someone else can repeat them.
Measured results: Enter only counts or times you measured. Say where to find the records that support them. A blank means not measured. It does not mean zero.
What the results can tell you: What do the results show, and what can they not show? Which key risks were not measured? Keep made-up practice, software tests, AI checks, real-source examples, and human studies separate.
Next step based on the results: Record any change to the review, further checks, or ongoing monitoring. Name the person in charge and say what is planned or done.

Save a version and record a decision

Link each workbook decision to the evidence used. You must do these steps yourself. An editable spreadsheet does not protect old versions from changes.

Version details: Enter the review ID, new version ID, prior version ID if any, who made the change, and when it was made.
What changed: Describe changes to the draft, sources, claims, readers, use, time period, importance of claims, fixes, or statement that all key claims are listed.
Saved copy for this decision: Save a dated copy before the decision. Record its exact filename or location. Include the text, claims, sources, issues, and context used for that decision.
Final list of claims: After any full-draft edit, read the final text again. Confirm again that you listed every claim that could change a reader's choice. Name who checked.
Problems still open: List every open issue. Material and Unsure issues block Ready and Approved. Explain any Minor limits you will keep and tell readers about.
Decision and reason: Choose Hold, Ready for human approval, Approved by named reviewer, or Withdraw or reject. Say why. Name the human in charge where required and record the real decision time.
Earlier decision: Name the earlier decision that this one replaces for the current draft. Keep its saved version. Do not overwrite it.
Check that the record is complete: Keep each decision's saved version and all linked evidence files with the finished review. Check that every link or reference leads to the right record.