Epistemic Mode Linter¶
Review-pass tool — instantiates Propositional Mode Governance
A tool or review pass that flags mode mismatches, such as treating an assumption as a verified fact or citing a conjecture as settled evidence.
An Epistemic Mode Linter scans an artifact, resolves it into propositions with their asserted or implied modes, and flags places where a proposition is used beyond what its mode licenses — an assumption stated as measured fact, a conjecture cited as settled evidence, a planned change written as though already true. Its distinguishing idea is that it is a detector, not a rulebook and not a record: it does not decide which operations a mode permits (it consults that ruleset) and it does not store the authoritative status of anything; it reads real text and surfaces the mismatches. Like a code linter, it turns a diffuse norm — "don't overclaim" — into concrete, located warnings an author can act on before publishing.
Example¶
A platform team runs an epistemic-mode linter over its internal API documentation and architecture knowledge base as a pre-publish check. It parses each page into claims and reads their tagged modes from the source. Two warnings come back. One page states "the rate limiter guarantees under 5 ms of added latency" as a flat fact — but the underlying figure is tagged in the design doc it draws from as a projected estimate, never measured in production; the linter flags a mode-use mismatch. Elsewhere an architecture diagram lists "service X reads from the new event bus" as a live dependency, when the migration is only a planned proposition still under review; the linter flags a hypothesis cited as fact. Neither is a typo or a broken link — each is a claim used above its epistemic warrant, and an editor now has a short, located list to fix before the docs ship and the overstatements propagate into everyone's mental model of the system.
How it works¶
The linter has a front end and a check. The front end resolves the artifact into propositional units and attaches each unit's mode — read from an explicit label where present, inferred from phrasing where not. The check compares how each unit is used against the operations its mode licenses, emitting a warning wherever use exceeds licence. It is deliberately a consumer of other mechanisms: the licensing rules come from a shared operation matrix, and the mode labels come from a labeling standard; the linter's contribution is binding those rules to real running text at scale. It comes in two forms — automated software over machine-readable docs and knowledge bases, or a human review pass driven by the same checklist of mismatch patterns.
Tuning parameters¶
- Automation level — fully automated over tagged text versus an assisted human review. Automation scales but only sees what it can parse; human review catches subtler misuse but does not scale.
- Strictness / false-positive tolerance — how aggressively it warns. Loose settings miss real drift; strict settings cry wolf until authors ignore the output.
- Inference aggressiveness — whether it checks only explicitly-labeled claims or also infers modes from phrasing. Inference widens coverage to the unlabeled majority but adds noise.
- Blocking vs advisory — whether a mismatch fails the publish/build or merely warns. Blocking enforces discipline but tempts authors to game the checker.
When it helps, and when it misleads¶
Its strength is scale: it catches mode drift across a corpus far larger than any reviewer can hold in their head, and it makes the archetype's flagship failure — label without license — actually detectable, because it looks for the gap between a stated mode and its real use. Its home error is the category mistake: presenting something as the wrong kind of thing, like citing a conjecture as if it were established evidence.[n1]
Its failure mode is false assurance. A clean pass means "no detected mismatches," not "all modes correct" — and a linter that only checks explicitly-labeled statements is blind to the unlabeled majority, so a green result over a lightly-tagged corpus is nearly meaningless. Over-strict linting has a perverse effect: authors strip labels to dodge the warnings, degrading the very metadata the check depends on. The guarding discipline is to read green as "no known violations," keep the ruleset it checks against and the label coverage honest, and treat the linter as one control among several rather than the guarantee. The linter runs an informal check against rules it is handed; it does not author those rules.
How it implements the components¶
propositional_unit_inventory— before it can check anything it resolves the artifact into discrete propositions with their modes; that extraction is its front end.misuse_and_drift_guardrail— its entire output is the guardrail: located flags for mode-use mismatch, drift, and hardening caught in the actual text.
It does not itself define which operations each mode licenses (licensed_operation_matrix) — that is Mode-Operation Matrix, its nearest twin, which the linter consumes as its rulebook: the matrix states the rules, and the linter finds where a proposition is used against them. Nor does it hold the authoritative record — the assignment bases and open obligations (mode_assignment_basis, obligation_register) — which is Epistemic Status Ledger.
Related¶
- Instantiates: Propositional Mode Governance — the linter is the enforcement pass that detects where mode and use have parted ways.
- Consumes: Mode-Operation Matrix supplies the licensing rules it checks against; Claim Status Labeling Standard supplies the labels it reads.
- Sibling mechanisms: Assumption Expiry Timer · Axiom Boundary Statement · Claim Status Labeling Standard · Decision Memo Epistemic-Mode Section · Epistemic Status Ledger · Hypothesis Promotion Gate · Mode-Operation Matrix · Premise Discharge Checklist · Proposition Lifecycle Board
Editorial Notes¶
Form Classification¶
Form family: Assessment, Review & Assurance
Rationale: Epistemic Mode Linter operates as a bounded evaluation of existing evidence or work that produces a finding or disposition because it a tool or review pass that flags mode mismatches, such as treating an assumption as a verified fact or citing a conjecture as settled evidence.
Independent corroboration: The frozen evidence defines Epistemic Mode Linter as 'A tool or review pass that flags mode mismatches, such as treating an assumption as a verified fact or citing a conjecture as settled evidence', so its operative form is Assessment, Review & Assurance.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Multi-domain
Rationale: Software linting supplies a pass that locates rule violations in an artifact without itself defining the rulebook or authoritative state.
Related originating lineages:
- Philosophy — Epistemology supplies the distinctions among fact, inference, assumption, hypothesis, and warranted use.
Review resolution: The current reviewers agree that computer_science is primary. For the reported differences (reported_ambiguity), the evidence supports cross_disciplinary_synthesis, multi_domain, and philosophy; these choices preserve materially formative origins without conflating later domain reach.
Attribution caveat: The mechanism deliberately transfers code-linter form to epistemic governance.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
[n1] A category mistake, in Gilbert Ryle's sense, is treating a thing as belonging to a logical type it does not — the error of expecting operations appropriate to one kind of thing from another. A mode mismatch is precisely this at the level of propositions: performing a fact-operation on a hypothesis, or an evidence-operation on a conjecture. ↩