The Five-Challenge Refutation Harness

A system that only prevents fabrication is still lying to you by omission. A system that prevents fabrication and omission is still lying to you by distortion. There are exactly five ways a truthful claim can be false, and R6 requires you to check all of them.

ℹPrerequisites▼

Before reading this chapter, you should be comfortable with: Chapter 12 (Adversarial Validation). The five challenge types are the taxonomy that organizes the adversarial harness introduced in Chapter 12.

The refutation block is Canon's most uncomfortable requirement. The witness block says what was observed. The findings block says what was concluded. The refutation block says here is the adversarial pressure we applied to those conclusions, and here is why we are still standing.

Most evidence systems stop at the findings block. Canon does not, because stopping at findings is how you get a court record that is technically accurate and substantively misleading. The refutation block exists to make that combination visible — and falsifiable.

This chapter describes the five challenge types, why each one is irreducible to the others, how Tri-Model Consensus (TMC) generates verdicts, and why the coverage.declined inventory is as important as the challenges that ran. ## At a glance - The five challenge types are orthogonal: FABRICATION, OMISSION, DISTORTION, TEMPORAL_ERROR, and ATTRIBUTION_ERROR each address a distinct failure mode, and optimizing for one does not reduce the probability of the others. - 2-of-3 model consensus is the aggregation rule: three independent challenger models each produce a verdict, and the majority outcome becomes the challenge result, with minority dissents logged rather than discarded. - Declined coverage is a required disclosure, not an opt-out: every challenge type absent from challenges[] must appear in coverage.declined[] with a non-empty reason string, and the reason itself is a falsifiable claim the recipient can contest. ## Learning objectives By the end of this chapter you should be able to: 1. Write a challenge_text (the input field) for each of the five challenge types against a given claim, specifying the adversarial question that distinguishes that challenge from the others. 2. Explain why OMISSION and DISTORTION are not the same challenge: construct a concrete example where FABRICATION and DISTORTION both pass but OMISSION finds a material gap. 3. Implement 2-of-3 aggregation: given three model verdicts, determine the consensus outcome, identify when the result is contested, and explain what contested means for the attestation's validity. 4. Populate a coverage object with applied and declined entries for a binary factual claim, writing a specific and falsifiable reason string for each declined challenge type. ## The problem the harness solves A challenge is a structured adversarial probe aimed at a specific claim, asking a specific question about a specific failure mode. Peer review asks "is this sound?" A challenge asks "does this specific mechanism of error apply to this specific claim?" Different failure modes require different probes. An adversarial prompt designed to catch fabrication will not catch omission. A counter-evidence retrieval designed to catch omission will not catch distortion. The five types are not five names for "challenge harder"; they are five orthogonal axes. The Canon R6 requirement (Canon §7) says every attestation's refutation block must contain: - challenges[]: at least one applied challenge entry. - coverage.declined[]: every challenge type that was not applied, each with a specific reason string. The requirement treats absence as something that must be accounted for. A challenge type that does not appear in challenges[] must appear in coverage.declined[]. There is no third option. > § For the Record — Canon R6. > > "Every Attestation MUST include a Refutation block containing at least one > Challenge entry and a Coverage object enumerating every ChallengeType not > applied, each with a non-empty reason string. A missing challenge type with > no declined entry is a conformance violation." ## The five types ### FABRICATION The question: Does the cited evidence actually support this claim? A FABRICATION challenge tests whether the claim asserts something that is not present in the observations the attestation's witness block cites. This is the most intuitive failure mode — the claim says something happened, and the evidence says otherwise — but intuition can mislead. The challenge is not whether the claim sounds plausible. It is whether the cited observations actually contain the supporting content the claim requires. This distinction matters because a model generating claims from retrieved evidence can misattribute. It retrieves a document about caseworker visits in February, constructs a claim about caseworker visits in February, and cites the document — but the document discusses a different February, a different caseworker, or a different family. The claim is not invented from whole cloth; the evidence does exist; but the specific content the claim requires is not in the cited source. That is fabrication. The FABRICATION challenge prompt presents the claim and the literal content of the cited witness entries and asks the challenger model: Given only this content, does this claim follow? A FABRICATION challenge is not asking whether the claim is true in the world. It is asking whether it is supported by the stated evidence. ### OMISSION The question: What material context is in the observations but not in the claim? Omission is the failure mode where every word of the claim is true and the claim is nonetheless misleading. The caseworker visited seven times in January. The claim says the parent missed two scheduled visits. Both facts are in the same document. The claim does not lie; it selects. If the ratio of attendance to absence changes the meaning — if five successful visits makes two absences look different than two absences standing alone — the omission is material. A FABRICATION challenge will not catch this. The claim is supported by the evidence; FABRICATION passes. A DISTORTION challenge, which asks about characterization, will not catch this either, because the claim makes no characterization beyond "missed two visits." OMISSION is its own axis. The OMISSION challenge presents the claim and the full witness content and asks: What material context does this content contain that does not appear in the claim and that would change its meaning? The challenger model is looking for what was left out, not for what was added. ### DISTORTION The question: Does the characterization match the evidence? Distortion is the failure mode where the observations are accurately cited and fully represented, but the claim's language characterizes their significance or severity incorrectly. An OMISSION challenge asks whether the right facts are there. A DISTORTION challenge asks whether those facts are framed correctly. The parent "did not respond" to a caseworker's message. The record shows: the message was sent to an email address that had been deactivated six days earlier. The claim accurately states the response did not arrive. The omission of the deactivated address is caught by OMISSION. But a separate DISTORTION challenge asks: does "did not respond" accurately characterize the nature of the failure? Or is the accurate characterization "a communication was attempted through an invalid channel, and no response arrived"? The semantic weight of "did not respond" implies an actor who chose silence; the accurate weight of the evidence implies an actor who could not receive the message. Distortion is the failure mode that matters most in evaluative claims — claims about parental fitness, professional conduct, institutional negligence — where the facts themselves are undisputed but their characterization determines the outcome. ### TEMPORAL_ERROR The question: Is the timeline correct? Temporal errors are discrete. They are not a matter of framing or context; they are a matter of what the dates in the cited evidence actually say. A claim can be entirely accurate in substance and entirely wrong in time, and the time error can determine whether the claim is legally relevant. An assignment period ran from February 7 to March 29. The claim states "January through March." The period is wrong. If the obligation at issue was contractual and the contract period was February through March, a TEMPORAL_ERROR challenge surfaces that the claim's stated period extends a month earlier than the evidence supports. A fabrication challenge misses this because there is evidence of activity between January and March — the claim's period just does not match the assignment's actual boundaries. An omission challenge misses it because the assignment period is, properly speaking, included in the characterization (January versus February is a characterization of when). Only TEMPORAL_ERROR asks the targeted question: Do the timestamps and the stated time range match? TEMPORAL_ERROR also covers causal ordering. If a claim states that event B caused event A, and the evidence shows A preceded B by six weeks, the error is temporal. The challenger looks at received_at timestamps across witness entries, looks at the dates in the claim's statements, and checks for misalignment. ### ATTRIBUTION_ERROR The question: Is the actor correct? A claim accurately describes an event, places it in the correct time window, does not distort its significance, does not omit material context, and attributes it to the wrong person. Attribution errors are common in multi-party proceedings where several people operate under a shared name, a shared role, or a shared context. The parent's mother made the contact. The claim says "the parent did not contact." The grandmother's contact was recorded in the caseworker's notes under the family's file. The claim reads the file, identifies contact attempts, and attributes them to the parent — who was named first in the file. The attribution is wrong. The contact was made and not made by the named actor. In a termination of parental rights proceeding, attribution errors are not minor corrections. Whether an action was taken by the parent or by a family member acting on the parent's behalf is often the precise question the court is deciding. ## Why all five are irreducible The five types are not a hierarchy. You cannot optimize for one and get the others for free. A system that runs only FABRICATION checks will confidently produce claims that omit the context that makes them false. A system that runs only OMISSION checks will produce claims that include all the context but distort its severity and attribute it to the wrong actor. A system that runs FABRICATION and OMISSION will still produce claims that get the timeline wrong. Each challenge type requires a different adversarial probe and a different class of counter-evidence to check against. FABRICATION retrieves the cited observations and asks whether the claim follows. OMISSION retrieves the full witness block and asks what was left out. DISTORTION presents the claim's characterization against the evidence's characterization. TEMPORAL_ERROR requires timestamp comparison. ATTRIBUTION_ERROR requires actor resolution across the evidence corpus. These are not harder and easier versions of the same question. They are different questions. > ▼ Why It Matters. > > In a 2026 termination of parental rights proceeding, the difference between > OMISSION and DISTORTION is the difference between "the caseworker report > failed to include an exculpatory fact" and "the caseworker report > accurately included every fact but framed them to imply a conclusion the > facts do not support." The first is an evidentiary gap; the second is an > issue of characterization and potentially professional conduct. A challenge > harness that runs both will surface both. A challenge harness that runs > only one will miss the other, structurally and silently. ## Tri-Model Consensus For each challenge that runs, Canon requires a verdict: CHALLENGE_FOUND (the challenge identified a failure mode) or CHALLENGE_NOT_FOUND (the challenge did not identify a failure mode). The Tri-Model Consensus protocol (TMC) generates that verdict using three independent challenger models. Each model receives the same challenge input — the claim, the relevant evidence, the specific adversarial prompt for that challenge type — and produces an independent verdict. The consensus rule is 2-of-3: if two or more models agree, that is the consensus outcome. The Challenge model in schema.py stores per-model outcomes in model_outcomes and the consensus result in consensus_outcome. A minority dissent — one model that disagreed with the consensus — is logged, not discarded. It is available to a recipient who wants to inspect it. The 2-of-3 rule exists because individual models are sycophantic under adversarial prompting. A single challenger will often agree with the claim it is challenging because its training rewards agreement and the challenge input presents the claim prominently. Three independent models, each prompted without knowledge of the others' verdicts, produce a more robust signal. A minority dissent tells the recipient that the challenge was genuinely contested and warrants human review. When all three models disagree — each producing a different verdict on a challenge with more than two possible outcomes — the outcome is contested. A contested challenge does not prevent the attestation from being valid. It is logged in the refutation block as a signal to the recipient that this specific claim requires human judgment that the TMC protocol did not resolve. > ◆ Going Deeper — Counter-evidence retrieval as part of the challenge process. > > The refutation harness should not ask models to challenge claims from memory > alone. Models hallucinate counter-arguments as readily as they hallucinate > supporting arguments: a model asked "what evidence might contradict this > claim?" will produce plausible-sounding contradictions with no grounding in > the actual corpus. > > Effective challenges retrieve potentially contradicting evidence from the > corpus before constructing the adversarial prompt. The retrieval step uses > the claim text as a query, runs dense or hybrid search over the full document > store, and presents both the claim and the top-k retrieved results to the > challenger model. The model's task is then to assess whether any of the > retrieved results actually contradict the claim — not whether a contradiction > is conceivable in the abstract. > > This retrieval-augmented refutation is especially important for > COUNTER_EVIDENCE challenges (the fifth of Canon's original five) and for > OMISSION challenges, where the question is specifically whether the corpus > contains material the claim did not include. A model that knows the corpus > exists but has not been shown relevant results will miss the omission. A > model that has been shown the actual retrieved results will catch it. > > The retrieval step itself becomes a SearchAttestation (Chapter 20), creating > an auditable record of what the harness looked for and what it found — > which means the refutation process is itself attested. ## The coverage.declined inventory Every challenge type that does not appear in challenges[] must appear in coverage.declined[]. Each declined entry carries a type and a reason string of at least one character. The reason string is a falsifiable claim, not decoration. "We did not run DISTORTION because this claim is purely factual (a date and a single location) and distortion is not meaningful for purely factual claims" is a legitimate reason. A recipient reads it and decides whether they agree. If the claim turns out not to be purely factual — if it contains an evaluative component the harness missed — the recipient points at the reason string and argues the decline was unjustified. "We did not run DISTORTION" with no reason is a conformance violation. An empty reason field fails Pydantic validation at construction time: the DeclinedChallenge model enforces min_length=1. This is intentional. An attestation that declines challenges without accounting for the declination is not falsifiable on those challenge types; it has simply hidden the gap behind silence. The distinction the declined inventory makes explicit: there is a difference between "we ran this challenge and it found nothing" and "we did not run this challenge." The first is evidence of robustness. The second is a scope boundary that the recipient can see and evaluate. Conflating them — by presenting an attestation with some challenges run and others silently absent — would make the attestation appear more thoroughly tested than it was. > § For the Record — Canon §7.4. > > "A Coverage object MUST enumerate every ChallengeType defined in the > specification, either in applied or in declined. A ChallengeType > that appears in neither list is a structural defect. The declined list is > not an opt-out mechanism; it is an accountability mechanism." ## The running case: a complete analysis The claim: "The parent did not contact the assigned caseworker between January and March 2024." This claim appears in a caseworker's summary report in the 2026 TPR proceeding. The report cites three sources: the caseworker's call log, the caseworker's email records, and a case note entered February 28. Run the five challenges. FABRICATION. Present the claim and the literal content of the three cited sources to the challenger. Ask: given only this content, does the claim follow? The call log shows five outbound calls from the caseworker's office to a number on record, all unanswered. The email records show two outbound emails from the caseworker's office. The February 28 case note records "no contact received." None of these sources document the parent's side of the communication. The call log shows calls made; it does not show calls attempted from the parent's end. The email records show outbound only. The case note records receipt, not transmission. FABRICATION challenge result: CHALLENGE_FOUND. The claim asserts absence of contact by the parent; the cited sources document absence of contact received by the caseworker. These are not the same assertion, and the cited sources do not support the stronger claim. OMISSION. Present the full witness block — all acquired documents from the relevant period, not just the three the claim cited. Ask: what material context does this content contain that the claim omits? The corpus also contains: a phone bill showing four outbound calls from the parent's number to a number identified as the caseworker's mobile during this period; a text message thread showing a contact attempt on March 3; a note in a separate part of the case file that the caseworker's office phone was forwarded to a new number as of February 15, with no notification sent to the parent. OMISSION challenge result: CHALLENGE_FOUND. The claim omits that the caseworker's contact routing changed mid-period and that the parent made documented contact attempts that may not have reached the caseworker. DISTORTION. The claim states the parent "did not contact" the caseworker. With the above context: the parent called a number that no longer reached the caseworker because of an unannounced routing change. Does "did not contact" accurately characterize this? The characterization implies the parent took no action; the evidence supports that the parent took action that did not result in contact, and the failure of contact was at least partly attributable to an infrastructure change the parent was not informed of. DISTORTION challenge result: CHALLENGE_FOUND. "Did not contact" implies inaction; the evidence supports attempted contact through a channel that became unavailable. TEMPORAL_ERROR. The claim states "between January and March 2024." The caseworker's case file shows the formal assignment began February 7, 2024. The January portion of the claimed period predates the assignment. Contact before the assignment existed cannot be characterized as absence of contact with the assigned caseworker. TEMPORAL_ERROR challenge result: CHALLENGE_FOUND. The stated period is January–March; the assignment period is February 7–March (or later). The claim overstates the period of assigned contact obligation. ATTRIBUTION_ERROR. The claim names "the parent." The text message thread in the corpus shows contact attempts from the parent's mother's number, not the parent's number. The phone bill contacts were from the parent's number. ATTRIBUTION_ERROR challenge result: CHALLENGE_NOT_FOUND for the primary claim; the parent did make direct contact attempts. However, the harness should note that a family member also made contact attempts attributed in the case file to the family without distinguishing the actor. All five challenges ran. None goes in coverage.declined. The refutation block on this claim carries five challenge entries, four with CHALLENGE_FOUND, one with CHALLENGE_NOT_FOUND. The claim does not survive the harness. The attestation's outcome for this claim is failed. The original caseworker report remains in evidence; the attestation documents its failure modes so that a reviewing court can see exactly where it breaks down.

A complete refutation block: one claim example

The following shows a minimal conformant refutation block for a simpler claim — "The parent was present at the March 15 home visit" — where only FABRICATION runs (confirmed by observation evidence) and the remaining four types are declined with explicit reasons.

{
  "challenges": [
    {
      "challenge_id": "chal-01JABC001",
      "type": "fabrication",
      "targets": ["claim-visit-presence-0315"],
      "input": "Claim: 'The parent was present at the March 15 home visit.' Witness content: [caseworker visit log entry, March 15, 14:07, notation 'parent present, home visited, no concerns noted']",
      "outcome": "survived",
      "model_outcomes": {
        "model_a": "survived",
        "model_b": "survived",
        "model_c": "survived"
      },
      "consensus_outcome": "survived"
    }
  ],
  "coverage": {
    "applied": ["fabrication"],
    "declined": [
      {
        "type": "omission",
        "reason": "Claim is a single binary presence fact with no material context that could be omitted; omission challenge is not applicable to presence/absence claims without additional evaluative content."
      },
      {
        "type": "distortion",
        "reason": "Claim makes no characterization of significance or severity; it asserts presence only. Distortion is not applicable to purely factual binary claims."
      },
      {
        "type": "temporal_error",
        "reason": "The timestamp in the witness entry (March 15, 14:07) matches the claim's stated date. Temporal verification is satisfied by the fabrication challenge's timestamp comparison; a separate temporal challenge is redundant."
      },
      {
        "type": "attribution_error",
        "reason": "The witness entry names one actor (the parent) and the claim names the same actor. No multi-actor ambiguity is present in the cited evidence."
      }
    ]
  }
}

All four declined entries carry specific, falsifiable reasons. A recipient who believes, for instance, that "presence" claims can be distorted — that "present" versus "minimally present and uncooperative" is a meaningful distinction — can argue against the declined DISTORTION entry and ask that it be run. The declination is not a wall; it is a documented scope decision that the recipient can contest.

☉ In the Wild — The Casey Anthony trial (2011).

The prosecution's timeline in the Casey Anthony trial centered on a 31-day gap between the last confirmed sighting of Caylee Anthony and the date Casey Anthony reported her missing. The prosecution's claim — that Casey knew of Caylee's death throughout those 31 days — rested on the precision of the timeline's endpoints.

A TEMPORAL_ERROR challenge on the prosecution's timeline claim would have required explicit documentation of what evidence supported the timeline boundaries. The last confirmed sighting relied on photographic evidence with a disputed timestamp. The gap's starting point was not as firmly established as the prosecution's narrative implied. A challenge harness that required the challenger to ask, in writing, "what evidence supports the January boundary of this claim?" would have forced that question before trial rather than after.

The gap was the structural weakness of the prosecution's case. The jury's acquittal turned substantially on doubt about what happened during those 31 days. A TEMPORAL_ERROR challenge does not answer the question; it identifies that the question needs to be answered, explicitly, before the claim is presented to a fact-finder.

✻ Try This.

Take any claim from the TPR running case — from a caseworker report, a court order, or a case summary. Write the challenge_text (the input field of a > Challenge entry) for each of the five types. Use this template for each: > > "Claim: [exact text]. Evidence: [describe the cited sources]. Question: > [the specific adversarial question for this challenge type]." > > Which challenge is hardest to write? DISTORTION typically produces the most > argument, because the line between accurate characterization and distorted > characterization is contested territory. ATTRIBUTION_ERROR is often the > easiest to write but the hardest to run, because resolving actors requires > corpus-wide knowledge that a single-document challenge cannot provide. > > After writing all five, ask: which of these five would the opposing party > most want to have been run? That is the challenge type with the highest > stakes for this particular claim, and it is the one most likely to be > challenged in court if it is absent from the attestation's coverage. ## The schema, from code The five challenge types in schema.py are the ChallengeType enum and the Challenge, DeclinedChallenge, Coverage, and Refutation models:

# meridian/canon/schema.py (excerpt)

class ChallengeType(str, Enum):
    REPLAY = "replay"
    ADVERSARIAL_PROMPT = "adversarial_prompt"
    CONSISTENCY_CHECK = "consistency_check"
    COVERAGE_AUDIT = "coverage_audit"
    COUNTER_EVIDENCE = "counter_evidence"

class Challenge(BaseModel):
    challenge_id: str = Field(..., pattern=r"^chal-[A-Za-z0-9_-]+$")
    type: ChallengeType
    targets: list[str] = Field(..., min_length=1)
    input: str
    outcome: ChallengeOutcome
    model_outcomes: Optional[dict[str, ChallengeOutcome]] = Field(None)
    consensus_outcome: Optional[ChallengeOutcome] = None

class DeclinedChallenge(BaseModel):
    type: ChallengeType
    reason: str = Field(..., min_length=1)

class Refutation(BaseModel):
    challenges: list[Challenge] = Field(..., min_length=1)
    coverage: Coverage

The challenge type vocabulary in schema.py (REPLAY, ADVERSARIAL_PROMPT, CONSISTENCY_CHECK, COVERAGE_AUDIT, COUNTER_EVIDENCE) is the mechanism classification. The five names used in this chapter — FABRICATION, OMISSION, DISTORTION, TEMPORAL_ERROR, ATTRIBUTION_ERROR — are the semantic classification of what a challenge probes. An ADVERSARIAL_PROMPT challenge can probe for fabrication, omission, or distortion depending on the prompt it carries. The input field carries the specific adversarial question. Canon §6.6.1 documents the mechanism-to-failure-mode mapping; the implementation that populates input for each failure mode lives in refute/adversarial.py (Phase C, not yet implemented). ## inspect-ai: Formal Evaluation Harness (v0.2.0) The five challenge types described in this chapter correspond directly to five categories of model evaluation: source accuracy (FABRICATION), coverage completeness (OMISSION), characterization fidelity (DISTORTION), timestamp correctness (TEMPORAL_ERROR), and actor attribution (ATTRIBUTION_ERROR). In v0.2.0, inspect-ai provides a formal, reproducible evaluation harness for these challenge types via run_adversarial_inspect() in meridian.refute.inspect_tasks:

pip install meridian-canon[inspect]

inspect-ai is developed by the UK AI Safety Institute and provides infrastructure for running structured evaluation tasks against language models: defined solvers, scorers, and log formats. Each of the five challenge types maps to an inspect-ai task definition. Running run_adversarial_inspect() executes all applicable tasks for a given attestation and returns a Refutation block compatible with the standard Canon schema. Pass backend="inspect" to run_harness() to route to this implementation:

refutation = run_harness(attestation, backend="inspect")

The primary advantages over the default EchoAdapter / OllamaAdapter paths: inspect-ai tasks are versioned and logged in a standard format, making it possible to reproduce any harness run from its task definition and seed. The log files are auditable — a recipient can confirm that the specific challenge prompts and model responses match what the attestation's refutation block claims.

## Exercises ### Warm-up 1. Read the Refutation model in schema.py. Run python -c "from meridian.canon.schema import Refutation; help(Refutation)". Identify which field enforces the min_length=1 requirement for challenges. 2. Construct a minimal DeclinedChallenge with reason="". Observe the Pydantic validation error. Write the corrected version. ### Core 3. Take the claim "The parent did not contact the assigned caseworker between January and March 2024." Write a full Challenge entry for each of the five failure modes. For each, write the input field as if you were constructing the adversarial prompt. Use the schema's field names (challenge_id, type, targets, input, outcome). 4. Construct a complete Refutation block for the March 15 presence claim above, but this time run OMISSION instead of declining it. Write a challenge_text that asks the right OMISSION question for a binary presence claim. Does running OMISSION on this claim produce a meaningful challenge, or does the declination reason hold? 5. Write a challenge_text string for each of the five challenge types targeting this claim: 'The parent did not contact the caseworker between January 1 and March 31, 2026.' For each type, identify what counter-evidence would be needed to move the verdict from UNVERIFIABLE to REFUTE. Which type is most likely to be resolvable given a complete iMessage corpus? ### Stretch 6. The TMC rule is 2-of-3. What happens if all three models agree on CHALLENGE_NOT_FOUND but the correct answer is CHALLENGE_FOUND? Name one structural reason this could occur and one way the harness design could mitigate it. 7. Design a coverage.declined reason string that is machine-readable (i.e., a receiving system could parse it and route it to a human reviewer based on its category) without being free prose. What field would you add to DeclinedChallenge to formalize this? 8. The running case analysis found FABRICATION on the "no contact" claim because the cited evidence documented absence of contact received, not absence of contact attempted. Write the adversarial prompt that would catch this distinction — the exact text you would send to a challenger model, including the claim text and the evidence excerpt. ## Build-your-own prompt For your capstone matter: which of the five challenge types is most likely to arise given your evidence corpus? If your matter involves audio recordings, ATTRIBUTION_ERROR challenges are the primary concern — the speaker must be identified from voice characteristics or context. If your matter involves timestamped system logs, TEMPORAL_ERROR challenges require a verified time-source attestation. Design your refutation harness around the challenge types your evidence is most vulnerable to, not the ones easiest to implement. ## Further reading - Meridian-Canon-Revised §7 (R6 requirement), §6.6.1 (challenge types), §6.6.2 (outcome handling). - meridian/canon/schema.py — ChallengeType, Challenge, DeclinedChallenge, Coverage, Refutation. - Perez-Rosas et al., "Automatic Detection of Fake News," COLING 2018 — fabrication detection in structured claims. - Thorne et al., "FEVER: a Large-scale Dataset for Fact Extraction and VERification," NAACL 2018. - Wachter, Mittelstadt & Russell, "Counterfactual Explanations Without Opening the Black Box," Harvard JOLT 2018 — the formal structure of adversarial challenge for algorithmic claims. - Ullman, "Large Language Models Fail on Trivial Alterations to Theory-of-Mind Tasks," arxiv:2302.08399 — why three independent models are better than one. - inspect-ai documentation: https://inspect.aisi.org.uk/ — task definitions, solvers, scorers, and log format. - meridian/refute/inspect_tasks.py — run_adversarial_inspect() and the five task definitions.

---

Next: Chapter 20 — The Four Attestation Kinds. Same structure, four roles.