Check Reality

---
name: check-reality
description: Attack whether the market, buyer, problem, and language a research or strategy artifact claims actually EXIST — the reality-attack pass. Not improvement, destruction of fabricated reality. Every item gets a 1-to-100 existence-confidence rating with reasoning, default low; internal coherence is not evidence. TRIGGER on research records, a judged root file, a project's re-derived buyers or problems, an assembled strategy, or a built piece, or when the Reality Reviewer runs the reality attack. DO NOT TRIGGER for whether a built piece's argument is constructed right (check-strategy), whether a claim resolves to a record (check-claims), or whether the reader believes it (buyer-review).
---

# Check reality

One Process: attack whether the market, buyer, problem, desire, and language a research or strategy artifact claims actually EXIST, and rate the existence confidence of each. This is not an improvement pass — the job is to destroy fabricated reality. check-strategy judges whether the argument is BUILT right for the buyer; this judges whether the buyer, problem, and language the argument rests on are REAL at all. The two are separate categories with separate owners; this pass never touches argument construction and never rewrites copy. The split from check-claims is by ARTIFACT: this pass verifies quote authenticity in the LANDSCAPE artifacts — the research records, the judged root files, and their evidence, where a fabricated quote fabricates the reality; check-claims resolves COPY claims to their records. This is the single home of that split; the consumers point here.

Treat every proposed market, buyer, problem, desire, and language item as unsupported until concrete evidence forces otherwise. Default to a LOW existence rating. Internal coherence is not evidence — a document that hangs together is not a document that describes anything real.

### Return findings to the chief, never a verdict transcript on disk
Every attack returns a rated finding to the chief, who corrects the research records or the judged rating it lands on. No PROVEN/UNPROVEN or REAL/FAKE status is ever written to disk, and no lineage-invalidation transcript persists. The existence rating rides with the item to the owner's pick; a low rating is a low rating, not a removal. The chief, holding the finding, decides whether to re-commission research, lower a judged rating, or strike a record — nothing is auto-killed by this pass.

### Run the attack product-blind
The pass runs on the research records and the judged root files (`Problems.md`, `Buyers.md`) product-blind: it never receives product files, because whether the product addresses a problem is irrelevant to whether the problem is real, and seeing the product match rewards product-compatible fabrications. Judge whether a problem was read off a product feature from the evidence's shape, never from what the product does. On the built piece in the final pass, the same category attacks whether the copy reintroduced a market, buyer, or problem the records never held.

## 1. Hunt the fabrication patterns

### Flag every pattern that manufactures a reality the evidence does not hold
Read the artifact for these, each a way a writer invents a market that is not there:

- a market that is only a category the document invented;
- a buyer that is merely a persona, not a group that would recognize itself without explanation;
- a problem derived from a product feature rather than found in the market;
- language no buyer would naturally use — a strategist's, copywriter's, or founder's words put in the buyer's mouth;
- a claim supported only by competitors — attribution companies existing proves attribution companies exist, never that the buyer wants attribution;
- a rare or possible event presented as widespread;
- emotional intensity the writer added, not the buyer's own;
- evidence that shows the thing OCCURS but not that it MATTERS;
- evidence that shows annoyance but not demand — a complaint is not purchasing intent.

Each illegal conversion on the researcher's evidence bar (`agents/researcher.md`) — possible experience into common problem, product capability into buyer demand, and the rest of its never-convert list — is a fabrication pattern here. Naming which pattern fired sets the item's existence rating low with a concrete reason.

### Fetch the cited element-2 quotes and record every fetch outcome
Verification is a completion condition, not a spot-check. Fetch the cited URL for every element-2 quote when the record set has ≤6 problems; above 6, fetch every high-rated problem's element-2 citation. Record the fetch outcome per citation — resolved verbatim, resolved with mismatch, or dead — in the round's finding file; a rating without its recorded fetch outcomes is incomplete. Confirm the quote appears verbatim, the speaker identity matches what the page shows, and any source number (review count, rating) matches the source page. Search claimed buyer language and venues with WebSearch. A quote that does not resolve at its URL, a metric borrowed from a different page, or a speaker the page does not identify is WRITER-INVENTED evidence, not support — internal artifacts cannot verify their own reality, and the item's existence rating drops accordingly.
Before declaring a citation dead, reconstruct the URL from the thread numbers and titles AND search for the quote; "no web footprint" is legal only after both fail. Misdeclaring a live citation dead is itself a recorded system failure.

### Compare every problem against its threads' outcomes
Comparing each claimed problem against what its threads actually resolved to is a named completion condition, not optional. What the comparison forces depends on what the thread holds:
- An outcome or diagnosis the record OMITTED — a wrong affiliate link the record hid, a sale that occurred, a fix that worked, left out of the record — drops the problem's existence rating sharply: the record misrepresents its own thread.
- A resolution or successful pivot the record DID record is a recorded fact, not a downgrade. It SUPPORTS occurrence, consequence, and behavior change — the problem was real enough to drive the holder to resolve or pivot. A problem does not become unreal because its holder later solved it; a resolved problem and a never-mattered problem are different things, and conflating them destroys real evidence.
- A trivial consequence, or an in-thread diagnosis showing the thing was never a problem (normal variance read as failure, too small a sample), drops the existence rating with that reason named. A recorded, confirming diagnosis is not a defect — it is the evidence working, and never lowers a rating.

Fetching a thread means fetching its continuation pages too, or recording them unfetched; a problem resting on an unfetched continuation cannot rate high. A defect that violates the merge rules — root-cause divergence across the merged speakers, failure-stage mixing — lowers the rating; it never sits as a caveat beside a high one. A caveat that names a fatal defect and preserves a high rating is not an attack.

## 2. Apply the sensibility test

### Rate low any claim that fails normal human behavior and intuition
A claim rates high only if it holds up against what people NORMALLY do and say. A claim that has to redefine ordinary behavior to stand is fabricated, however coherent it reads.
Example: "the funnel owns the sale" fails — the payment processor runs the transaction, the claim reads as unsafe, and it moves no one toward buying.
Example: "the operator's bank contradicts the dashboard" fails — people read their bank AS the source of truth; the claim invents a behavior no one has to make its point.

## 3. Apply the obviousness prior

### Demand stronger evidence the less obvious the problem is
Real problems are mostly OBVIOUS and driven by WHO the buyer is. A creator building courses obviously wants more money; that a creator building courses has, acknowledges, or will think about a "tracking problem" is far less obvious and far less likely. The less obvious a claimed problem, the more independent, concrete evidence it must carry before it rates high — a non-obvious claim on thin evidence rates low, not entertained because it is plausible.

## 4. Rate the existence of every item

### Rate each claimed market, buyer, problem, desire, and language item from 1 to 100
Each item gets one existence-confidence rating with its reasoning and the fabrication pattern (if any) that lowered it. The rating answers one question: how much concrete, fetched evidence forces this thing to exist outside our documents. Meet the kind's completion condition below before rating an item high.

### Meet the kind's completion condition before a high rating
Each kind carries its own fetched-evidence completion condition; missing it caps the existence rating and the reasoning names what is absent:
- a PROBLEM rates high only with all seven elements of the researcher's evidence bar (`agents/researcher.md`) present and its element-2 citations fetched per the fetch discipline above; a missing element caps the rating and names the missing elements.
- a BUYER GROUP rates high only with its existence-outside-our-documents evidence fetched and confirmed — the self-name observed at a real venue, members speaking there; an unfetched or unconfirmed existence claim caps the rating and names the missing existence evidence.
- a LANGUAGE item rates high only with its quote fetched and confirmed verbatim at its cited URL; a quote that does not resolve rates near zero as writer-invented; an unfetched one caps the rating and names the unfetched quote.
- a DESIRE rates high only with the buyer's own quote naming the wanted outcome fetched and confirmed verbatim, AND the seeking behavior behind it observed — the buyer acting toward that outcome, not a writer asserting they want it; a desire missing its fetched quote or its observed seeking behavior caps the rating and names which is absent.
A market or buyer inherits the completion condition of the problem and buyer-group evidence it rests on.

### Prefer "we do not know" over a reasonable-sounding fill
Where the evidence does not force existence, rate it low and say so. A blank filled with a plausible answer is the exact failure this pass exists to catch.

## 5. Findings block, and record what was caught

### Write every attack as a rated finding in review-copy's format
Write each attacked item as a finding (check, severity, location, finding, suggested fix) in review-copy's finding format, carrying its existence rating and the pattern that set it. Name the artifact and the exact item. A low-rated item returns to the chief with its reasoning; the chief corrects the record or the judged rating.

### Route a fabrication finding to the chief, never to revise
A finding that a problem was read off a product feature, that language was writer-invented, or that a problem never mattered goes to the chief, never to revise: revising copy around a problem that does not exist ships fabricated reality polished. Name the item (the `Problems.md` or `Buyers.md` rating, or the research record behind it) and hand it to the chief, who re-commissions the research that produced it, lowers the judged rating, or strikes the record.

### Record every catch for tracing back into the system
Every low rating or downgrade records what it caught and which pattern produced it, in the round's finding file, so the failure can be traced back and the upstream skill updated to produce fewer of them. A catch that is fixed silently teaches the system nothing.

Verification: every claimed market, buyer, problem, desire, and language item carries one existence rating from 1 to 100 with its reasoning, meeting its kind's completion condition before a high rating; the required element-2 citations fetched with each fetch outcome recorded; every problem compared against its threads' outcomes with continuation pages fetched or recorded unfetched; the sensibility test and the obviousness prior applied to each; every fabrication finding routed to the chief with the item named; no PROVEN/UNPROVEN or REAL/FAKE status and no lineage transcript written to disk; every low rating recorded as a finding in review-copy's format with the pattern it caught named for tracing.