Example

Run the whole Personal Information Radar on one invented afternoon

Watch five candidates pass or stop at each stage of the Radar, read the typed reasons, and see the coverage report name its own boundary.

This is the Part II example end to end: five candidates arrive, each passes through observation, retrieval, eligibility, selection, assertion, qualification, resolution, timing, presentation and notice, and each is recorded with a typed reason. The chapter’s claim is that the interesting thing is not the ranking but the record — every candidate’s path, and the boundary of what was never seen.

Run it

git clone https://github.com/ernanhughes/project-language.git
cd project-language
git checkout 329660f679a5a87831f91fe1430c20ac9360dda8
npm ci
npm run example:radar

One invented afternoon, five invented candidates, and a scripted stand-in for the model. No real model is called and no real service is contacted.

Expected outcome

Each candidate stops at a different stage, and the run says which:

...
  preprint       A  eligible, and its standing does not satisfy 'peer-reviewed': not qualified. The subscription is as the person wrote it.
  mechanism      B  closeness is high; no bridge; the relation to the tracked claim is UNRESOLVED, so it is kept available (not pushed) and says so.
  contradiction  D  a person's bridge names both scopes: qualified. BRIEF is safe. A meeting is on: BRIEF + QUEUE.
  lossy          C  names the qualifier's unit at BRIEF and says only 'safe': membership, nesting and closure hold, the wording does not. The resolution rises.
  decoy          E  keyword-stuffed. Retrieved. No grant and the wrong domain: not eligible. It goes no further.

The decisions are typed, and each carries a reason rather than a score:

...
attn:preprint      r1 WITHDRAWN resolution null     mode null
attn:mechanism     r1 PENDING   resolution BRIEF    mode AVAILABLE
attn:contradiction r1 PENDING   resolution BRIEF    mode QUEUE
attn:lossy         r1 PENDING   resolution SUMMARY  mode QUEUE
attn:decoy         r1 WITHDRAWN resolution null     mode null

And the coverage report names its own boundary, which is the part the chapter insists on:

...
configured and observed sources only
boundary: two configured feeds, one invented afternoon
unknown: sources that were not configured; items that were never retrieved; items that were never observed; access restrictions on source identifiers and reasons, as well as bodies
exclusions: preprint reached [observed,retrieved,eligible] causes [evidence_standing:standing in [peer_reviewed] (candidate: preprint)] | decoy reached [observed,retrieved] causes [permission:no-grant,scope:scope-mismatch]

The run closes with a list of what it does not establish, which is part of the result:

...
  "does_not_establish": [
    "real-model language quality (the model is a scripted stand-in)",
    "that any person noticed, understood, used or benefited from anything (noticed, used and helpful stay unknown)",
  ...
    "cross-domain discovery: the bridge is supplied, nothing here finds a relation",
    "open-world coverage or recall",
    "that the urgency and interruption-cost table is the right policy for a person"
  ],

The stages, and what each one can decide

The Radar’s decisions are split into independent axes rather than one score. The contract that describes them is PART-TWO-CONTRACT.md at the root of the repository; the code is core/radar/src/attention/, where each stage is its own module:

Stage Module What it decides
Eligibility qualify.ts permission, currentness, scope and standing, as four booleans
Qualification qualify.ts whether the subscription matches and whether the relation is established
Resolution resolution.ts the least representation whose four obligations hold
Delivery delivery.ts urgency, interruption cost, and the delivery mode
Receipts receipts.ts who was shown what, and what that does not establish
Coverage coverage.ts what was configured, what was seen, and what was not

Selection is not re-implemented: units are offered to the existing compiler, and closure is the compiler’s.

// Stable units, and unit selection through the EXISTING compiler.
//
// Selection is not re-implemented here. Units are presented to core/compiler as context
// candidates: a claim's `dependsOn` is its qualifier, so the compiler's dependency closure
// refuses a claim whose qualifier was not admitted (REJECTED_DEPENDENCY). That is closure,
// and only closure. It says nothing about whether any wording is faithful.

Mechanism and limitations

Documented: the stage split, the reason vocabulary and the observation boundary are in PART-TWO-CONTRACT.md and in the run’s own closing summary.

Observed: the run above. Five candidates took five different paths; each decision carried a typed reason and a revision; the coverage report named what it could not see; and the summary listed what the run does not establish.

Not shown. Real-model language quality is not shown: the model is a scripted stand-in. Nothing shows that any person noticed, understood, used or benefited — noticed, used and helpful stay unknown throughout, and the human receipt records an interface call, not a screen. Cross-domain discovery is not shown: the bridge is supplied. There is no open-world coverage or recall, and no measure of how often these situations occur. The urgency table is a declared policy, not a measured one. The wording check is defeated by copying the right words around different meaning.

The model-side observation boundary is the provider callback in the Pi harness, not a remote HTTP request; the human-side boundary is the call to the UI notify function, not the person’s screen or attention.

Canonical source , the attention modules and the Part II contract .

Understand this example

Copy this prompt into your AI tool. No code runs here.

Apply this example

Copy this prompt into your AI tool. No code runs here.