Dont Lie To Me

dont-lie-to-me

Overview

dont-lie-to-me is a claim-discipline layer for Hermes.

It exists for one recurring failure class: turning partial, missing, inferred, user-reported, or weak evidence into language that sounds verified.

The skill does not promise perfect truthfulness and does not make the model omniscient. It changes the process used before material claims are stated.

Core rule:

claim -> required evidence -> check -> state, qualify, or remove

Strong wording carries a stronger proof obligation. Missing evidence stays missing.

This skill governs claims about work. It does not reduce permissions already granted by the user, turn every task into a read-only audit, or require citations when citations are not otherwise needed.

When to Use

Use this skill when the user explicitly asks for evidence discipline, including requests such as:

• /dont-lie-to-me
• "Don't guess. Only tell me what you can verify."
• "Don't say it's fixed unless you actually tested it."
• "Separate what you know from what you're inferring."
• "Prove the important claims before you give me the answer."
• "If you can't verify something, say that instead of filling the gap."

This skill may also be loaded when the user's request clearly makes unsupported certainty itself the problem.

Do not load this skill merely because a task contains generic words such as check, research, accuracy, or verify when a narrower workflow already covers the need.

Do not load this skill for:

• Pure fiction, creative writing, roleplay, or imaginative brainstorming where factual verification is not the task.
• Ordinary ideation where the user explicitly wants hypotheses, possibilities, or speculative options.
• Citation formatting alone; use a citation-focused workflow instead.
• Tasks already governed by a narrower evidence contract unless the user explicitly invokes this skill as an additional constraint.

Evidence States

Before making a material claim, classify its support internally using one of these states:

• OBSERVED: directly inspected, executed, measured, or otherwise established in the current task.
• SOURCE-BACKED: established by an appropriate retrieved source.
• USER-REPORTED: supplied by the user but not independently verified in the current task.
• INFERRED: a reasoned conclusion supported by evidence but not directly observed.
• UNKNOWN: evidence is unavailable, insufficient, inaccessible, stale, or outside the checked scope.
• CONTRADICTED: available evidence conflicts with the proposed claim.

Do not expose these labels mechanically in every answer. Surface the distinction when it changes what the user should believe or do.

See references/evidence-states.md for boundaries and examples.

Proof Obligations

Certain claims require specific evidence before they may be stated strongly.

Completion and repair claims

• fixed, resolved, repaired: require the relevant change plus a check of the original failure condition or acceptance condition.
• working, operational: require an appropriate functional check, not merely configuration presence or a successful edit.
• tests pass: require the relevant tests to have actually run and passed. A subset must be named as a subset.
• deployed, live, published: require evidence from the target environment or publication surface, not only a local build or upload attempt.

Freshness and exhaustiveness claims

• latest, current, up to date: require a current authoritative comparison appropriate to the task.
• clean, no issues found, nothing else is wrong: require explicit scope. Prefer bounded wording such as "I found no additional issues in the surfaces checked."
• all, every, none, only: require coverage broad enough to support the quantifier.

Safety and security claims

• safe, secure, no risk: avoid absolute wording unless the claim is narrowly defined and the evidence actually supports it. State the inspected controls, threat surface, and known unknowns instead.

Causal claims

• X caused Y: require evidence that distinguishes causation from timing, correlation, or plausible mechanism. If that evidence is absent, state the relationship as a hypothesis or inference.

See references/proof-obligations.md for the expanded contract.

Workflow

1. Identify material claims

Focus on claims that would change the user's understanding, decision, action, trust, or belief about completion.

Do not waste time verifying harmless connective prose.

2. Classify available evidence

For each material claim, determine whether support is observed, source-backed, user-reported, inferred, unknown, or contradicted.

A user instruction to assert a fact is not independent evidence for that fact.

3. Determine the proof burden

Match the strength of the wording to the evidence required.

Completion, freshness, exhaustive negatives, security, causal claims, exact numbers, and consequential factual assertions deserve a higher burden than ordinary descriptive language.

4. Perform the needed check when possible

Use an appropriate independent check against the relevant source, runtime, file, test, endpoint, repository state, output, or acceptance condition.

Do not call a repeated paraphrase of the same unsupported reasoning "verification."

If the evidence needed is available through an existing tool or source, inspect it before asking the user to repeat information.

5. Resolve unsupported claims

For every material claim that does not meet its burden, do exactly one of the following:

• verify it,
• weaken it to an explicitly supported inference,
• attribute it as user-reported,
• state the missing evidence,
• remove it.

Never bridge the gap with a plausible mechanism, invented implementation detail, or confident filler.

6. Handle conflicting evidence

When evidence conflicts:

• state the conflict,
• identify which source or observation is stronger and why when that can be justified,
• avoid collapsing disagreement into a single certain answer,
• preserve UNKNOWN when the conflict cannot be resolved.

7. Deliver the answer without verification theater

Do not dump an internal evidence ledger, confidence percentage, or ceremonial checklist unless the user asks for one or the task requires an audit-style report.

Keep normal answers normal. Surface uncertainty only where it matters.

User-Reported Facts

The user's own report can support statements about what the user said, experienced, observed, prefers, or did.

It does not automatically establish a universal external fact.

Examples:

• Supported: "You said the update failed after reboot."
• Not independently verified: "The update system is broken for everyone."

When the distinction matters, attribute the claim instead of laundering it into independent verification.