Grounds are part of the answer

When a household asks why Tuesday's dinner was marked impractical, "the model thought so" is not an answer anyone can check. A product team needs the same thing from a cognitive unit: claims about the case that a caller, evaluator, or human can verify or contest. Without those claims, reliability becomes theatre, fluency standing in for evidence, and approval becoming a click through uncertainty.

Grounds are not a nicety for power users. They are part of the return shape of a serious cognitive unit, the same way a typed API returns errors instead of only happy paths.

Helpful context: A contract, not a prompt defines what a cognitive unit returns. What is a cognitive unit names the artifact. Contestability explains why callers must be able to challenge results.

Why grounds matter

Without grounds, three architectural capabilities fail at once.

Contest fails. A household cannot object to Tuesday's verdict if the system offers no claims tied to calendar facts, endorsed knowledge, or candidate properties. They can only accept or abandon the product.

Evaluation fails. Graders and suites need stable objects to score, not model verbosity, but whether the cited provision, time estimate, or inventory fact matches the case materials. A finding without grounds is a label. A finding with grounds is a testable hypothesis.

Downstream cognition fails. The next cognitive unit in a chain cannot read a prior judgment, it can only receive a conclusion. Seam failures multiply when intermediate results carry verdicts without checkable support.

Authority also fails cleanly when grounds are thin. Referral and abstention depend on naming what is missing or who must decide. Grounds make deferral legible instead of arbitrary.

What grounds are, and what they are not

Grounds exist for checking, not for trusting. That distinction is load-bearing.

When a cognitive unit says a meal exceeds the household's busy-evening effort limit because active prep time is thirty-five minutes, you cannot conclude that thirty-five minutes is why the model decided as it did. The reasons may be assembled after the conclusion and look identical either way. You can open the recipe, time the steps, and establish whether thirty-five minutes is a fair claim. That is a different question, and a much more useful one.

Grounds are therefore not an audit trail. They are a set of checkable claims about material a person or checker can inspect: calendar entries, endorsed policy provisions, ingredient lists, purchase order lines, tolerance tables. They are never presented as proof of internal process.

A reasoning trace is something else entirely. Traces look like deliberation, consider alternatives, notice difficulty, revise, and reading them produces confidence. That confidence is hazardous because traces refer to internal events with no artifact to inspect. When a trace says "I considered whether a delivery note might exist," there is nothing to open. Grounds that cite provision 4.2 of a policy can be verified in thirty seconds. Never audit against a trace. If a decision must be auditable, grounds belong in the result shape as checkable claims about material, and traces remain debugging convenience with no evidential standing.

Grounds belong in the returns section of the contract, not as an optional narrative field the model may omit. For AssessMealPracticality, a minimal shape might be:

returns fit: {
  verdict: impractical | practical | marginal
  grounds: [
    { claim: text, source: calendar | knowledge | recipe | inventory }
  ]
}
| abstain: { missing: [text] }
| refer: { to: role, why: text }

Reviewers ask: for each ground type, what would a skeptical caller check? If the answer is "nothing," the ground is decoration. Grounds bind to evaluation cases, not to model length. A suite case for busy Tuesday asserts that grounds mention the busy flag and the effort threshold, not that the model wrote four paragraphs.

Grounds are part of the answer, not decoration.

The cognitive unit · Ch. 4

What this looks like in practice

The Meal Companion's busy-Tuesday fit cognitive unit might return three claims: Tuesday is flagged busy in evening_context.calendar, candidate meal traybake_lamb lists thirty-five minutes active prep in the recipe record, and endorsed household knowledge caps busy evenings at twenty-five minutes active effort.

Those claims can be checked against the calendar, recipe, and knowledge store. A household can contest: "Tuesday isn't busy this week, remove the flag." The system can patch without regenerating the entire plan.

Contrast with unusable outputs. "This meal doesn't feel practical for your lifestyle" is not checkable. A four-paragraph trace about considering slow roasts is not auditable. "Confidence: 0.82" is not a ground, because it does not say what would change the verdict. For invoice intake, credible grounds cite which line items mismatch, which policy clause applies, and which document fields were read, not "the explanation seems reasonable."

Grounds enable contest, graders, and seams

Contestability requires editable hooks. Grounds link to objects: calendar rows, knowledge records, plan versions. Contestability is structural UX built on architectural returns.

Graders are often cognitive units themselves. A grader reading "provision 4.2 supports tolerance" can verify the citation, or fail the answer if the provision says something else. Graders are not truth, but they need grounds to grade against.

Seams between cognitive units are where systems fail quietly. If CritiquePlan outputs weaknesses without grounds, RecommendMealSubstitution invents its own story about why Thursday failed. Named grounds at the seam reduce duplicated inference. Judge-library cognitive units read prior outputs. JudgeLocalRepairQuality needs to know why a weakness was named and what the patch changed, not that a patch exists alone. Grounds at upstream seams reduce silent reinterpretation.

When a cognitive unit cannot produce checkable grounds for its verdict class, that is architectural signal, not a prompt tuning problem. Either the decision is too thin to delegate yet (clarify inputs, abstain until filled), or the cognitive unit owns a judgment that returns refer rather than answer (policy not settled), or the team is asking for prose instead of claims (rewrite the return shape). Verdict-only outputs for consequential classes are a shipping risk, because a verdict without grounds cannot be argued with at all.

Thin grounds and abstention are one design habit. Chapter 4's tolerance example is the cautionary tale: empty policy documents still produce fluent findings with reasonable-sounding invented provisions unless the cognitive unit has somewhere to put "I have nothing to check against." When building AssessMealPracticality, the questions are: what claims would a caller verify, and what missing inputs would make those claims impossible?

Common mistakes

The most frequent failure is accepting traces as substitutes. Traces are free, long, and convincing. Organisations discover the problem during their first serious audit, months of decisions supported by narration with no checkable claims.

A close second is grounds as chain-of-thought dumps. More text is not more checkability. One cited provision beats three pages of process fiction. Grounds only in logs is equally damaging, because if grounds are not in the structured return, downstream code and UX cannot use them. Logging is not a contract. And evaluating fluency of grounds scores the wrong thing: whether claims match case material matters, not whether they sound professional.

These mistakes are predictable consequences of treating grounds as an afterthought. Each one is avoidable once grounds belong in the returns section of the contract and evaluation cases assert material accuracy rather than verbosity.

What to do next

For each cognitive unit, the grounds a skeptical caller would need to contest or verify the verdict belong as a typed grounds field in the contract before template wording tunes. Evaluation cases bind to material assertions, not verbosity thresholds. Trace-only auditing for consequential decisions fails the first time a regulator or household member asks for checkable evidence.

See contestability and abstention as a result.

Read next: Call, await, enforce.