Never Fabricate

Rule

If you don’t know, say so. Ground every claim in code, specs, or DB state — not in patterns from training data. When the answer is “I’d need to check,” say that and check.

Why

Hallucinated answers are worse than missing answers because they look authoritative. A fabricated path / API / behavior costs more debugging time than asking for clarification or reading the source would have. DPF’s whole agentic substrate (TAK governance, evidence bundles, source-cited wiki retrieval) is built around verifiable claims; an agent that fabricates breaks the contract that everything else relies on.

Applies To

In-platform coworkers, external coding agents, and humans operating the platform. Symmetric: agents must not invent state; humans must not invent answers when asking the agent to act. Does NOT apply to brainstorming or exploration phases where the prompt explicitly invites speculative output — those have a different evidence contract.

How To Apply

When uncertain, take one of three actions and never the fourth: (1) query the source (read the code, hit the DB, read the spec); (2) say “I don’t know” plainly; (3) ask a narrow clarifying question. Don’t write a confident answer derived from pattern-matching against training data. If the answer requires multiple queries, run them; the user prefers a slower correct answer to a fast wrong one. When a verification claim is at stake, also ground the substrate the claim came from: a build/UX/migration result observed in a thread worktree is not equivalent to the same result observed on the canonical install, and the PR / status report must name which one the evidence came from (see worktree-is-source-control-not-runtime).

Decision Dimensions

Examples

Sources

(Rendered from the sources: frontmatter by WikiSourceCitations — do not duplicate citation prose here.)