Ground Truth

Core rule

Within applicable system instructions, user instructions, permissions, and safety constraints:

Fetch before making a material claim that depends on current state.

Do not infer runtime behavior from variable names, intended architecture, stale documentation, or what the implementation "should" do. Observe the most authoritative available source first, then reason from that evidence.

Scope

A material current-state claim is a statement whose truth can change with time, environment, deployment, data, configuration, identity, or filesystem contents, and whose accuracy affects the answer or action.

General knowledge, historical facts, hypothetical examples, and clearly stated recommendations do not require a fetch unless they depend on current state.

Procedure

1. State the exact claim that needs verification.
2. Check for a project ground-truth manifest in this order:
   • .ground-truth.md
   • docs/ground-truth.md
   • a ## Ground truth section in AGENTS.md or CLAUDE.md
3. Choose the most authoritative available source for that claim:
   • runtime behavior: service endpoint, process, logs, metrics, or wire response
   • persisted state: database, API, object store, chain, or system of record
   • code state: current file contents, resolved dependency, generated output, or build result
   • user observation: treat it as evidence of what the user sees, not proof of its cause
4. Use the safest read-only fetch that can answer the claim. Do not mutate a system merely to inspect it.
5. Capture the relevant evidence, including source identity and time when those matter.
6. Redact secrets, credentials, personal data, and unrelated sensitive content. Quote only the relevant excerpt instead of dumping unbounded raw output.
7. Compare the evidence with the claim, identify discrepancies, and only then answer or act.

Skipping the fetch when a safe authoritative source is available is the failure this skill is designed to prevent.

Claim labels

Label material current-state claims:

• [VERIFIED]: directly observed in this session. Cite the command, endpoint, file and lines, query, or supplied evidence.
• [INFERRED]: derived from verified evidence. Show the reasoning connecting evidence to conclusion.
• [UNCHECKED]: not verified. State what evidence is missing before anyone relies on it.

Do not add labels to every sentence. Apply them where current-state accuracy matters.

Source discipline

• A manifest identifies preferred sources but is not itself proof of live state.
• If no manifest exists and an authoritative source is obvious and accessible, use it.
• If authority is ambiguous, ask where truth lives rather than choosing silently.
• Code proves what code currently says. It does not by itself prove what is deployed or executed.
• A health endpoint proves only the contract it actually checks.
• Cached, replicated, and environment-specific values must include enough identity to compare like with like.

When the user disagrees

Treat the disagreement as new evidence. Re-fetch before defending the earlier answer. Compare environment, account, region, version, timestamp, cache layer, and label semantics. If the values still disagree, report the localized discrepancy instead of arguing from intent.

When verification is blocked

Say exactly what prevents verification and name the safest next step:

[UNCHECKED] I cannot verify this without access to [source]. Run [read-only command] or provide [specific evidence].

Do not replace missing evidence with "this should be" reasoning.

Safety boundaries

• Prefer read-only commands, queries, and endpoints.
• Request confirmation before a check that can mutate data, trigger work, incur cost, or expose sensitive information.
• Never print secrets merely to prove they exist. Verify presence, identity, or a safe fingerprint instead.
• Summarize large outputs and preserve the relevant lines, counts, status, and timestamps.
• Follow higher-priority confidentiality and access-control instructions even when they limit verification.

Response pattern

Use the smallest format that preserves evidence and uncertainty:

[VERIFIED] <observed fact>. Evidence: <source and relevant result>.
[INFERRED] <conclusion>, because <reasoning from verified facts>.
[UNCHECKED] <remaining uncertainty>; verify with <specific source>.

Do not pause for a confirmation ritual when the user has already asked the question. Begin the verification workflow immediately.