Verify technical engineering claims against authoritative documentation

Estimated active time: 55 minutes Defensible artifact: Documentation Verification Record v1

Finding an answer is not the same as proving a claim

Two explanations disagree about a Git command. A search result or generated answer confidently describes the command's scope, while another source gives a narrower account. Your local run appears to support one of them. The tempting move is to publish that result as a general technical statement.

This lesson prevents that promotion. You will bind each technical claim to a claim boundary, source authority, exact locator, version/context, freshness state, source statement, and local observation. You will then issue only the strongest bounded decision that the evidence supports.

The deliverable is Documentation Verification Record v1. A reviewer should be able to tell, without guessing, what came from documentation, what was observed only in the recorded environment, where those evidence atoms agree or conflict, what remains uncertain, and when the source needs review again.

This lesson does not claim that official documentation is infallible, that one local run establishes universal behavior, that search rank equals authority, or that an AI explanation is primary authority. It also does not turn documentation verification into a command-execution lab, Root Cause analysis, or a complete Test Strategy.

Three support routes, one evidence bar

• Foundation: explicit definitions, one continuous case, and a partially structured record. The support is removed before transfer.
• Repair: repair only the fragile dimension, such as source authority or the source-statement/local-observation distinction. The final standard does not drop.
• Experienced: move quickly through basic explanation, but still deliver claim boundary, Provenance, version/context, freshness, uncertainty, transfer, and a human decision.

You need enough local project context to bound the claim: tool, recorded version/platform, exact statement under review, and the available local observation. Debugging discipline helps you avoid merging observation with explanation, but this lesson does not diagnose a defect's cause.

Mental model: one claim, several independent Evidence atoms

Treat verification evidence as structured atoms rather than one block of prose:

1. Claim: what exact statement may be accepted, restricted, or rejected?
2. Claim boundary: which tool, version, platform, invocation, and context does the statement cover?
3. Source authority: is the source authoritative for this type of claim? An official command manual can outrank a search snippet for command semantics without becoming an authority on runtime architecture.
4. Locator + version/context: the exact source location and applicability context.
5. Source statement: what the source actually supports, not an expanded inference.
6. Local observation: what happened in the recorded environment. It remains separate even when it agrees with the documentation.
7. Freshness: retrieval date and review boundary.
8. Decision + uncertainty: ACCEPT, MODIFY, REJECT, or bounded defer, with a non-claim and residual uncertainty.

The invariant chain is:

Bounded claim → appropriate authority → exact locator/context → source statement || local observation → support status → bounded human decision.

The double bar is intentional: source statement and local observation do not merge into one atom.

Check your classification before the worked case

Given the opening scenario, write one bounded claim, identify which source class should govern that claim, keep the local observation separate, and name at least one missing evidence item. If you cannot name the missing evidence, narrow the claim before continuing.

Foundation: what Documentation Verification Record v1 must capture

1) Write a claim small enough to verify

Weak: “Git cannot see this file.” More reviewable: “For the recorded invocation, version/context, and documented scope of this command, is this content included, and what did the local run observe?”

If the evidence covers one environment, the conclusion must not silently become a statement about every environment.

2) Select authority by claim type

For Git command semantics, the recorded primary sources for this lesson are the official git-ls-files and git-grep manuals. Their authority is bounded. A git grep result does not by itself establish runtime reachability.

Before search or AI support suggests discovery paths, first make your own initial claim boundary and complete the first applicable primary-source retrieval/diagnosis step. After that step is closed, search snippets, secondary commentary, and AI explanations may accelerate discovery with disclosure, but they must not replace applicable primary evidence or the learner's sufficiency judgment.

3) Record version and context

“According to the docs” is incomplete. Record the exact locator, manual/current-version context, retrieval date, installed tool version/platform or local invocation, and any applicability restriction.

4) Keep two columns separate

• Source statement: what the source supports within its boundary.
• Local observation: what happened in the recorded environment.

If they conflict, preserve the conflict in the record. Guessing them into agreement is not verification.

5) Make the record decision-ready

The final record needs at least: claim, boundary, authority, locator, version/context, freshness, source statement, local observation, support status, uncertainty, non-claim, next action/review, support/AI disclosure, and final human decision.

Use the required documentation-verification ledger to see these fields as one auditable row. The English learner view uses the en-US projection; the canonical machine table is an internal structural authority, not the primary learner display.

Deep explanation: authority is not absolute

Authority is claim-relative

An official manual is strong evidence for the product semantics it actually defines. In the recorded source set for this lesson, git-ls-files is bounded to semantics around tracked/index/worktree file states and is not a repository-architecture authority. git-grep is bounded to pattern-search semantics in tracked/worktree content and is not, by itself, evidence of runtime reachability.

The useful question is not “Which source is most trustworthy in general?” It is “Which source class directly governs this claim, and where does its authority stop?”

Exact locators prevent memory drift

“Git docs” is not a sufficient locator. A reviewer should be able to reach the source you used and see which statement you connected to which claim. If only a snippet or summary survives, Provenance is incomplete.

Version/context prevents accidental universalization

Current online documentation and an installed environment can differ because of version, platform, or configuration. Do not resolve that mismatch by guessing. Restrict the claim, choose MODIFY, or use BOUNDED_DEFER until stronger evidence closes the boundary.

Freshness is part of the evidence

Official does not mean timeless for a tool-current claim. TOOL_VOLATILE sources carry retrieved_at and review_due. Once the review boundary expires, re-verification is part of publication integrity.

Support status is not the final verdict

An evidence row can be SUPPORTED, RESTRICTED, CONFLICT, or INSUFFICIENT. The learner makes the final artifact decision. AI or tools may summarize supplied material or suggest discovery paths, but they do not invent Provenance or replace the human sufficiency judgment.

Worked example: what does “no match” actually prove?

A team wants to publish this statement:

“Because git grep returned no match for legacy_mode, the application cannot depend on legacy_mode anywhere.”

That sentence compresses several different claims: command semantics, the content scope searched by the command, a local observation, and a conclusion about runtime reachability.

Step 1 — narrow the claim

A reviewable version is:

“Under the recorded invocation and environment, does git grep report a match for legacy_mode within its documented search scope?”

This says nothing yet about runtime dependency.

Step 2 — record the appropriate authority

For command semantics, use the official Git git-grep manual version 2.55.0, DESCRIPTION, at https://git-scm.com/docs/git-grep/2.55.0#_description. The page version was last updated on 2026-06-29 and the statement-level locator was re-verified on 2026-09-06. Its authority is bounded to the command search semantics it documents; it does not establish application runtime reachability.

Step 3 — separate source statement and observation

• Source statement atom: Git 2.55.0 documents git-grep as searching specified patterns in tracked work-tree files, index blobs, or supplied tree objects depending on invocation. This statement defines command search scope, not runtime reachability.
• Local observation atom: in the recorded exercise environment and invocation, the command reported no match for the target string.

Neither atom justifies “the application can never depend on this value.”

Step 4 — keep support status separate from the final decision

The supplied training scenario intentionally does not provide the installed Git version/platform mapping. Therefore:

• bounded command-level evidence status: RESTRICTED, because the manual boundary and supplied local observation are relevant but version/platform applicability is not fully closed;
• universal/runtime evidence status: INSUFFICIENT, because neither the manual boundary nor the supplied observation establishes runtime reachability;
• final human decision on the original universal sentence: MODIFY — restrict the publication claim to the command's documented scope and the supplied observation, or gather different evidence if runtime reachability is the actual question.

RESTRICTED/INSUFFICIENT are evidence-support states; MODIFY is the human artifact decision. They are not interchangeable labels.

Step 5 — uncertainty and non-claim

Uncertainty: the supplied scenario omits installed Git version/platform/configuration, so applicability to a specific installation remains unresolved until that context is recorded and checked. Non-claim: “No match in this command does not prove that the string is absent from generated, ignored, external, or runtime data, or that the application cannot reach it.”

The same discipline applies to git ls-files: its output can support bounded file-state semantics, but presence or absence of a path does not itself prove runtime architecture.

Three shortcuts that look professional and still break verification

1) “The top search result already says the answer”

Ranking optimizes retrieval, not claim authority. When an applicable primary source exists, a snippet or secondary article should remain a discovery aid rather than the verdict.

2) “It reproduced locally, so that is what the documentation means”

Local reproducibility is useful, but it does not turn an observation into a source statement. Record the environment and bound the conclusion accordingly.

3) “It is official, so it does not need a date”

A current tool manual can change. Without retrieval and review boundaries, a reviewer cannot know when the evidence must be refreshed.

Contrast case

An AI answer correctly guesses the effect of a command option but provides no exact locator or version. A later local observation agrees. The answer does not become primary authority because it happened to be correct. Repair by locating the applicable primary source, preserving its bounded statement, keeping the observation separate, and disclosing support use.

Check the shortcut

State exactly why “the AI answer was correct locally” is still an invalid authority shortcut, then name one discriminating next evidence step. A valid answer must point to the claim boundary that the shortcut fails.

Experienced bridge: turn good habits into an auditable record

You may already open official docs, read release notes, inspect source code, capture --version, run a command locally, or use AI to discover the right terminology. Keep those habits, but assign each one a role.

• Official manual/spec: potential authority for claims inside the product/standard scope it defines.
• Release notes/changelog: useful for version changes when tied to a specific claim.
• Local run: an observation in your environment, not a documentation statement.
• Source code: implementation evidence for a bounded version/context, not automatically every version.
• Search/AI: discovery and summarization with disclosure, not final authority.

A fast path removes explanatory repetition, not Provenance, freshness, claim boundaries, or final human judgment.

Restrict, defer, reject, or escalate

• When primary authority, local observation, and version/context align, a bounded claim may be ACCEPT.
• When the evidence supports the core statement but not its original breadth, choose MODIFY and narrow the claim.
• When a candidate conclusion conflicts with applicable authority or recorded evidence, choose REJECT.
• When applicability, version mapping, or environment evidence is incomplete, BOUNDED_DEFER is better than fabricated certainty.

If the question becomes “Why does this behavior occur?”, move into causal debugging. If it becomes “What test evidence is needed for this risk?”, move into Test Strategy. Documentation verification should not absorb those constructs.

Guided practice, then independent transfer

Guided pass

Start with the locale-specific partially structured Documentation Verification Record v1 supplied with this lesson. It pre-fills only authorized evidence categories/prompts; it does not lower the final evidence bar.

For the git grep claim, complete these fields:

1. original claim and narrowed claim;
2. source class and authority rationale;
3. exact locator;
4. version/context and local environment;
5. bounded source statement;
6. separate local observation;
7. support status;
8. uncertainty and non-claim;
9. final human decision;
10. next review/action.

On the second pass, switch to the blank Documentation_Verification_Record_v1_template.csv; the suggested evidence-category prompts are gone and you must classify each atom yourself.

Check record integrity before transfer

Before starting the changed-context task, inspect your blank-form record: evidence atoms must be traceable, source statement and local observation must still be separate, support status must not be used as the final verdict, at least one limitation/non-claim must remain explicit, and the final decision must be yours. If one dimension fails, repair only that dimension and repeat this check before transfer.

Changed-context independent task

Use the supplied FND006-S5 changed-context case: it is a deterministic, non-executable training payload for a fictitious CLI tool, with its own source statement, locator/context, secondary explanation, and local observation. Do not copy Git command paths, labels, or answers.

Create a new Documentation Verification Record v1 that demonstrates:

• a claim bounded to the new tool and context;
• authority selected by claim type rather than resemblance to the prior case;
• separate source statement and local observation;
• complete freshness/Provenance;
• a final decision and limitation that you can defend yourself.

What counts as reviewable evidence?

A reviewer must be able to inspect all five critical dimensions:

1. Claim-boundary precision: the claim is no broader than the evidence.
2. Source-authority selection: source class fits the claim and applicable primary authority was not bypassed without reason.
3. Version/context binding: locator and applicability are tied to version/platform/invocation.
4. Separation of source statement and local observation: the two atoms remain distinct even when they agree.
5. Freshness/Provenance completeness: retrieval, review_due, origin, and residual uncertainty are auditable.

Every blocking conclusion must also be traceable, at least one limitation/non-claim must remain explicit, support/AI use must be disclosed, and the final decision must be human. No arithmetic average can compensate for a failed critical dimension.

This lesson intentionally has no standalone executable lab. A local command run may contribute one evidence row; command execution is not the assessed construct.

Assessment: from category distinction to defended transfer

The final assessment covers five performances:

• Retrieval: distinguish claim boundary, source authority, and local observation in a compact case.
• Application: build the central portion of Documentation Verification Record v1 from the supplied FND006-S2 application case.
• Diagnosis: locate the first unsupported promotion from weak evidence to a stronger claim.
• Decision: choose ACCEPT, MODIFY, REJECT, or BOUNDED_DEFER and cite evidence plus a non-claim.
• Transfer: repeat the method from the supplied FND006-S5 changed-context case using new evidence.

For blocking tasks, narrative-only prose is insufficient. The reviewer must be able to inspect claim, source, locator, context, observation, support status, uncertainty, and decision.

References, freshness, and claim boundaries

For this lesson, the recorded primary official sources are:

• SRC-GIT-LS — https://git-scm.com/docs/git-ls-files — bounded to semantics around listing tracked/index/worktree file states; not repository-architecture authority.
• SRC-GIT-GREP — https://git-scm.com/docs/git-grep — bounded to pattern-search semantics in tracked/worktree content; not independent evidence of runtime reachability.

The git-ls-files source remains on its recorded 2026-09-02 retrieval. The statement-level git-grep locator used by the worked example was re-verified on 2026-09-06; the recorded review boundary remains 2026-10-17. Re-verify sooner if a new current claim falls outside the recorded boundary or the cited tool/manual materially changes.

The rules “search/AI are discovery aids” and “source statement and local observation remain separate atoms” are lesson design rules. Do not attribute them to the Git manuals.

Stable non-claims: official documentation is not infallible; one local run does not establish universal behavior; search rank is not source authority; and an AI-generated explanation is not primary authority.