The Record That Answers

The row is short.

A time. A person. The stage they left, the stage they entered. And one word for who moved them: rule, or agent.

There are two thousand and ninety-eight of these rows, written since the start of July, for one thousand and eight people in seven groups. A stranger became a lead. A lead asked for a price. A buyer came back and bought again.

Not one row says a person moved them.

Each row is read the way a diary is read. One person at a time, when somebody opens that person.

Nobody reads them together.

What they could say together is simple to state. Before people moved, what happened? Which word, on which channel, at which hour, from which helper? Which of them went quiet for four days and then came back, and what brought them?

The answer exists. It is spread across two thousand rows that were written for a different reader.

So the operator does what operators have always done. Starts at the top of the list. Answers the loudest. Remembers who seemed warm last week.

The rest go quiet. Some of them were ready.

The ask arrived in plain words. The customer is at the centre of everything. Track everything. Optimise on what happens between people. Keep it light enough that nobody has to learn it.

Tracking everything is the easy half. Every page read, every reply, every payment already arrives as a signal, and the record already keeps it.

The difficulty runs the other way. A record that keeps everything and answers nothing grows heavier every day it runs. It is not a memory. It is a warehouse.

The usual cure is a dashboard. Eleven tabs, a chart on each, and someone paid to read them.

It is not lighter. It is the same weight, moved.

The other answer is older than any of this. When something works, the path that led there grows a little stronger. When something fails, it gains a little resistance. When nothing happens, both fade.

Nobody decides which path is good. The traffic decides, and the forgetting keeps it honest.

A record built this way does not need a report. It needs one question it can answer at the top of one screen: who next, and why.

Light, here, means a small number of things. Not a small screen. One person. One stage. One thread. One next step. Everything else sits a tab behind them, and fills itself.

And the customer is at the centre of it, not in the sights of it. Every signal that follows a person should be one that person could read. Every channel should be one they chose. Tracking everything is only tolerable on those terms.

The turn is not a feature. It is the first morning the list is in a different order.

At the top is someone who wrote nothing yesterday. Under the name is the reason, in one line: people who read that page twice and then went quiet tended to move when someone answered their first question, not their last. Under the reason is a draft, two lines long.

The operator changes one word and sends it.

If the person answers, the path that led to them is marked, and the next person like them rises a little sooner. If they do not, the path fades, and the list forgets it was ever sure.

Nothing announces that the record has learned. The order of the list is the only evidence.

The same holds in every group. A client's record forgets at the client's own rate. The agency above sees what its clients see. None of them is told what works by anyone except their own customers.

The row is still short.

It has a reader now.

Where the metaphor stops being true

Outside the story, in the repo's words.

• "Nobody reads them together." True today. lifecycle:mine and lifecycle:of (one.ie/web/src/lib/world-receivers.ts:2093-2152) read stage_transition for ONE actor. Neither is in the SDK contract (grep -c '"lifecycle:mine"' packages/sdk/src/receivers.ts → 0). No aggregate exists.
• "Not one row says a person moved them." Measured: source holds rule (1,086) and agent (1,012) and nothing else. Either a drag on the board writes no row, or it writes one of those two words. VERIFY which, before anything learns from this table. A learner that cannot see human moves learns only what machines did.
• "Since the start of July." The at column is in MIXED UNITS: the earliest row is 1783175945 (seconds) and the latest 1790481622078 (milliseconds). Any time-in-stage computed over this table today is wrong by a factor of 1,000 on some rows. Normalising at is the first card of chapter two, not a detail.
• "The path that led there grows stronger." mark, warn and fade are wired (schema/one.tql). What is NOT WIRED is the link from a stage move back to the touch before it. Chapter one marks only a sale, by amount × 10 (text/crm.md world.tracking).
• "Who next, and why." NOT WIRED. lib/crm and components/crm hold no ranker, and there is no health score in lib/.
• "Light." Unmeasured. ActorContent.tsx plus components/crm/*.tsx is 2,893 lines, and the profile has eleven tabs today (text/crm.md card 11, red). There is no budget for load time or bytes.
• "One the person could read … one they chose." Chapter one's cards 7, 25, 26 and 27 are red. POST /api/forget takes any actor id with no auth check (one.ie/web/src/pages/api/forget.ts); the fix is in flight on the secure lane, 2026-09-28.
• Locked words used: signal, and the verbs behind stronger (mark), resistance (warn) and fade. Dead names: none. Warehouse and diary are ordinary English, not substrate words.

The family this story generates

Sentences that would be false if shipped

• "The CRM tells you who to talk to next."
• "Time in stage is measured for every person." (at mixes seconds and milliseconds.)
• "We know what moved each customer." (No stage move is linked to the touch before it.)
• "Every reply an agent drafts is scored by its outcome."
• "The profile loads in under a second." (Nothing measures it.)
• "Customers can see and delete everything we hold." (Cards 26 and 27 are red.)
• "Your team moves people through the pipeline." (No recorded move has a person as its source.)

The story shape — the chain, and the three rules

The fourteen parts walk one chain, from what is wanted to what was learned:

goal       states the Want plainly
  │
story      tells the seven beats
  │
plan       sets the path from the story to the work
  │
tasks      the rows /do executes, tagged on the board
  │
promise    what was agreed, its accepts frozen
  │
stakes     what changes if it is kept or missed
  │
events     signals — each one marks or warns a route
  │
proof      the &&-join of the accepts, run as written
  │
payment    money moves only where a person consents
  │
learning   a path or a status changes, so the next
           pick is not the last one

Three rules hold for every lifecycle, for people and for agents:

1. Promises at every touchpoint. Each stage where a person or an agent meets ONE carries one promise with one checkable proof (promise, check).
2. Agents help people move forward. Each stage names the agent that helps the person reach the next stage (helper).
3. Agents hand tasks to people. Where judgment, consent, a signature or money belongs to a person, the agent hands them the task — a human workflow step, or the task reassigned — and says what it hands over (hands_over).

Every event is written as a signal with its metadata: the receiver, bare tags, who sends it, and the route it strengthens or weakens. A fact nobody has checked is written VERIFY:, never filled in.

The knock is what was said. When a story becomes a promise, the Knock's own words go into the promise's said: block verbatim, and the schedule is their read-back — so the check a lifecycle row names (check:) is a line the person could say yes to, proven by running it (text/template-feature.md; the law is .claude/rules/documentation.md § What a promise contains, and what must be proven). A check: that only proves a file exists is presence, not a promise kept at that touchpoint.