Computational Fallacies in Spillway

The Computational Fallacies page names recurring ways intelligent systems can become confidently wrong. This companion page shows what those failures could look like inside Spillway and what the product is doing to reduce them.

No single safeguard is enough. Most of these problems are controlled by several layers at once: how evidence is stored, how uncertainty is preserved, what the AI is allowed to do, what requires confirmation, how testing is performed, and how much the system is allowed to learn from its own prior conclusions.

Status labels used here:

Implemented — a concrete protection exists in the repository now.
Partially implemented — some protections exist, but the full policy is not complete.
Designed / planned — the architecture has a defined direction, but production behavior is not complete.

Capability inference

Narcissus Fallacy

What failure would look like: Spillway trusts a fluent, human-sounding AI answer more than a terse deterministic result simply because it feels more intelligent.

Countermeasures: - Implemented: AI output is treated as a proposal, not as authority. A model can interpret evidence, but it does not get to authorize consequential actions. - Implemented: Spillway keeps source, confidence, reliability, and authority separate, so sounding persuasive does not itself increase evidentiary weight. - Implemented: deterministic observations and AI interpretations can both contribute without either being privileged for resembling human reasoning. - Implemented: consequential actions still require trusted application logic and, where appropriate, an explicit user decision.

Quacks Like a Duck Fallacy

What failure would look like: two models give the same category and Spillway assumes that agreement proves they used the same sound reasoning or supplied independent evidence.

Countermeasures: - Implemented: Spillway records where evidence came from, including model and prompt provenance, so similar outputs do not become indistinguishable. - Implemented: evidence that comes from the same underlying observation can be marked as related rather than counted as independent corroboration. - Implemented: a dependence-aware aggregation path can combine correlated evidence conservatively instead of simply adding it together. - Designed / planned: deeper ancestry tracking will extend this protection when one derived claim is built on another.

CSI Fallacy

What failure would look like: an email does not contain enough information to establish whether a date is really a deadline, but Spillway keeps applying more AI and eventually treats the result as though missing information had been recovered.

Countermeasures: - Implemented: the evidence model allows uncertainty, disagreement, and unknown values instead of forcing every question into a categorical answer. - Implemented: missing metadata means “not known,” not “certain” or “independent.” - Implemented: important model claims can be tied back to source evidence; unsupported output may fail visibly rather than quietly becoming fact. - Implemented: asking the user or declining to act is an acceptable outcome. High model confidence alone does not authorize consequential action.

Clever Hans Fallacy

What failure would look like: a classifier performs well because it learned a shortcut in the test data, and Spillway mistakes the score for evidence of general semantic understanding.

Countermeasures: - Implemented: mutation testing checks whether tests actually enforce the intended rule rather than merely passing while the rule is broken. - Implemented: wiring tests check that tested components are truly reached by production paths; a component can be correct in isolation and still be disconnected in the real app. - Implemented: extraction stages preserve task, model, prompt, and source-evidence information, making some shortcut behavior easier to inspect. - Implemented: automated test success and physical real-device acceptance are tracked separately. - Designed / planned: calibration work includes stratified audits, correspondence testing, and deliberate counterexample searches rather than relying on one headline score.

Tiger Mom Fallacy

What failure would look like: a newer model improves a benchmark score and Spillway assumes the underlying capability is universally better.

Countermeasures: - Implemented: model and prompt changes are versioned behavior changes rather than invisible replacements. - Implemented: historical observations and provenance remain available for comparison instead of being rewritten around the new model. - Implemented: release decisions distinguish automated correctness from real-device acceptance. - Designed / planned: task-specific calibration and drift checks will matter more than one aggregate benchmark.

Behavior, selection, and opportunity

What failure would look like: Spillway sees that the user opens messages from one sender quickly and concludes that the sender is intrinsically important.

Countermeasures: - Implemented: user behavior is recorded as observation, not as direct truth about preference. - Implemented: observations retain context such as event type, time, device class, subject, and—where meaningful—causal order. - Implemented: different behaviors remain different measurements rather than being collapsed into one generic “engagement” score. - Designed / planned: later behavioral learning is intended to infer contexts and regimes instead of treating one observed action as a stable preference.

What failure would look like: the user rarely handles a type of work on iPhone, so Spillway learns that the work is unimportant rather than recognizing that the phone may be a poor place to do it.

Countermeasures: - Implemented: device context is preserved, but device identity by itself is not allowed to stand in for user intent. - Implemented: feasibility and opportunity are modeled separately from importance and urgency. - Implemented: several time- and opportunity-related concepts remain distinct rather than collapsing “could not act” into “did not care.” - Designed / planned: future behavioral regimes can incorporate input method, layout, session, and interaction context instead of assuming one device equals one preference state.

Survivor Fallacy

What failure would look like: Spillway evaluates triage quality only on messages it surfaced, while messages hidden by its own policy never receive labels and disappear from evaluation.

Countermeasures: - Implemented: histories of observations and decisions are preserved rather than retaining only the current visible projection. - Implemented: causal order and wall-clock time are kept separate where a genuine causal sequence exists. - Designed / planned: evaluation is intended to use stratified and targeted samples rather than only naturally observed outcomes. - Known gap: fully selective-label-aware calibration is not yet complete.

What failure would look like: Spillway highlights a message as important; the user responds because it was highlighted; the response is then counted as proof that the original importance judgment was correct.

Countermeasures: - Implemented: system decisions and later user behavior are stored as separate events rather than one self-validating field. - Implemented: causal ordering can be represented separately from mere chronological order. - Implemented: human decisions, AI proposals, and derived state remain distinguishable. - Designed / planned: future calibration must treat outcomes produced after Spillway intervened differently from clean counterfactual evidence.

Measurement and optimization

MBA Fallacy

What failure would look like: Spillway optimizes inbox-zero because it is easy to measure even while the user starts missing consequential work.

Countermeasures: - Implemented: the top-level product objective is reducing wasted attention, repeated scans, unnecessary decisions, and context switching—not maximizing throughput. - Implemented: confidence and the decision to interrupt the user are separate questions; a confident inference does not automatically imply silent action. - Implemented: work projections retain lifecycle and consequence semantics rather than optimizing a single inbox metric. - Designed / planned: calibration is intended to consider completed work, errors, undo rates, trust, attention cost, and downstream consequences.

Streetlight Fallacy

What failure would look like: Spillway focuses on whatever is easiest to instrument while ignoring harder-to-measure failures such as misunderstood obligations or latent tasks.

Countermeasures: - Implemented: the architecture deliberately preserves facts and metadata that may not have an immediate consumer because they would be impossible to reconstruct later. - Implemented: scope, dependence, provenance, and diagnostic value are recorded even when they are not immediately convenient to score. - Implemented: manual testing covers real-device, external-service, and user-visible behavior that automated telemetry cannot establish. - Designed / planned: future audit sampling is intended to follow decision value, uncertainty, drift, and consequence rather than instrumentation convenience.

Circus Statistician Fallacy

What failure would look like: a model is 97% accurate overall, so Spillway automatically acts on a high-impact message even though the evidence for that particular message is weak or contested.

Countermeasures: - Implemented: case-level beliefs preserve support, competing interpretations, and uncertainty. - Implemented: review requirements are separate from overall model accuracy and can require confirmation for a particular case. - Implemented: several work projections already use stronger review for consequential cases. - Partially implemented: the generic review policy still has places where consequence sensitivity is less complete than the architecture intends.

Fundraising Fallacy

What failure would look like: Spillway optimizes for immediate confirmations and gradually trains users to rubber-stamp prompts, reducing long-run trust and correction quality.

Countermeasures: - Implemented: there is no universal AI confirmation queue; low-stakes, high-confidence outcomes can remain quiet and reversible rather than maximizing prompts. - Implemented: attention cost is an explicit product concern. - Implemented: confirmation, correction, dismissal, and ordinary behavior remain distinguishable instead of becoming one “engagement” reward. - Designed / planned: longer-run calibration should consider fatigue, trust, correction quality, and trajectory effects.

Evidence, dependence, and validation

Echo Chamber Fallacy

What failure would look like: three signals all ultimately come from the same sentence in one email, but Spillway counts them as three independent reasons to believe the same conclusion.

Countermeasures: - Implemented: simple restatements collapse instead of accumulating a fresh vote every time the same evidence is processed again. - Implemented: observations can record that they share the same underlying source event. - Implemented: missing dependence information means “we do not know,” not “these are independent.” - Implemented: a dependence-aware aggregation path can prevent several correlated observations from adding up like independent evidence. - Implemented: aggregation policy is versioned and replaceable, so stronger dependence handling can be introduced without rewriting the underlying observations. - Implemented: a claim records the specific earlier observations it rests on, separately from which processing run produced it, so dependence can be followed through repeated rounds of derivation rather than only one. - Designed / planned: deeper recursion will have to be earned from human-derived grounding rather than from the system's own repeated conclusions.

Rubber Stamp Fallacy

What failure would look like: one AI suggests Work, another stage sees that suggestion and agrees, and Spillway treats the agreement as a second independent observation.

Countermeasures: - Implemented: translating or consuming an earlier judgment does not automatically create new human authority. - Implemented: explicit human decisions come from authored decision records rather than being inferred because a machine judgment survived downstream processing. - Implemented: derived conclusions remain below human decisions in authority and cannot promote themselves by passing through another subsystem. - Implemented: dependence tracking can keep several interpretations of one source observation from adding up independently. - Implemented: a later judgment names the earlier ones it depends on, so agreement that is actually a descendant of the original judgment is recognisable as such rather than looking like a second opinion.

Elon Musk Fallacy

What failure would look like: a model agrees because the prompt strongly suggests the answer, and Spillway treats the agreement as independent validation.

Countermeasures: - Implemented: model and prompt provenance are recorded separately from the claim itself. - Implemented: prompts and model responses are treated as untrusted inputs, not as authorization. - Implemented: trusted application code, not the model, assigns provenance and authority. - Designed / planned: dependence-aware calibration can discount agreement produced under the same framing or upstream judgment.

Fine by Me Fallacy

What failure would look like: the user clicks “Confirm” after seeing an AI suggestion and Spillway treats that exactly like the user independently supplying the same answer without being shown the suggestion.

Countermeasures: - Implemented: the human-evidence path can record what the user had already been shown at the moment of confirmation, because that exposure cannot be reconstructed later. - Implemented: user confirmation and correction remain distinct from machine evidence. - Implemented: human confirmation carries strong authority but is not encoded as infallible truth. - Implemented: a person volunteering an answer and a person agreeing with one Spillway offered are now recorded as different things, and an agreement records which suggestion it answered — so a hundred agreements with one suggestion cannot be mistaken for a hundred independent human judgments.

Established Campsite Fallacy

What failure would look like: an early classification changes how mail is organized; later learning observes that organization and mistakes repeated use of the earlier choice for independent proof that the choice was right.

Countermeasures: - Implemented: source observations, semantic evidence, authored decisions, and derived projections remain separate rather than collapsing into one overwritten label. - Implemented: provenance can preserve when later records descend from earlier system outputs instead of independent source facts. - Implemented: historical decisions remain replayable history rather than silently becoming fresh observations. - Implemented: a conclusion cannot support itself, however long the chain of reasoning between it and itself; support is traced outward from independent starting points, so a loop reaches nothing. - Implemented: a claim whose supporting evidence is later withdrawn stops counting rather than surviving as a free-standing fact. - Designed / planned: how far the system may reason in an area will have to be earned from human-derived grounding for that area, and will be able to contract when human corrections show it was wrong.

Charismatic Leader Fallacy

What failure would look like: a generally reliable model or trusted sender is treated as authoritative across unrelated claims simply because it has been right before.

Countermeasures: - Implemented: authority and empirical reliability are separate concepts. - Implemented: how informative an observation is can vary by claim rather than becoming a universal property of the source. - Implemented: reliability policy can vary by source and semantic facet instead of treating reputation as global truth. - Implemented: unfamiliar future authority levels fall back conservatively rather than silently inheriting enormous evidentiary weight.

Representation, provenance, and uncertainty

Telephone Game Fallacy

What failure would look like: an extractor says “possibly a deadline,” a later stage stores “deadline,” and the interface eventually presents it as fact with no remaining uncertainty or source trail.

Countermeasures: - Implemented: source artifacts, observations, semantic evidence, derived beliefs, projections, and authored decisions are kept as separate layers. - Implemented: evidence retains information about where it came from, how certain it was, its scope, and—where available—what source material supported it. - Implemented: model outputs for important tasks can be required to point back to source evidence rather than supplying unsupported free-text conclusions. - Implemented: belief is recomputed under a versioned policy instead of being persisted as timeless truth. - Implemented: a derived claim becomes non-current the moment the evidence it required is withdrawn — it is dropped rather than quietly discounted, so nothing survives as a fact whose basis has gone.

Confidence Laundering Fallacy

What failure would look like: a moderately uncertain AI inference becomes a category label, then a synced field, then an apparently certain fact on another device.

Countermeasures: - Implemented: observational certainty, diagnostic value, authority, and aggregation weight are kept distinct rather than compressed into one score. - Implemented: synchronization transports provenance and authority rather than inventing new authority merely because data crossed devices. - Implemented: the model cannot choose its own authority, identity, operation type, or provenance. - Implemented: unknown durable values are handled conservatively rather than being mapped to a familiar stronger meaning. - Implemented: the interface distinguishes machine proposals from explicit human decisions. - Implemented: Spillway now preserves a stance it does not recognise exactly as written and counts it in neither direction, instead of guessing. The build before it would have read a future "the user says no" record as a positive assertion of the very thing being rejected, and a reader that behaves safely has to be installed before anything writes such records — so the two are deliberately shipped a release apart.

Good Enough Fallacy

What failure would look like: a sender-level shortcut that works well enough for triage is later reused as though it were precise enough to establish project membership or task responsibility.

Countermeasures: - Implemented: independent semantic dimensions remain separate rather than being collapsed into one universal label. - Implemented: evidence records the scope at which it was actually observed, so later features do not have to guess how broadly it should generalize. - Implemented: task-specific evidence and proposal formats prevent one convenient representation from becoming the API for every downstream purpose. - Implemented: related time concepts such as urgency, feasibility, and rigidity remain distinct, with tests preventing them from quietly becoming synonyms.

Voodoo Doll Fallacy

What failure would look like: changing Spillway's internal representation of a task is treated as though the underlying external obligation itself changed.

Countermeasures: - Implemented: external systems remain systems of record; Spillway preserves their source identity and permissions. - Implemented: internal projections are recomputable derived state, not external truth. - Implemented: consequential external changes require explicit domain commands and user authorization rather than happening because an internal belief changed. - Implemented: inferred properties and authored decisions remain separate.

Pay No Attention Fallacy

What failure would look like: a model generates a plausible explanation for why something was categorized, and Spillway presents that narrative as though it were the actual causal process that produced the decision.

Countermeasures: - Implemented: explanations can be grounded in recorded evidence and provenance rather than relying only on a model-generated story. - Implemented: many extraction paths retain source pointers or supporting identifiers that can be inspected later. - Implemented: generated rationales are treated as untrusted model output, not privileged causal access. - Implemented: several domains retain structured explanations of what evidence or rule supported a projection instead of only free-form prose.

Trusty Old Map Fallacy

What failure would look like: a sender-project relationship learned months ago keeps dominating after the sender changes roles or the project ends.

Countermeasures: - Implemented: evidence retains time information separately from claim identity. - Implemented: supersession and withdrawal can preserve history while removing old assertions from the current view. - Implemented: learned and empirical rules are treated as revisable hypotheses with audit, demotion, and replacement paths. - Implemented: aggregation policy can change and recompute over preserved observations. - Designed / planned: calibrated temporal decay, especially for derived evidence, belongs to the next weighting/calibration layer.

Fairness, privacy, and derivation

What failure would look like: Spillway omits a sensitive attribute but relies on strongly correlated proxies and then assumes the resulting model is substantively independent of that attribute.

Countermeasures: - Implemented: provenance and feature/source distinctions make it possible to audit where a signal came from instead of treating a final score as self-explanatory. - Implemented: local-first data policies reduce unnecessary transport of behavioral and observational data. - Designed / planned: correlation-aware evaluation is required; simply removing an explicit field is not treated as proof that its influence disappeared. - Known gap: Spillway does not yet claim a complete fairness-audit framework for every future learned feature.

Ship of Theseus Fallacy

What failure would look like: several individually harmless observations are combined to infer a private relationship or identity that was never explicitly supplied.

Countermeasures: - Implemented: different classes of data—source material, observations, derived knowledge, projections, and sync state—have different storage and transport rules. - Implemented: raw behavioral observations stay local; moving summaries across devices requires an explicit benefit, privacy, and storage justification rather than happening automatically. - Implemented: derived information is treated as its own privacy concern rather than assuming only raw fields can be sensitive. - Designed / planned: future cross-device summaries must consider what combinations of fields could reveal, not only whether each field looks harmless alone.

Vanilla Ice Fallacy

What failure would look like: a summary is treated as independent knowledge simply because its wording differs from the email it came from.

Countermeasures: - Implemented: transformed evidence retains source and provenance rather than becoming independent merely because it was rewritten. - Implemented: related interpretations can record that they share the same underlying source. - Implemented: derived projections remain derived and recomputable instead of becoming new canonical source artifacts. - Designed / planned: recursive support ancestry will prevent long chains of transformation from manufacturing new independent roots.

Human-technology interaction and deployment

Roomba Fallacy

What failure would look like: Spillway's persistent task prioritization is described as though the system literally “wants” the user to do something.

Countermeasures: - Implemented: the architecture represents evidence, policies, beliefs, projections, and decisions without treating machine behavior as subjective intention. - Implemented: model proposals remain distinct from user intent and human authority. - Product discipline: explanations can say why something was surfaced without anthropomorphizing the system.

Field of Dreams Fallacy

What failure would look like: a technically impressive triage feature is declared successful even though users avoid it because it interrupts their workflow or feels untrustworthy.

Countermeasures: - Implemented: physical/manual acceptance is an explicit gate separate from unit and simulator tests. - Implemented: real TestFlight/device workflows are used to validate interaction and cross-device behavior before product claims are widened. - Implemented: real-device and external-service gaps remain in the user-testing queue rather than disappearing behind green automated tests. - Implemented: the design principles optimize workflow fit and attention, not demo capability.

New Homeowner Fallacy

What failure would look like: because AI can draft a reply or identify a task, Spillway assumes the user no longer needs domain judgment about whether the result is appropriate.

Countermeasures: - Implemented: consequential actions remain human-controlled, and proposals or drafts are distinct from execution. - Implemented: model output cannot directly send, delete, invoke connectors, or choose authority-bearing operations. - Implemented: explicit user actions are required to turn proposals into human decisions. - Implemented: source material remains available even when AI assistance is unavailable or wrong.

Cover Page Fallacy

What failure would look like: polished summaries or attractive UI make an inference feel correct even though the underlying evidence is weak.

Countermeasures: - Implemented: evidence quality, provenance, contest, and review requirements are independent of presentation quality. - Implemented: model-generated strings are inert by default; persuasive wording does not create action authority. - Implemented: automated tests, mutation tests, physical validation, and observed behavior are treated as separate evidence from interface polish. - Implemented: explanations are intended to point back to recorded evidence rather than simply sound convincing.

Labor, law, governance, and futures

McKinsey Fallacy

What failure would look like: because Spillway automates one recurring email task, its designers infer that the corresponding human role is broadly automatable.

Countermeasures: - Design discipline: Spillway models tasks, obligations, people, workflows, constraints, and external systems separately, which resists turning task competence into an occupation-level claim. - Product scope: automation claims are tied to tested workflows rather than labor-market forecasts. - Known boundary: this is mainly a reasoning and governance safeguard rather than a runtime mechanism.

One Exception Fallacy

What failure would look like: one bizarre misclassification causes a generally useful rule to be discarded without considering its overall performance or the alternatives.

Countermeasures: - Implemented: empirical rules have audit, revision, demotion, and replacement paths rather than permanent keep/delete status. - Implemented: uncertainty can be localized to a case rather than forcing one exception to overturn an entire rule. - Designed / planned: representative and consequence-weighted evaluation will judge rules across more than salient anecdotes. - Counterweight: Black Swan handling separately prevents “do not overreact to one exception” from becoming “ignore catastrophic rare failures.”

Black Swan Fallacy

What failure would look like: a rare but catastrophic filing or external-action error is dismissed because its average frequency is tiny.

Countermeasures: - Implemented: high-impact outbound, destructive, and cross-system actions require explicit human authorization regardless of model confidence. - Implemented: review policy is separate from probability; a low-frequency but consequential case can still demand confirmation. - Implemented: output and resource limits reduce blast radius when inference fails. - Implemented: unknown or incompatible sync operations are quarantined instead of being silently acknowledged and compacted away.

Insider Trading Fallacy

What failure would look like: a classifier is evaluated using future replies, later thread outcomes, or metadata that did not exist when the original decision had to be made.

Countermeasures: - Implemented: observations retain event time and, where appropriate, causal position. - Implemented: provenance records what evidence an inference actually consumed rather than preserving only the later conclusion. - Implemented: staged model tasks receive scoped evidence rather than unrestricted mailbox state. - Designed / planned: evaluation policy explicitly requires respecting the information boundary that existed at decision time; automatic leakage auditing remains future work.

Old Dog Fallacy

What failure would look like: a rule that worked under an old provider, device pattern, or model is assumed to remain valid after the environment changes.

Countermeasures: - Implemented: model, prompt, and package versions make changes in the environment attributable. - Implemented: empirical rules have audit and revision lifecycles rather than permanent authority. - Implemented: physical release testing distinguishes provider/device behavior from abstract unit correctness. - Designed / planned: drift and correspondence sampling can trigger recalibration when the environment changes.

Greener Grass Fallacy

What failure would look like: Spillway compares its ordinary failures with only the most impressive examples from another AI product and concludes that the other architecture is categorically superior.

Countermeasures: - Design discipline: comparisons should use common tasks, denominators, privacy constraints, latency, attention cost, reversibility, and failure consequences rather than showcase anecdotes. - Implemented: the project distinguishes automated, simulated, and physical evidence, which reduces comparisons between unlike validation levels. - Known boundary: this is chiefly an evaluation discipline, not a runtime subsystem.

NPC Fallacy

What failure would look like: Spillway learns user behavior under one ranking policy and assumes the user will behave the same way after the ranking itself changes what the user sees and does.

Countermeasures: - Implemented: behavior is recorded as contextual observation rather than permanent preference truth. - Implemented: event kind, device context, and causal ordering allow later analysis to distinguish behavior produced under different circumstances. - Implemented: policies and projections can change without rewriting historical observations to fit the new policy. - Designed / planned: future behavioral-regime learning and calibration are intended to account for policy-dependent opportunity and feedback.

Science Fiction Fallacy

What failure would look like: a plausible story about recursive personal AI steadily becoming autonomous is treated as a forecast instead of a scenario.

Countermeasures: - Implemented: roadmap and release documentation distinguish shipped, physically validated, planned, and speculative capability. - Implemented: recursive inference is being designed around explicit evidence lineage and authority rather than being assumed safe because the architecture can technically support it. - Designed / planned: deeper recursion will be earned locally from human-derived grounding rather than assumed from the maturity of the software as a whole.

A special cross-cutting defense: earned recursion

Several fallacies become much more dangerous when a system is allowed to learn from its own previous inferences: Echo Chamber, Rubber Stamp, Established Campsite, Telephone Game, Confidence Laundering, Fine by Me, Trusty Old Map, and NPC in particular.

Spillway's intended defense separates two questions.

How far may the system recurse in this area? Permission should depend on the amount and quality of human-derived grounding for that particular category, outcome, or claim family.
Given that depth, what should the system conclude? Once a depth is permitted, all admissible evidence may contribute, including deterministic and machine-derived evidence, subject to dependence, validity, authority, and later calibration policy.

Machine-derived evidence, repeated restatements, recursive descendants, and synced copies must not earn permission for deeper recursion. That means a new user or a newly created category begins conservatively even if the software is globally capable of deeper recursive inference.

This principle works together with several existing protections:

repeated processing should not create repeated votes;
evidence known to share one underlying source should not masquerade as independent corroboration;
moving evidence between devices should not increase its authority;
descendants should eventually stop counting when their required support disappears;
a human independently supplying an answer can be distinguished from a human merely confirming an AI suggestion;
stale or repeatedly recycled machine-derived evidence can later be discounted by calibration policy.

If a user sees that a whole category or area has become error-ridden, Spillway should eventually provide a circuit breaker for that area: temporarily reduce recursive influence, return to surviving human and root evidence, re-derive the affected conclusions, remove or recompute contaminated descendants, and require deeper recursion to be earned again from subsequent human grounding.

This is meant to be a permanent cold-start safety property, not just a development-phase restriction. Mature software does not imply that a brand-new user's local model is mature.

What is not solved yet

This page is not a claim that Spillway has eliminated every fallacy. The current picture is roughly:

Strongly represented today: provenance and authority separation, semantic scope, repeated-evidence collapse, dependence tracking for shared observations, typed proposal validation, human-versus-AI authority, reversible current projections, physical validation discipline, and data/privacy boundaries.
Partially implemented and being strengthened: recursive lineage and validity, consequence-aware review, independent-human versus model-exposed confirmation, category-level re-derivation, and broader dependence-aware aggregation.
Mostly future calibration/evaluation policy: recursion thresholds, temporal decay, full correlation-aware weighting, selective-label and counterfactual evaluation, drift sampling, fairness auditing, and automatic leakage detection.

For a new feature, the useful engineering question is therefore not “does Spillway claim to avoid this fallacy?” but:

If this feature violated the fallacy, what observable failure would we expect, which existing protections would constrain it, what test could falsify those protections, and what gap would remain?

That turns the fallacy catalog into a design, review, and testing discipline rather than just terminology.

Computational Fallacies · From Data to Knowledge · The Ideas Behind Spillway · Explainable AI

Documentation provenance: Iterative human-AI construction. See Documentation Provenance.