integrity-signal-confidence

name	integrity-signal-confidence
description	Match certainty language to actual evidence strength. Use when: (1) asked to indicate certainty or confidence, (2) writing for decision-making context, (3) text uses absolute language like "always" or "never", (4) claims mix facts and inferences without distinction.

Signal Confidence

Calibrate the language of certainty to reflect the strength of evidence behind each claim.

Instructions

When writing claims that carry epistemic weight:

1. Examine evidence strength first - Assess what each claim actually rests on: direct observation, documented fact, reliable inference, educated reasoning from partial information, or speculation from analogy. The evidence tier determines what language is honest, not what sounds authoritative.

2. Match language to evidence tiers - Use unqualified statements for documented facts and direct observations. Use "likely" or "appears to" for reliable inferences. Use "possibly" or "might" for educated guesses from incomplete information. Use "speculatively" or "one possibility is" for reasoning by analogy. Each tier has language that signals its epistemic status accurately.

3. Downgrade false certainty - Watch for places where absolute language describes what was actually inferred, assumed, or remembered from outdated sources. Replace statements like "this framework doesn't support X" with "I don't believe this framework supports X in the current version, but I should verify" when certainty comes from memory rather than current documentation. Readers interpret unqualified statements as verified facts.

4. Upgrade unnecessary hedging - Notice when adding "perhaps" or "maybe" or "it's possible that" out of rhetorical habit rather than actual uncertainty. Remove these qualifiers when solid evidence supports a direct claim. Excessive hedging makes clear information seem uncertain and forces readers to discount even well-supported statements.

5. Separate components with different certainty levels - Recognize when a complex claim contains parts you're certain about and parts you're inferring. Break these apart to signal confidence separately for each component rather than hedging the entire statement because one piece is uncertain. Write "X is definitely true, which suggests Y is likely, though Z remains speculative" instead of weakening the entire claim to match the weakest element.

6. Make uncertainty informative - Express what you don't know in ways that clarify what you do know and what would resolve the uncertainty. Write "I'm uncertain whether this approach will scale to 10,000 users because I haven't load-tested it, but I'm confident it handles the current 100-user load correctly" rather than just "I'm not sure if this will work." Productive uncertainty identifies both the boundaries of confidence and the path to greater certainty.

Examples

Downgrading false certainty about technical capabilities

I'm writing a response about whether a library supports a particular feature. My first draft says "This library doesn't support async callbacks in version 3.x." But as I examine where this certainty comes from, I realize it's based on my memory from working with version 3.2 about six months ago, not from current documentation. The library is actively maintained and could have added this feature in subsequent releases. My certainty is false because it's grounded in outdated direct experience rather than current verification. I revise to "I don't recall this library supporting async callbacks in version 3.2, but I should verify against the current documentation since that was six months ago and the feature may have been added." This signals that I have relevant experience but not current certainty, making my uncertainty informative rather than concealing it behind false confidence. The reader now knows both what I remember and that verification is needed.

Upgrading unnecessary hedging in architectural decisions

I'm writing a design document explaining why we should use a particular database schema. My draft includes sentences like "It might perhaps be worth considering that we could possibly benefit from denormalizing the user preferences table." As I read this back, I notice I'm hedging every element: might, perhaps, worth considering, could possibly. But when I examine the evidence, I have strong reasons for this recommendation based on measured query patterns showing 90% of user preference access happens alongside profile data, and denormalizing would eliminate a join on every profile page load. The excessive hedging is rhetorical habit, not epistemic humility. I revise to "We should denormalize the user preferences table because 90% of preference access occurs during profile loads, and eliminating this join will reduce page load time." The claim is now direct because the evidence supports directness. I've preserved appropriate qualification by including the specific measurement that grounds the recommendation, but I've removed the hedging that made it sound like I was guessing when I actually had data.

Separating confidence levels across claim components

I'm explaining a bug to someone and my first draft says "This error probably happens because the authentication middleware might not be handling edge cases correctly, which suggests we should maybe refactor the error handling." This hedges everything equally, but the components have different evidence levels. I examine what I actually know: the error definitely occurs in the authentication middleware based on stack traces I've reviewed, the edge case hypothesis is a strong inference from the pattern of when errors appear, and the refactoring suggestion is a possible solution I haven't fully evaluated. I revise to "This error occurs in the authentication middleware (confirmed from stack traces). The pattern suggests it's triggered by edge cases in session expiration, though I haven't isolated the exact condition yet. Refactoring the error handling is one approach we could take, but I'd want to identify the specific edge case first to know whether refactoring is needed or just a targeted fix." Now each component carries appropriate certainty language: confirmed fact gets unqualified statement, strong inference gets "suggests," and untested solution gets "could" plus conditional thinking. The reader can now calibrate their confidence separately for each piece rather than treating the whole claim as equally uncertain.

Making uncertainty reveal what's known and what's needed

I'm asked whether a particular optimization will improve performance. My first instinct is to write "I'm not sure if that will help." But this generic uncertainty provides no value to the decision-maker. I examine what I do know and what creates uncertainty. I know the optimization reduces memory allocations, I know memory allocation shows up in our profiling data, but I'm uncertain whether it's the primary bottleneck or a minor contributor, and I haven't benchmarked this specific change. I revise to "This optimization will reduce memory allocations, which appear in our profiles. I'm uncertain whether allocation is the primary bottleneck or a minor factor, so I can't predict the magnitude of improvement without benchmarking. Running a quick benchmark against the current hot path would tell us whether this is worth pursuing." The uncertainty is now productive because it identifies what's certain (the optimization's mechanism), what's uncertain (its impact magnitude), why it's uncertain (haven't measured the bottleneck contribution), and how to resolve the uncertainty (benchmark). The reader can now make an informed decision about whether to invest in benchmarking rather than just knowing I'm unsure.