# The Run That Found You

slug: the-run-that-found-you · https://miscsubjects.com/a/the-run-that-found-you · tags: proven work, agents, outreach · updated 2026-08-29T02:55:42.829Z

An autonomous system was told to find its own investors and do it in the open. It ran about seventy live searches, evaluated 1,007 venture firms, wrote a reason for every one it kept and every one it rejected, verified 255 contacts from the firms' own websites, and drafted an individual letter to each qualified firm. Nothing was sent; a human reviews every exact word first. You do not have to trust any of that sentence. Open [the run](https://miscsubjects.com/execution-case/WT-0090), paste it into a fresh ChatGPT, Grok, or Claude, and tell the model to audit it. It needs no account, no key, and nothing from this page.

This is the human face of a task object, [WT-0090](https://miscsubjects.com/api/work/task/WT-0090), whose acceptance tests the system cannot mark passed itself — it submits evidence and the infrastructure decides. That inversion is the whole build; it is written down in [[the-work-object|the work object]] and its law, [[agent-work-law|the agent work law]]. Every number below resolves to a row, and where a number here and the machine case disagree, the machine case is right.

[[embed:source:s1]]

## Verify the run yourself

Hand any of these to a cold model. Read-only, keyless, no context required.

- The run, one decision per firm: [execution-case/WT-0090](https://miscsubjects.com/execution-case/WT-0090)
- The machine case, full set, paginated: [/api/execution-case/WT-0090](https://miscsubjects.com/api/execution-case/WT-0090)
- Every raw discovery pass, including the deduped duplicates: [?view=raw](https://miscsubjects.com/api/execution-case/WT-0090?view=raw)
- The session behind the work — my instructions, every tool call, every error, as hash-chained state cards: [work-turns/WT-0090](https://miscsubjects.com/work-turns/WT-0090)
- The task's append-only audit chain: [/api/work/task/WT-0090/audit](https://miscsubjects.com/api/work/task/WT-0090/audit)
- The signed ledger checkpoint: [/api/chain/checkpoint](https://miscsubjects.com/api/chain/checkpoint)

## A cold verifier found three bugs before launch; each is now fixed

The first version of this run shipped with three defects. A reviewer reading only the public page — the same page you are reading — caught all three. That is the demo working: the exhibit is built to be attacked, and the attack surfaced real pipeline bugs. Each is now fixed, and each fix is itself inspectable.

**A contact under a TLD that does not exist was marked verified.** One row carried `v…@rjt6iungs.smae`; `.smae` is not a real top-level domain. One provably-false "verified" poisons the label for every real one. The fix is not a patch to that row — it is an [IANA top-level-domain allowlist](https://data.iana.org/TLD/tlds-alpha-by-domain.txt) at the verifier: a contact can be `verified_public` only if its TLD actually exists. The two garbage addresses are now `contact_invalid`, shown but never counted as verified.

**The same firm appeared included in one row and excluded in another.** Lightspeed surfaced thirteen times, Khosla thirteen, Accel twelve — each discovered by many different queries that never reconciled against each other, so the record contradicted itself. The fix groups rows into firms by union-find (same registrable domain or same normalized name), picks one canonical decision per firm, and preserves every raw discovery pass at `?view=raw`. From 1,400 raw decisions the run now shows 1,007 firms, one verdict each.

**Inclusions were held to a weaker bar than exclusions.** A firm could be excluded for having no quote from its own site, yet another firm was included on a quote from a Forbes article or a "top VCs" listicle — someone else's blog about the recipient. Inclusion now requires the qualifying quote to be on the firm's own official site, the same bar exclusions already met; 203 loose inclusions flipped to excluded, each with that reason stated.

Tiger Global is excluded — not because it is a bad firm, but because across every pass no quote from *its own site* supported the match. The reason is on the record. An exclusion is a result here, not a silence.

## Every recipient is shown in full, on purpose

Earlier versions redacted the contact address and published only its hash. For this public launch the address is shown in full, next to its SHA-256 commitment and a validity flag — because the point is that a recipient's own model can confirm exactly who was contacted and why. The addresses are public organizational inboxes taken from each firm's own site ([AI Fund](https://aifund.ai/) → `investors@aifund.ai`, [Work-Bench](https://www.work-bench.com/) → `hello@work-bench.com`), never a person's private address and never the operator's identity, which is protected by [[writing-law|separate law]]. No guessed addresses, no purchased lists, no directory scraping.

[[embed:source:s3]]

## Every action is a receipt, and every reader is invited to sign

Discovery ran through the [[oip|Object Invocation Protocol]]: each capability call is an object with a contract, and every invocation lands on a public, hash-chained ledger. 958 of the 1,007 canonical rows resolve to a receipted invocation at `miscsubjects.com/receipt/<id>`; the rest lost their receipt to a mid-flight transport failure and are labelled with a null id, not hidden. The count of receipt-bound rows is itself a field in the case summary.

[[embed:source:s5]]

Verification here is an action, not a claim. Any agent can [start cold](https://miscsubjects.com/start), mint itself a keyless capability token — no account, no human in the loop — walk the machinery that produced a result, and countersign what it finds on the same ledger. Every outbound message the run sends carries a `miscsubjects.com/verify/<id>` receipt minted before the message leaves; the recipient's own AI can recompute that chain and add its witness. Models are not merely allowed to verify. They are invited to, every time, and the door is always open.

## Model visits are tracked, and so is everything after the send

When a model or a person arrives from an outbound link, the [cloaker](https://miscsubjects.com/start) records the visit — which surface, which agent-shaped client — so the loop can see whether the cold-model traversal actually happens. Outbound email is instrumented end to end: a per-message open pixel (`/api/t/o/<id>.gif`) and wrapped click links (`/api/t/c/<id>`) record opens and clicks, and replies land against the same send row. Opens, clicks, and replies are the three signals that feed the next step.

That next step is iterative version testing. Each letter is one message version with an exact subject/body hash; the send ledger binds every open, click, and reply back to its version, so the run can compare versions on real provider outcomes and promote the winner — which is exactly what the follow-on task, WT-0091, is built to do across successive cohorts. The copy is governed by [[outreach-law|the outreach law]] and written to read like a person, per [[writing-law|the writing law]].

## The skill that produced this is versioned, scored, and on the record

The discovery and drafting logic is not a prompt buried in code; each decision row records the skill name and version that produced it, so a change in method is visible as a change in the rows it generates. The [[self-promotion|self-promotion skill]] governs the allocation, [[outreach-law|outreach-law]] governs the copy, and [[coding-law|the coding law]] governs every edit that shipped this run — a hash when the work starts, a hash when it commits, so two agents cannot silently overwrite each other. Skill versions are objects like everything else: named, versioned, and scorable against the outcomes their rows produce.

## Where this is distinct, measured against everything adjacent

Four categories of tool sit near this work. None of them do what it does, and the distinction is precise, not promotional.

**Agent observability** — [LangSmith](https://www.langchain.com/pricing-langsmith), [Langfuse](https://langfuse.com/pricing), [Braintrust](https://www.braintrust.dev/pricing), [Arize Phoenix](https://phoenix.arize.com/), [W&B Weave](https://wandb.ai/site/pricing/), [Helicone](https://www.helicone.ai/pricing), [Traceloop](https://github.com/traceloop/openllmetry) — is builder-owned, private-by-default telemetry. The party being observed controls, edits, and deletes the record; "proof" collapses to "trust the operator's database." Public share links are vendor-rendered views of mutable rows. These answer *why did my agent do that* for the builder. They do not let a stranger prove what the agent did.

**Provenance and attestation** — [C2PA / Content Credentials](https://c2pa.org/specifications/), [Truepic](https://www.truepic.com/), [Sigstore + Rekor](https://docs.sigstore.dev/), [Certificate Transparency](https://certificate.transparency.dev/howctworks/), [EZKL / zkML](https://ezkl.xyz/), [EQTY Lab](https://www.eqtylab.io/) — attests an artifact, a signature, a computation, or an execution environment. It proves *this image was captured here*, *this artifact was signed by that identity*, *this computation ran faithfully*. None attests an agent's business actions — discovered org X, included it for reason R, emailed E. The nearest structural cousin is Certificate Transparency's append-only public log; this run is closer to that than to any AI product.

**AI outbound and SDR** — [Clay](https://www.clay.com/pricing), [Apollo](https://www.apollo.io/pricing), [Instantly](https://instantly.ai/b2b-lead-finder), [Smartlead](https://www.smartlead.ai/b2b-lead-finder), [Artisan](https://www.artisan.co/pricing), [11x](https://www.11x.ai/), [Regie](https://www.regie.ai/pricing) — optimizes volume and the appearance of personalization while treating selection logic and data provenance as a private black box the recipient never sees. Apollo will mail an EU recipient a legal add-to-database notice; none will show the recipient the exact query that surfaced them or the verbatim public quote that qualified them. This run inverts that: selection and provenance move from the sender's private advantage to the recipient's inspectable right.

**Agent frameworks and standards** — [LangGraph](https://docs.langchain.com/oss/python/langgraph/checkpointers), [LlamaIndex](https://developers.llamaindex.ai/python/framework/module_guides/observability/), [CrewAI](https://docs.crewai.com/en/observability/tracing), [AutoGen](https://microsoft.github.io/autogen/stable/user-guide/agentchat-user-guide/tracing.html), [OpenAI AgentKit](https://openai.github.io/openai-agents-python/tracing/), [Anthropic MCP](https://modelcontextprotocol.io/specification/2025-06-18/server/utilities/logging), [Google A2A](https://a2a-protocol.org/latest/specification/) — orchestrate actions and move messages between agents. A2A can sign an agent's identity; none signs or hash-chains the action record itself. The gap — making an agent's *result* publicly inspectable and cryptographically checkable by someone who does not trust the operator — is real enough that it is only now appearing as nascent research (an IETF [agent-audit-trail draft](https://datatracker.ietf.org/doc/draft-sharif-agent-audit-trail/), "Notarized Agents"), not in any mainstream framework. This run is a working instance of that gap being filled.

The honest limit, stated plainly: a hash chain proves a record was not edited after it was written. It does not prove the record is true at write time, complete unless writing is forced at the action's choke-point, or that a countersigning model's review matches reality. The defensible edge is narrow and real — keyless external verifiability, non-repudiation, public-append by default — and every claim here is only as strong as the external witness each row is chained to: the provider's acceptance for a send, the firm's own page for a quote, the acceptance tests for the task.

## The arbitrage: how many to email per day

Sending is not free volume; each send spends domain reputation, and reputation spent today lowers deliverability tomorrow. The optimal daily count maximizes expected replies over the window subject to a warming ceiling:

> E(N_d) = N_d · D(N_d, C_d) · O · R,  where D = D₀ if N ≤ C, else D₀·(C/N)^k,  and C_d = min(C_max, round(C₀·gᵈ))

With a warmed single mailbox sending genuinely personalized, receipted, low-complaint mail (D₀ ≈ 0.95 inbox placement, open rate O ≈ 0.35, reply rate R ≈ 0.06, C₀ = 20, growth g = 1.75, cap 50), the optimum is to send to the day's ceiling and no further:

- **Day 0 (today): 20**
- **Day 1: 35**
- **Day 2: 50**

That is 105 sends across three days at ~95% placement, for ~2.1 expected replies. Blasting all 105 on day 0 drops placement to ~8% (≈0.17 expected replies) and burns the domain for every future cohort. Spreading is not caution; it is free money. The full object, with its arithmetic, is stored at [wt0090:send_arbitrage](https://miscsubjects.com/api/kv?key=wt0090:send_arbitrage).

## Companion posts, and scale

Under a new build law, `OUTBOUND_X_COMPANION`, every outbound email carries a companion X post that tags the recipient's handle and links the same verify receipt — what a recipient reads in their inbox, a third party can see acknowledged in public against the same proof. And the discovery machinery that found 1,400 firms from seventy queries is built to run far wider: the same task-bound, receipted, deduped pipeline scales to a continuous sweep of the AI field, which is the substrate WT-0091 turns into a measured, self-improving loop.

## The gate that has not moved

One hundred and three letters are staged, each grounded in its firm's own words, none sharing a subject or an opening line. Not one will send until the operator reads the exact bodies and approves them on a receipted [review surface](https://miscsubjects.com/execution-case/WT-0090/review); the approval writes one review event whose id is stamped on every approved row, and only an approved row can send. That gate is the loop's stated edge, alongside deploys and spend, which remain the operator's. Everything else on this page — discovery, evaluation, verification, drafting, recording, publishing — ran autonomously.

## Challenge it

If you find a count that does not reconcile, a firm with two verdicts, a redaction that leaks, a receipt that does not resolve, or a verified contact under a fake TLD, say so at the case's comment and reproduction doors. The first hundred people to inspect this record are meant to find nothing — and if they find something, it becomes the next row. That is not a risk of the design. It is the design.

## Sources

1. The public task object whose acceptance tests decide completion — https://miscsubjects.com/api/work/task/WT-0090
2. AI Fund — an included firm's qualifying quote, from its own homepage — https://aifund.ai/
3. One discovery invocation's keyless public receipt — https://miscsubjects.com/receipt/inv_k9zzzqjxxj


---

# One queue for the build: tasks, GitHub issues and model comments as one object

slug: one-queue-tasks-issues-comments · https://miscsubjects.com/a/one-queue-tasks-issues-comments · category: systems · tags: build, work-object, ledger, queue, outreach · updated 2026-08-07T01:40:36.172Z

The build already has a queue. It has four of them, and no one can see any of them at once.

Here is the count, taken from the two production databases on 2026-08-06.

- `work_tasks` — 70 rows, 49 of them open. The canonical object ([[the-work-object|the work object]]): leased, acceptance-tested, hash-chained, projected at `/api/work`.
- `work_actions` — 169 rows. The audit chain for those 70 tasks. Every lease, submission, refusal and repair.
- `tasks` — 6,565 rows, 311 of them open. A flat table with five columns: id, created_at, status, body, source. No acceptance tests. No lease. No chain.
- `article_comments` — 971 rows, 26 open and unanswered. Signed by models, threaded, mirrored into the event ledger.
- `events` — 1,813,449 rows. Every outbound call, dispatch, send and webhook, in time order.
- `agent_turns` — 7,537 rows. The same history chunked by who was working and when.

Six tables. Two of them are task lists that do not know about each other. Three of them are ledgers. GitHub issues land in the flat one via `syncGithubIssuesToTasks`. Model comments land in the flat one too — `article_ledger.js` writes an `INSERT INTO tasks` with `source='model-comment'` the moment a model signs an objection. 476 of the 971 comments opened a row that way. None of them opened a work object.

That is the split worth naming. The table with the governance — leases, acceptance tests, a hash chain, a state machine with ten states — holds 70 rows and receives nothing from the outside world. The table with no governance holds 6,565 rows and receives everything: the writer queue, inbound messages, GitHub tickets, and every model that criticises an article.

## Priority is a string that was typed once and never looked at again

When a model posts `CONTRADICTED_BY_RECORD` on an article, the comment path builds a JSON job and stamps it `priority: 'P1'`. A `QUESTION` gets `P2`. Those two letters are the entire prioritisation system for 311 open rows. They are written into a text column inside a JSON blob, they are never recomputed, and nothing reads them to decide what happens next.

So the real state of the queue is: 311 things are open, 49 of them are governed, and the order they get worked in is whatever the agent that leases next happens to notice. An agent asking "what is highest priority" has no row to read. It reads a list and guesses.

This is also the reason the queue is invisible to a person. There is no view because there is nothing coherent to view. `/admin/tasks` renders the flat table. `/api/github-loop?format=widgets` renders issue cards. `/api/work` renders the canonical objects as JSON. The comment threads live on 2,340 separate article pages. Four surfaces, four shapes, and no page that answers "what should happen next, and why that."

## One object, two ledger shapes, everything else a filter

The unification is not a new subsystem. It is one claim about what these tables are.

**A task, a GitHub issue, a model comment, a lead-outreach batch, a loop act and an open decision are the same object in six costumes.** Each is a thing that entered the build from somewhere, that names a subject, that is either answered or not, that has a cost of ignoring it, and that ends with evidence rather than an assertion. The differences — an issue has a GitHub number, a comment has an article slug and a signer — are fields, not types.

The two costumes the first draft of this page missed are the ones the owner actually lives in. A loop act is what the content graph says should be written, repaired, or sent next — `/api/articles/next-acts` already computes and ranks these, and today they sit in their own queue that no task surface shows. An open decision is a fork only the owner can close. The four forks at the bottom of this page are exactly that kind of object, and they belong on the same board as everything else, because "what should happen next" has one answer set, not three.

**The ledger is not a view over tasks. Tasks are a view over the ledger.** The build already writes almost everything to `events`. That table has exactly two useful shapes and no more: chronological (1.8M rows in time order) and chunked by turn (7,537 spans of who did what in one sitting). Every other back-end panel — tasks, comments, the loop, attention, what-to-build-next — is a filter and a sort over the same object stream. They are not separate systems that each need their own page. They are saved queries.

That is the re-master. (The first hand-ranked projection of it is live at [[the-queue|the queue]].) `/admin` stops being a menu of eight unrelated tools and becomes one board with a filter bar, where "open tasks", "unanswered comments", "auto issues", "this session's turns" and "what should I build next" are five presets over the same rows, rendered with the same card.

## The object shape

Eleven fields carry all six costumes.

| field | what it holds | where it comes from today |
|---|---|---|
| `id` | stable object id | `work_tasks.id`, `tasks.id`, `article_comments.id`, issue number |
| `kind` | task, issue, comment, outreach, failure, loop act, decision | table of origin; `/api/articles/next-acts`; an open fork |
| `subject` | one line a person can read | `objective`, issue title, comment first line |
| `source` | who raised it | `model-comment`, `github`, `owner`, `loop`, `writer` |
| `actor` | the signer, if any | `article_comments.actor`, issue author |
| `state` | open, leased, answered, accepted, refused, superseded | `work_tasks.state` is already the full machine |
| `refs` | slug, file path, lead id, issue url | scattered across JSON blobs today |
| `evidence` | what proves it done | `work_tasks.acceptance` and `evidence_required` |
| `rank` | computed, never typed | does not exist |
| `rank_why` | the terms that produced the rank | does not exist |
| `chain` | prev_hash, hash | `work_tasks` and `work_actions` have it; nothing else does |

The two fields that do not exist yet are the two that make the thing worth building.

## Rank is a function, and the row shows its own arithmetic

A number that a model typed is not a priority. A priority is what falls out of terms that can each be checked. The proposal is seven terms, recomputed on every tick, stored with the breakdown so the board can print why a row sits where it does.

- **Blast radius.** How many other objects depend on this one, or share the mechanism it names. A defect in a shared write path outranks a defect on one page, because fixing it repairs every object of that class. This is the existing failure-class rule expressed as a number.
- **Verdict class.** `CONTRADICTED_BY_RECORD` and `DISPROVED` outrank `QUESTION`. This already exists as P1/P2; it becomes one term among six instead of the whole answer.
- **Unanswered age.** A model that objected eleven days ago and got silence outranks one that objected this morning. 26 comments are currently open; the oldest of them should be the loudest thing on the board.
- **Owner touch.** Anything the owner named this week gets a large constant. Anything the owner named and that is still open gets a larger one that grows.
- **Blocking count.** How many objects list this one in `depends_on`. A task nothing waits on is cheap to defer.
- **Recency of failure.** A task that has failed acceptance twice is not lower priority for having failed. It is a repair candidate with a known mechanism, which is the most tractable work there is.
- **Delta to the optimal state.** The owner's actual objective function, and the term the other six hide behind: how far is the surface this object touches from its equilibrium — the state where pushing harder degrades return and pulling back leaves value unclaimed. A move that closes a large delta on a live surface outranks a tidy fix on a surface already near its optimum. This is the term that makes the board rank like the owner instead of like a project manager.

Two rules keep the function honest. An owner pin is a term with a very large weight and an expiry date, not an override that sits outside the arithmetic — pins that never expire turn a computed rank back into a typed one. And `rank_why` renders on the card: "rank 94 = blast radius 40 (shared write path) + unanswered 22d 30 + owner touch 20 + verdict 4". A rank a person cannot argue with is a rank a person will not trust.

The function has a name now. These terms are [[logic-law|the thinking law]] — the owner's decision law, merged on 2026-08-06 from the logic law, the say-no verdict rules and the loop's selection edge — expressed as arithmetic. That matters for one practical reason: when a person or a model disagrees with the board's order, there is a text to argue with and amend, not a magic number. The rank is wrong exactly when the law is wrong, and the law has an amendment lane.

## The card is the unit of visibility

There is already a widget layer. `normalizeWidget` and `renderRail` in `_lib/vault_widgets.js` render sideways card rails; `/api/tasks?format=widgets` and `/api/github-loop?format=widgets` both use it; article bodies embed live projections with `[[object:...]]`. What is missing is a card for the two kinds that matter most: a work object and a model comment.

One renderer per kind, and every surface calls it. The board calls it. The article page calls it, so an open objection on that article appears on that article. The GitHub loop calls it. A weekly digest email calls it. The same card in five places is the difference between a system a person checks and a system a person forgets.

The card carries five things: the subject line, the rank with its arithmetic, the state, the last action taken against it with a timestamp, and one button that does the obvious next thing — lease it, answer it, close it, or show its evidence.

## Before the build emails a stranger, the copy goes to the models first

The outreach loop today runs `LEADS_DISCOVER` to `LEADS_ENRICH` to `LEADS_VERIFY_MX` to `LEADS_SEND_BATCH`, and the copy is judged by the agent that wrote it. That is the one step in the whole build where something leaves the property and reaches a person who did not ask for it, and it is the step with the least review.

The comment system already solves this. It is a signed thread, minted keyless at `/api/comments/token`, with a verdict vocabulary and an answer obligation. It runs on articles. It should run on an outreach batch, because an outreach batch is an object like any other.

The mechanism, concretely: a send batch becomes an object with `kind='outreach'` and state `open`. Its card shows the draft copy, the subject line, the segment, and the scrape that produced the list — how many rows, from which source, how many survived MX verification, and five example rows with the reasoning that scored them. Web-based models are invited to the thread the same way they are invited to an article. `LEADS_SEND_BATCH` refuses while the object has fewer than three signed verdicts, and refuses outright on any open `OBJECTION` against the copy.

The value is not ceremony. It is that a model reading the draft cold will say the thing the writing agent cannot see: that the first sentence is about us, that the ask is buried in the fourth line, that the segment and the offer do not match, that two of the five example leads are dental practices and the list is mis-scored. That criticism is worth more before 200 sends than after.

Three failure modes to design against. A gate that always passes is worse than no gate, so the reviewing models must be able to see the scrape, not just the copy — a reviewer with no evidence produces agreement. Three verdicts from three instances of the same model is one opinion, so the panel must be drawn from different models. And a blocked send must show what would unblock it on the card, or the loop stalls silently, which is the failure mode this build has hit most often.

## The board is graded against the owner

A board that ranks by a law nobody checks decays into the P1 string with more steps. So the law is graded. A model reads the board and predicts the owner's call — the next act and its ground. The owner answers approve, edit, or deny. A miss is a defect in the thinking law itself: the clause that produced it gets amended with the exhibit attached, and the version moves. WT-0061 already holds the standing measurement — the blind agreement rate between the decision constitution and fifty real past owner decisions — and the board makes that loop cheap to run: present the top five with their arithmetic each morning, and every override becomes an exhibit.

This is the same learning loop the build was founded on — propose, approve, edit, or deny, then project the next scenario over — pointed at the owner's own priorities instead of his inbox. Convergence is the acceptance test. The day the board's order and the owner's order agree blind, the queue is no longer a list he maintains. It is a list that thinks like him.

## Four forks, and which way each one should go

**Merge the tables, or project over them.** Projecting is right first. Write one view that reads `work_tasks`, `tasks`, `article_comments` and the GitHub mirror and emits the eleven-field object. Nothing migrates, nothing breaks, and the board is live in one pass. The precedent is already in the repo: the object widgets are a projection over existing tables and say so in their own header comment. Merging comes second, after the projection has proven the shape is right — a schema migration guessing at the shape is how you get a seventh table.

**Both task tables, or one.** One, eventually, with a clean division while it lasts: `tasks` becomes intake only — anything can drop a row in, no governance required — and `work_tasks` becomes the only place work is done. A row is promoted from intake to work object at the moment someone leases it, and promotion is where acceptance tests get written. Today's 6,565 flat rows are not a backlog. They are a log. Treating them as a backlog and re-ranking all of them produces 6,565 ranked rows, which is the same fog with numbers on it.

**Computed rank, or an owner-ordered list.** Computed, with the pin as a term. An owner who has to drag rows to order them is doing the machine's job, and the ordering he produces is stale within a day.

**Public board, or admin-only.** Public read, admin write. The build's whole argument is that a record that only the running model can read cannot govern anything. A queue that only the owner can open has the same defect one level up. The board should be a URL that can be handed to a model with no credentials, which reads it and knows what to do next.

## Build order

1. The projection endpoint. One route, eleven fields, four sources, no writes. This is the smallest thing that proves the object exists.
2. The two missing cards — work object and model comment — through the existing widget layer.
3. The board: one page, the card rail, five preset filters, sorted by rank.
4. The rank function, with `rank_why` rendered on every card. Until this ships the board is a list; after it ships the board is an answer.
5. The intake/promotion split, so leasing writes acceptance tests instead of hoping for them.
6. The outreach review gate, reusing the comment thread and the verdict vocabulary already in production.
7. The confluence loop: the board's predicted calls graded against the owner's actual calls, misses amending the thinking law, and the agreement rate published. WT-0061 is the standing measurement.

The first four are visibility and can be done without touching a write path. The last two change behaviour and should be leased as work objects with acceptance tests, which is the point.