# The synthetic readers programme

**status** Running. One archetype defined and run, three archetypes defined, two
run types specified, first findings already fed back into the pack.
**date** 21 August 2026

---

## Why this sits outside the pack

The thirteen documents of [the Map Your Case pack](../index.html) are an
argument about a tool. **This area is not part of that argument — it is the
instrument that tests it, and it feeds the pack rather than belonging to it.**
The flow runs one way:

```
a fixed artefact (a live page, or a mockup authored in advance)
        │
        ▼
   a run: one archetype, one arrival condition, one budget
        │
        ▼
   findings ──────────► change-control entries in the pack
```

Keeping it separate matters for a reason beyond tidiness. A run's output is
**simulated material**, and simulated material must never be shelved beside the
documents it tested as though it were the same kind of thing. Different
directory, different filenames, different rendering, markers throughout — that
is [rule one](../principles.html) implemented rather than described.

## The two agents

| Agent | What it is | What it may do |
|---|---|---|
| **The renderer** | A browser and nothing else | Navigate, scroll, click where it is told, screenshot, return the image |
| **The reader** | One archetype, in a fresh context | See the image. Answer the fixed questions. Point at where to go next |

The renderer never interprets the page for the reader, never passes text, DOM,
structure or the page's purpose on, and never reacts. **The reader receives
pixels and nothing else.** It has read no documentation, holds no knowledge of
the project, and is instructed that the image is the whole of what it knows.

That boundary is the instrument, not a limitation of it: a reader that could
read the source would understand the page better than any human being could, and
every finding would be optimistic.

**Spatial, not semantic.** The reader points — *"click the first box in the row
of four"*, *"scroll up a little"* — and never names an element by its function
unless it can literally read that word in the image. Naming it would prove
recognition had already happened and skip the exact step where a real person
fails. Where a spatial instruction is ambiguous, the renderer records how it
resolved it, in the run record, beside the step.

## The two run types, per archetype

**Type A — the tabletop.** Blind. The protocol above: pitch, expectation
question, then screen-by-screen with the fixed comprehension question, until the
budget is spent or the reader leaves. This is the one that finds defects.

**Type B — the informed analysis.** A second pass by an agent that *has* read
the pack, looking at the same run: what worked, what did not, what the tool is
actually worth to this archetype, and what should change. This is the one that
turns a transcript into decisions.

They are kept apart deliberately, and in this order. A single agent that both
reacts and analyses will produce a reaction shaped by what it knows it is about
to conclude — the same self-consistency failure that makes a page generated
during a run worthless.

## The arrival condition — an amendment to document 08

Document 08 says the reader must not be told what the page is for, because a
page whose purpose is not apparent is the commonest real failure and briefing
the reader makes it undetectable. That rule is right, and it describes an
arrival nobody actually has: real readers arrive with a sentence from whoever
sent them the link.

So the arrival condition becomes **a run parameter** rather than a fixed rule:

| Condition | The reader is told | What it measures |
|---|---|---|
| **Cold** | Nothing at all | Whether the page states its own purpose |
| **Pitched** | The fixed elevator-pitch paragraph, and nothing else | Whether the page delivers the promise that brought the reader |

Both are needed and they measure different things. Recording the condition per
run is what keeps them from being confused; running only the pitched form would
quietly retire document 08's rule 3, so the schedule below carries both.

The pitch itself is fixed wording, exactly like the comprehension question — see
[the instruments](instruments.html).

## The budget, set from outside

Patience is **not** generated by the reader. It is fixed before the run and
spent by mechanical rule, so abandonment is a measured event rather than a
coherent story the model tells about itself.

| Property | Round 1 setting | Spent how |
|---|---|---|
| Screens | 6 per reader | One per screenshot delivered |
| Clicks | 8 per reader | One per instruction |
| Time | 10 minutes, estimated at a fixed reading rate | Per screen, by the rate — never by the model |

Round 1's numbers are judgement and are published to be argued with; round 2's
come from round 1's spend data, which is the only non-arbitrary source there is.
A reader may also leave *before* the budget is spent — that is a different event
and is recorded as such.

## What a run may and may not conclude

**Defects, not preferences.** A run can establish that a page does not answer its
own question, that a term was used before it was defined, that a step had no next
action, that a control looked like an affordance and was not. It cannot
establish which of two clear designs people prefer, whether a tone lands as
confident or arrogant, or whether a finding feels alarming enough to act on.
Those need humans, and they are spent on variants after the levels are clear.

## Honest limits of this programme, stated before its findings

1. **The reader and the page share a model family.** The page was built with the
   same kind of model that is now reacting to it. The fixed-artefact rule blocks
   the worst form of this — the page cannot be written to suit the reader,
   because it was published first — but a shared prior about what a web page is
   remains, and it is not measurable from inside.
2. **The pixels-only boundary is instructed, not enforced.** The reader is told
   it may read only the image path it is given. Nothing in the harness prevents a
   breach; the tool-use count per step is recorded in the run record so that a
   step doing more work than one image read is visible.
3. **The artefact was served locally.** The environment's browser could not reach
   the public site, so runs are against a local server holding the exact
   published tree, with the served bytes hash-verified against the live site
   before the run. This satisfies the fixed-artefact requirement more strictly
   than the live site would, and it is a substitution, so it is recorded.
4. **One reader per archetype is n = 1.** These are qualitative findings.
   Anything counted here is counted for the ledger, never for a percentage.
5. **No calibration record exists yet.** No real reader has run the same
   protocol, so nothing here is known to predict what a person would do. That is
   the gap that separates this from a product, and it is named in the pack's
   [change control](../change-control.html) as an open decision.