---
name: "convention-comms-owner"
type: convention
description: The standard for anything an agent puts in front of the Owner to read or act on — the scannable decision-and-action header, the plain-language escalation that leads with a recommendation, the standing operator report and Owner-session agenda format, and instructions written for someone who does not live in the tool. Read before commenting to, escalating to, routing to, reporting to, or writing instructions for the Owner, so the decision and the required action are legible without reading the full thread, the code, or a follow-up chat. Owner legibility is a first-class output of the fleet, not a courtesy; as the fleet does more autonomously the Owner's read time becomes the binding constraint. Companion to convention-ticket, which holds the Linear specifics of an instruction the operator must action; this holds the register and format. Grown as it is applied.
license: CC BY-NC-SA 4.0
---

# Owner comms

How an agent writes anything the Owner has to read or act on, so he can act from the top of it without reconstructing the decision from a long thread, the code, or a follow-up chat. The failure mode is quiet and expensive: a comment that is a correct audit record and an unusable instruction at the same time. The thread is thorough, every verdict is right, and the Owner still cannot tell what was decided or what is now his — so the gate is slow, and work that reached his lane sits there. Legibility to the Owner is a first-class output of the fleet, not a nice-to-have; as the fleet does more autonomously his read time becomes the binding constraint (APP-575), so this compounds.

## When this applies

Any output whose reader is the Owner and whose purpose is a decision or an action: a gate handoff at merge, a Prism verdict routed to him, a Blocked escalation, a routing decision surfaced by Relay, an operator's cycle report or Owner-session agenda, a decision put to him, or a set of steps for him to run. It does **not** change agent-to-agent comments (the `[exec]` / `[qa]` / `Relay —` audit record stays exactly as it is) — it adds an Owner-facing surface on top of that record, it does not replace it.

## The header — decision and action first

Lead every Owner-facing hand-off with a short, standard, scannable block, above the technical detail:

- **Decision** — what was decided (or what is being asked), in one line.
- **Action needed** — what the Owner must do, or *"nothing beyond your yes"* if the agents carry the rest. Where he must do something, write it as numbered, literal steps (per `convention-ticket`, *Writing an instruction the operator has to action*), one action per line, a decision kept separate from a thing to type.
- **Why** — one or two plain sentences, enough to decide on.

The full detail — exec / QA / Relay verdicts, waivers, the diff, the framework specifics — stays **below** the block for the audit reader. The test: the Owner can act from the first few lines without opening the thread, the codebase, or a chat. (Worked case: A1-219 landed back in his court to merge and he could not tell from a thorough, correct thread what he actually needed to do — the decision and the required action were never surfaced, only reconstructable — APP-729.)


## The live review — one item at a time, with a two-line lead-in

The header above shapes a **single** hand-off. A **live review** — a sitting where the Owner is taken through several items each needing his decision or his read — is a different shape, and the header alone does not carry it. Three rules:

- **One item per message.** Never a list. Four items in one message reads as a batch however cleanly each one is written, because it makes him hold all four in his head while composing a single reply that addresses all four — the same read-time constraint the header exists to relieve, one altitude up. *"Go through them one by one"* means one item per message, not one paragraph per item inside one message.
- **Each item opens with a fixed two-line lead-in, before the ask.** Line one names the **project** in plain words — the venture or repo, the label only, not the ticket key. Line two states the **ticket's objective** in one plain-language line: what the work was supposed to achieve, no jargon, few words. Then, and only then, the decision or the review ask. Leading with the decision leaves him reconstructing what the thing even is before he can judge it.

  > **Project:** `<venture or repo, plain name>`
  > **Ticket:** `<one-line objective, plain words>`

- **The next item is not raised until the current one resolves.** Stop after the ask and wait for his answer. Acknowledge a resolved item in one line if it needs it; queueing the next item behind it in the same message re-creates the batch the first rule removed.

This holds on **any** surface that puts a queue of items in front of him in one sitting — a delivery-loop hand-off, a QA batch, a `skill-coordinate` escalation set, a stand-up's attention list — not only a session conversation. (Worked case: a live review following a delivery-loop run, 2026-09-22, took **two** corrections in one sitting. First on a four-item batch — a decision, two PR reviews and a blocked-project note in one message: *"thats not one by one, that's 4 in one go."* Then, once corrected to one item per message, on the first single-item message, which led with the decision rather than the context: *"important to give me some context of what project this is for and what the PR was supposed to achieve. simple, concise, few words for the ticket context and label only for the project."* The shape above is what was used for the rest of the session. APP-1652.)

## Escalations — plain language, and a recommendation

When a decision is escalated to the Owner, the opening is for a non-engineer reading it cold:

1. **What happened, in plain language** — no framework, API, or internal names in the opening; describe the situation, not its implementation.
2. **A recommendation, stated — and governance checked first.** If a convention or standard already prescribes the resolution, say so and recommend it. Never present N co-equal options when canon already has an answer; never hand the Owner an open-ended menu where a recommendation is possible. A stated recommendation he can accept or override is the deliverable, not a set of choices for him to adjudicate.
3. **What the yes costs him** — spell out that accepting needs nothing further from him where the agents handle the rest (*"merge the four done now, I file one follow-up for the last two — nothing needed beyond the yes"*).

The technical detail follows below for the QA / build audience. Test: the Owner can decide from the first three sentences. (Worked case: a Storybook blocker on A1-200 was escalated engineer-to-engineer — RSC internals, three open-ended options, no recommendation — when `convention-storybook` already prescribed the answer; it took a plain-language re-explanation with a recommendation before the decision took seconds — APP-584.)

## The forward format — an operator hands up to the Owner

An operator is the first escalation target for its vertical and the Owner the second (`skill-operating-loop` step 5; Owner ruling 2026-09-03, APP-962). When an operator forwards a decision it could not take, the item is the decision-item format above with **two fields added**, both stated concretely rather than as labels:

* **Category** — which of the five it sits in: strategic context · how and where · prioritisation within the mandate · human faculties · authority.
* **Failed test** — which of the three grant tests it failed, named: *outside the vertical* (the consequence lands elsewhere), *irreversible or unbounded in cost* ("this changes a client-facing price"), or *inconsistent with the goal or mandate*. A category-4 or -5 item names the faculty or authority it needs instead.

The format is the detector. A forward that names no failed test is, by construction, an over-forward — the operator has handed up something its own grant covers — and the Owner returns it without reading the thread. Under-forwarding shows in the decision log instead: a consequential ruling with no logged citation, or a call logged as reversible whose consequence turns out not to be, both read in the weekly session against the goal. Both failure modes are otherwise invisible from outside — a busy operator and an over-cautious one look identical — so the forward states its own justification and the judgement becomes a property of each message. The delivery-leg-to-operator hop uses the lighter shape already in `convention-linear` (*Executor*): the routing comment names the category and the question, nothing more.

## The sign-off brief — exceptions only, each with a recommendation

Where the Owner has to sign something off, he receives the **brief, not the artefact** (`skill-operating-loop` step 5, *Assessment before escalation*; Owner ruling 2026-09-11). The operator has already read the whole thing against its sources; what reaches him is the residue that is genuinely his. The format is fixed so that reading it is a sequence of rulings rather than a review:

* **One line per judgement call, each with a recommendation** — the call, the two readings, the recommendation, in that order: *"Returns window: the draft says 30 days, the store setting says 21 — recommend 30."* No call arrives without a recommendation; an operator that cannot recommend has not finished the assessment.
* **A closing checked-and-fine line** — what else was read and found sound, stated as coverage rather than as reassurance: *"The other five pages read against the live store, the fulfilment arrangement and the UK base; nothing else needs you."* This is what makes a short brief evidence of a full review rather than of a thin one.
* **The limits of the review, where they carry consequence** — a competent sense-check is not professional legal, tax or safety advice, and the brief says so rather than leaving it implied.
* **One decision, one surface** — the brief goes on the ticket that carries the sign-off and the binding act, not on the review ticket, so the decision and the act live together (the section below).

The register is the header rule above: decision and action first, plain language, and nothing he has to open in order to understand the question. Where he genuinely must open something — a rendered page, a preview — it is pinned as a Link rather than described (*Review artefacts the Owner has to open*). Length is the working test: a sign-off brief he cannot read in about five minutes still has material in it that the assessment should have absorbed (APP-1352).

## One decision, one surface — a run that supersedes an open Owner ask

The Owner's review queue is only readable as a list of *distinct* decisions. A fleet run whose output supersedes an Owner ask that is still open — a shortlist ticket asking him to pick an angle, then a draft ticket asking whether *this* angle stands — leaves two tickets carrying one decision, and creates an ordering hazard: answered on its own terms, the superseded question yields a ruling on a shortlist the fleet has already moved past, which the fleet must then unpick.

* **The run that supersedes owns the consolidation, in the same pass.** Whoever creates the superseding ask **comments on the superseded ticket** naming where the live decision now sits ("The decision on this now lives on MRP-47 — this shortlist is superseded by the draft there; no separate answer needed here"). It is a **pointer, not a state change**: the superseded ticket stays where it is, carries no `blockedBy` (coordinate cannot read relations at board scale — APP-976), and is folded or closed by the operator or triage on their own read. What matters is that the Owner meets one live question on whichever ticket he opens first.
* **Do not commission work that pre-empts an open Owner decision without consolidating that decision first.** Running ahead of an open ask is sometimes the right call — a draft he can say yes to is a smaller ask than a pick plus a week's wait — but it is exactly the manoeuvre that orphans the earlier ask. Where the fleet chooses to run ahead, the consolidating comment above is part of the commission, not an afterthought.

(Worked case: MRP-41, In Review from 2026-08-14 asking for one of three launch-piece angles, and MRP-47, In Review from 2026-08-18 with angle 1 drafted in full and asking whether it stands — both High, both assigned, neither pointing at the other, consolidated by hand at the stand-up on 2026-08-19 — APP-1031. Same shape one tier down: APP-710, an approved ADR superseding a build ticket's criteria with nothing updating what it superseded.)

## The operator standing report and Owner-session agenda

Every operator reports its cycle and runs its weekly Owner session in one shared format, so a report reads the same whichever vertical it comes from and the Owner learns one shape, not five. Validated live on the `task-bottrader-operator-loop` trial and Owner review, 2026-08-13 (APP-869); templated identically across all operators (bara, apps, a1, mrp, bottrader). It is a specific, recurring instance of the header and escalation rules above, not a separate register.

**The standing report skeleton — four parts, in order:**

1. **Status** — where the vertical stands against its goal, one headline line, carrying the RAG health flag.
2. **Decisions pending** — the mandate-edge items awaiting the Owner's ruling, each in the decision-item format below.
3. **Decided** — what was ruled or shipped since the last report, one line each; a ruled item then drops off next cycle.
4. **Forward** — the next cycle's planned moves and any upcoming plans wanting the Owner's light review. Every line under Forward takes exactly one of three shapes; anything else is a defect in the update: (a) **a dispatched move** — cites a ticket id that exists; (b) **an observation with no owner** — marked as such; (c) **an item awaiting an Owner ruling** — marked, with the item named. Forward is where the operator makes commitments, and `convention-ticket`'s rule that every obligation is encoded as structure rather than prose applies to it as it does to a ticket: a well-reasoned line that names no ticket is an intention that evaporates between cycles, and the report reads identically whether it was dispatched or not. (Worked case: the A1 loop wrote that the Meirion cutover chain A1-267 → A1-268 → A1-34 was "worth sizing into a hold window with Aide" on 2026-08-14, wrote it again verbatim on 2026-08-17 with all three tickets untouched in Todo, and it moved only when A1-362 was filed — APP-999.)

**The RAG health key**, used on the Status line and as each project/initiative's native health flag (`convention-project-status`):

- 🟢 **on track** — moving toward the next gate, no decision needed.
- 🟠 **needs a decision or at risk** — a ruling is pending, or a KPI is drifting off target.
- 🔴 **blocked or off target** — the critical path is stalled, or the vertical has missed a target.

**The key's default rendering — flag-leading sentence(s), then bullets, never prose-first.** The key above fixes *which* flag a health read carries and nothing about the shape it arrives in, and the same three flags buried in paragraphs are unreadable at exactly the altitude they exist to serve. So any Owner-facing status or health content carrying this key — a per-initiative or per-vertical progress read, a KPI or milestone health summary, a stand-up's goal-progress open — renders as **one or two sentences leading with the 🟢/🟠/🔴 flag, then short bullets for the supporting detail**. A prose paragraph is never the primary unit. This is a rendering rule, not a second key: it generalises the *one headline line* already required of the standing report's **Status** part to every surface the key reaches, so one shape holds whether the read covers one vertical or five. It applies **unprompted**, including to Aide's Owner-facing output, which *When this applies* already scopes — needing to be shown the unreadable version first is the cost this removes, and it is a cost paid in the Owner's read time, which is the binding constraint this whole convention exists to protect. (Worked case: the first goal-progress overview written into the stand-up's new goal-progress open, 2026-10-07, used a long paragraph per initiative. The Owner's reaction, reported from the session: *"very unreadable."* The same content reformatted on the spot to flag-leading sentences plus short bullets — *"sooooooooo much better … this last format is so much better for me to understand my day"* — was the shape the rest of the session used, and he asked in the same breath that it be captured in canon rather than relearned once per surface — `APP-2135`.)

**The decision-item format** — every item under *Decisions pending* carries four fields, sharpening the recommendation rule above into a fixed shape:

- **Decision** — the call to be made, one line.
- **Recommendation** — the operator's stated answer, governance checked first (never a menu where canon has an answer).
- **Why it matters** — the stake, in plain language.
- **Risk of deciding vs not** — what accepting costs, and what waiting costs, so the Owner can weigh urgency.

**The tables**, where the vertical has milestones or KPIs to show:

- **Milestone timing** — milestone · target date · status (🟢/🟠/🔴). A milestone with no target date shows the date cell flagged as a gap, never left blank (`convention-project-status` — a blank reads green to a careless eye).
- **KPI snapshot** — KPI · baseline · current · target · trend, so movement is legible against the target rather than reported as a raw number.

**The Owner-session agenda document** is the durable surface for the weekly session (`skill-operating-loop` step 8): one standing document per vertical, named **`<vertical>.owner-session-agenda`** (the dotted document style `convention-linear` prescribes; `a1.owner-session-agenda`, `mrp.owner-session-agenda`, `bara.owner-session-agenda`), on the vertical's initiative. It is **refreshed each loop, never rebuilt**, and the mechanism that makes that true is a lookup before any write: **list** the documents on the vertical's surface and match the canonical name within that set, never query the canonical name on its own; if nothing in the set matches, create it; if more than one exists, consolidate into the canonical name and mark the others superseded with a pointer; and if exactly one exists under a **near-miss** name — the same agenda, filed under a title that is not the canonical one — rename it and carry it forward rather than creating a second, which is what the listing is for. A name query cannot tell that third case from a genuinely new vertical: it returns nothing, the create branch fires, and a month-old agenda carrying open decision items is orphaned in place, invisible to every future lookup and never marked superseded. The listing costs one call and removes the class, and it is the same shape as `convention-linear`'s list-then-ID pattern for dotted names. (Worked case: the Apps agenda sat as *Apps portfolio — Owner session agenda* from 2026-08-14, unique and non-canonical, with six open decision items on it; the prescribed lookup would have found nothing and created a duplicate, and the 2026-09-14 loop avoided that only by listing every document on the initiative — an incidental choice, not a prescribed step — APP-1430.) — never delete, so the record of what was raised survives. It holds only *open* items in the decision-item format, in **two sections**: *Open — decisions for the session* (initiative-level — strategy, goals, resources, targets, and mandate-edge escalations) and *Async — not for the session* (delivery and lifecycle gate verdicts — a merge, a promote/retire, a design sign-off — which are ruled in Linear or at the daily stand-up). The split is what gives a gate item a correct home rather than promoting it into the session or dropping it, and it is what keeps the size honest: a misfiled gate item inflates the sized calendar ask. Async items alone never justify **shortening** the slot: the session is **never released and never reduced** — it runs its full allocated time, and async items simply do not consume it, because they are ruled in Linear or at the daily stand-up rather than in the session. So a slot whose agenda holds only async items is still a full slot of session-level work to be found, not a short session. The confirm-or-reduce call and the 10-minute floor are **retired** (Owner ruling, Aled, 2026-09-22: *"I actually see us using the full allocated time every week"*), and `skill-operating-loop` step 8 is the authority on the session's length — read it there rather than restating a duration here. This does not relax the sizing discipline above: a misfiled gate item still inflates the calendar ask, it just no longer shortens the session (APP-1657). **The carry-forward rule is the inverse of the drop-off rule:** an item leaves the agenda only when it has been ruled and logged to the decision log. **The refresh opens with an inbound scan — carry-forward and drop-off between them cannot see a new item.** Both rules operate on items *already on the agenda*; neither reads the board, so an agenda refreshed from its own prior contents is closed to everything filed since. Before touching the item list, the refresh therefore **scans the vertical for tickets filed or escalated since the previous refresh** — the initiative-level shapes that belong under *Open*: `STRATEGY:` and goal-layer tickets, mandate-edge escalations, and anything raised against the vertical's initiative — and places each one under *Open* or *Async* on the split above, or records why it belongs on neither. The previous refresh's own timestamp is the window's lower bound; the document is its own record of when it last ran, so the scan needs no separate state. An agenda that ran a refresh without the scan is **incomplete, not merely short**: an item filed between two refreshes is invisible to every refresh that follows, and nothing else in the loop puts it back — the ticket ages on the board while the surface that was supposed to carry it to the session never sees it. This is distinct from the re-grounding rule below, which catches a *stale* item; this catches a *missing* one. (Worked case: A1-427 — a1.Agents has no charter, objectives or KPI tree — and A1-428 — a1.Advisory's live nine-epic project sits under no outcome-initiative — were filed 2026-09-14T05:51Z by that morning's `task-strategy-review`, both Medium, both goal-layer, and both flagged in the same day's a1.standup entry as belonging beside A1-229 for the Tuesday session. The weekly A1 loop refreshed `a1.owner-session-agenda` roughly an hour later, at 07:01Z, sizing that same Tuesday 2026-09-15 session — and carried three items, A1-229, Heroes and Muse, with neither new ticket among them, though both existed before the refresh ran. APP-1473.) **Every item under *Open* carries a backing ticket, filed when the item is first raised.** The agenda is a document, and Linear cannot report on prose: an item held only here has no priority, no age the board can surface, and nothing for `convention-linear`'s escalation ladder or the daily stand-up's read recipe to act on, so it survives only as long as a hand copies it into the next refresh. The loop therefore files a ticket for any *Open* item that lacks one — in the vertical's own team, the decision in the title, the decision-item format in the body — and the agenda entry cites it. The ticket is what ages; the agenda is the view onto it. Without one, a loop that misses a cycle drops the item with no trace anywhere, where a ticketed item at least keeps ageing on the board. (Worked case: the Mr Pritchard item *publishing an identifiable former colleague's stated position* was raised on 2026-08-14, dropped unruled from the 17 August agenda, restored on 22 August and re-grounded on 2026-09-14 against six drafts then in review — and has never carried a ticket, while every other open item on that agenda, MRP-19 and MRP-21, does — APP-1435.) An item that is absent from the agenda and absent from the decision log is a refresh defect, and a loop self-checks its own refresh against the previous version for exactly that. Each item may carry a one-line *carried since <date>* stamp so an ageing item reads as ageing rather than freshly raised. (Worked cases: `bara.owner-session-agenda` opened on 2026-08-14 with MBN-266, a merge gate, as item 1, three of four items async, and MBN-266 reached day six unruled — corrected by the two-section refresh of 2026-08-17, APP-997. Mr Pritchard carried two agendas under two naming styles for five days, the 2026-08-17 loop having declared itself the "first refresh" without finding the 2026-08-14 document, and an unruled standing policy item was silently dropped until the 2026-08-22 loop read both — APP-1053.)

## Recurring output — read your last one before writing the next

Every scheduled or recurring producer — an operator loop, the daily brief, any status writer that runs on a cadence — reads its **own last output on the target surface before writing a new one**. If a prior output already falls inside the current cadence window (a second run at the same altitude in the same window), emit the **delta** since it rather than a duplicate standing report, and set any health / RAG flag **deliberately** — re-affirmed only where still true — never as an unconditional per-run stamp. Ten thin loaders over one loop, and a churny schedule, make a second same-window run a near-certainty rather than an edge case, so the precondition is written once here for every producer (APP-884).

The companion rule for a lapse a recurring surface keeps re-reporting: **escalate by recommendation, not by repetition.** A surface that restates the same overdue or blocked line every run decays into noise; where a standing decision would clear it, carry that recommendation **once** (per the escalation rules above), then let the age ladder do the escalating rather than re-stating the lapse each run (APP-866). This is the `convention-linear` age-ladder principle applied to recurring output: restating without escalating is signal decay, not urgency. (Worked instance of the pattern: a daily brief that re-reported the same five overdue items with identical lines for eight weeks while never once carrying the recommendation that would have cleared them — `task-daily-report`, *Overdue under an open rescope*.)

## Control-plane actions — recommend, never assert

Pausing, resuming, disabling, or rescheduling a scheduled job lives on the scheduling surface (Claude Code → Schedule, the Cowork task settings) — a lever only the Owner holds. An agent that wants such a change writes it as an Owner-facing recommendation with an actor and a mechanism — *"Recommend pausing the delivery loop (Claude Code → Schedule → pause) until APP-832 is fixed"* — never as an assertion that the state already holds (*"the delivery loop is paused"*). The agent cannot make that claim true, so writing it in the grammar of a fact states a falsehood a later reader takes as authoritative.

This binds on the read side too, and it is the one place this convention reaches into agent-to-agent prose: a state-of-the-system claim in any ticket comment is a recommendation unless the writer holds the lever, so a consuming run weights it that way rather than obeying it. Holding the lever is not the whole test, because a claim about a **connector-held resource** — a store's catalogue, a calendar, an inbox, a scheduler — decays regardless of who wrote it: the lever makes it true when written, not when read. A consuming run, and above all a run about to escalate or restate an Owner-facing recommendation built on such a claim, re-verifies it against the connector first and, where the state has moved, corrects the record and withdraws or restates the recommendation rather than carrying it forward. (Worked case: `operator-bara`, who does hold the Shopify lever, wrote on MBN-250 on 2026-08-14 that three bundles were "live now with empty descriptions" and recommended hiding them; on 2026-08-17 Reach read the catalogue and found all five bundles `DRAFT`, `publishedAt: null` — the recommendation was moot when written, and had been ageing in the Owner's lane as a non-decision — APP-990.) Where the claim contradicts direct evidence — a scheduled run that has fired is, by construction, not paused; the scheduler is the authority — the evidence wins. The mirror risk is worse than the case that prompted this: an agent writing *"the loop is running normally"* or *"this was approved"* when it holds no such lever would licence action rather than prevent it. (Worked case: a Relay comment *"the delivery loop is paused"* on A1-263 stopped a legitimate scheduled run from draining a six-ticket queue; the loop was never paused and the merge-leg fix it cited had already landed — the comment was both unenforceable and stale. APP-836, Owner ruling 2026-08-12.)

## Attribution — what the run saw against what it was told

An unattended run that reads other passes' captures writes a report built mostly from other agents' figures, and nothing in the grammar of that report separates them from its own. The flat declarative the Owner reads as *this run observed this* is the same sentence a run writes when it is restating a number it read in a note body three hops back. Two rules bind on any unattended pass whose output reaches him:

- **Every figure carries its provenance.** A figure in a report or an Owner notification is marked **observed** — this run read it from the primary source — or **reported** — it came from another pass's note, comment or capture. A reported figure never appears without its source: *"two queue notes report four starved runs"*, never *"the delivery loop has produced nothing for four consecutive runs"*. Where a claim is cheap to verify and the run did not verify it, the run says so rather than repeating it flat; a blast-radius count that two `get_issue` calls would have settled is either settled or attributed, never asserted.
- **An unattended pass leads with what it owns.** The headline of an Owner notification is the finding inside the pass's own remit; a relayed cross-lane item sits below it, attributed. Ranking the notification by the largest figure in the queue is what puts a board item the pass neither owns nor can act on above the pass's own headline — a leverage ranking orders the work, it does not order the message.

The marking travels down a fan as well as up: **a fan subagent's brief is itself a relay hop**, so a parent cannot tell a figure the subagent verified from one it read in a note body unless the subagent marks it.

**A brief that a fresh-context leg will act on carries the same marking, and never asserts a review outcome it cannot quote.** The rules above stop an unattributed figure reaching the Owner; this stops one reaching a gate. A brief reads confidently by design — it names the device, the commit, the browser — and a leg told that a change was "reviewed and re-verified" has been handed a conclusion where the framing promised it a premise. So a review, approval or verification outcome appears in a brief as a quotation of the ticket's own latest comment on that topic, with its timestamp, or it appears marked *outcome not found in the ticket record*. A paraphrase is the one form not available, because it is indistinguishable from a confirmation. (Worked case: a merge-leg brief stated that an independent review had found and fixed a flaky test and that the work was re-verified on a green head. The ticket's record showed the approval signal set at 19:08:11Z, the de-flake commit pushed at 19:45:32Z — after it — and the comment announcing that commit closing *"Requesting a fresh review pass on the new head before merge"*, with nothing after it answering and no PR review on record. The leg held the merge and asked for re-confirmation; a more trusting pass would have merged on a stale approval — `APP-1877`.)

The observed/reported marking therefore applies to a subagent's return exactly as it applies to the report the parent writes from it.

**A claim that something does not exist carries the surface it covers.** The rules above mark where a figure came from; this marks how far a *negative* claim reaches. "The site loads no Adobe font kit", "that isn't built", "there's no ticket for it" are read by the Owner as claims about the system, while the search behind such a claim has almost always covered one surface — one directory, one local branch, one board. So a negative assertion to him names its surface and claims no more than its surface — *"not on `main` and not on production; an open preview PR carries it"* — and where a check cheaper than the assertion was available and was not run, the run says which, exactly as the reported-figure rule above requires. Four surfaces are normally read into a negative claim about delivered work, and each is either checked or excluded by name: every remote branch and open PR, not only the working tree; the board, for a ticket on the topic; the live deployment; and the checkout's own freshness, since a stale `main` answers a question about today's code with last week's. The framing is the expensive part, not the conclusion — an unscoped "that can't be right" has to be withdrawn and corrected even when the narrow conclusion turns out to hold, and the correction spends more of his read time than the scoped claim would have. (Worked case: asked whether everyone gets Helvetica Neue via Adobe, a session grepped `src/` on a local, possibly stale `main` and told the Owner the code loads no Adobe Fonts kit. He pushed back, because another session had discussed the kit that day. A proper check then found the kit wired on an open preview PR, a live build ticket (A1-412) and a closed setup ticket (A1-411) — while production genuinely was not loading it. The conclusion about production was right and the unscoped framing still had to be corrected — APP-1721, 2026-09-23.)

This bites harder here than in a ticket thread because an Owner notification is a scarce channel and its first sentence is the whole message on a phone banner, so an unattributed relay in the lead does not only mislead — it spends the channel on someone else's lane. The rule lives once, here, and is cited rather than restated by the passes that commit it (`skill-ops-retro` step 6): it is not Pulse-specific, and every unattended run that reads another pass's capture can commit it. (Worked case: the `task-pulse-refine` run of 2026-09-07, caught live by the Owner asking *"why are you commenting on the delivery loop?"*. Its notification read *"Delivery loop has produced nothing for four consecutive runs — one unrouted ticket (A1-388) is blocking six build leaves, and a canon save was silently lost three days ago"* — three defects in one sentence: figures written by `routine-delivery-loop` into two note bodies, read by a fan subagent, summarised into a brief and restated by the parent as its own finding; a "blocking six build leaves" count taken from a note body, with A1-388's own state, assignee and dwell verified but the transitive chain to the other five leaves never tested, at a cost of two `get_issue` calls; and a lead inherited from the leverage ranking, which pushed the genuinely Pulse-owned headline second — APP-1150. Adjacent to APP-948, a ticket body asserting an Owner ruling that never happened: that one is fabricated provenance in a ticket body, this is unattributed relay in a run summary.)

## Instructions to execute — write for someone who does not live in the tool

When the Owner is asked to carry out steps himself, the register is a first-time user of that tool, often reading mid-task on a phone, not a daily user of it:

- **Name the click path, not the concept.** "Open DevTools → Network tab" beats "inspect the network requests".
- **State what he should see at each step**, so he can tell whether it worked before moving on.
- **One action per step.**
- **If a step needs a hidden or configured UI element, say how to reveal it first** — before referring to it (right-click the table header to show the Domain column, *then* read the Domain column).

Correct and unfollowable at the same time is the failure — the steps name the right actions but assume the reader already knows the tool's furniture. (Worked case: a PostHog verification walkthrough on A1-116 was accurate and still unusable, assuming the operator knew to right-click a header to enable a hidden column — APP-618, observation 1.)

## Clock times — in the Owner's timezone, as he will read them

Every clock time an agent puts in front of the Owner — an ETA, a check-in, a next-report time, a timestamp naming a record he has to find on screen — is stated in **Europe/London**, the timezone he reads in, with the UTC value in brackets only where the run also needs it for a machine check: *"~20:50 (19:50 UTC)"*. Resolve the offset for the date rather than assuming one. Europe/London is BST (UTC+1) through the summer and GMT (UTC+0) from the last Sunday in October, so a rule or a run that hard-codes `+1` is wrong for about five months of the year — take the offset from the clock (`TZ=Europe/London date`), never from arithmetic on a remembered offset.

A bare UTC time is not merely less convenient; it is silently wrong at the point of use. The Owner reads it as his own clock, so a stated ETA arrives an hour late against the wait he is actually sitting through, and a timestamp naming a record he must find on screen names a different record from the one meant. Neither failure announces itself: the agent's figure is correct, the sentence reads as complete, and the Owner acts against the wrong one.

The companion rule is for the wait itself: **where a wait runs longer than about ten minutes, say once when the next report is due**, in his timezone, rather than going quiet. A silent wait and a stalled run look identical from his side, which is what turns a fifteen-minute CI wait into a chase.

(Worked cases: a session gave CI finish and check-in ETAs as "~19:50 UTC" and "next check-in 15:11 UTC" across an eighteen-minute CI wait it reported nothing during, and the Owner chased twice — "it's been a while", "it's 20:43 now" — because the times read an hour off and the wait looked longer than it was, APP-1722, 2026-09-23. The next day the A1-515 Owner-assisted preview steps named Sanity delete targets by their UTC `_createdAt` — "the card created at 19:15" — while Studio showed those same cards at 20:15–20:19 in his local time; his first delete landed on a different card from the one named, which happened also to be a valid target, so nothing was lost, APP-1722, 2026-09-24.)

## The link travels with the reply — and says what it is for

Where a run produces something the Owner is expected to look at, the reply **carries the direct link to the surface the looking happens on**, not just the artefact's name. The trigger is *producing* the thing, not being asked for it: the Owner having to ask for a link is the failure this closes. Naming a review without linking it makes him do the retrieval — open the tracker, find the ticket, find the PR, find the review surface — which is exactly the cost this convention exists to remove, and it is silent: nothing marks a missing link, the reply reads as complete, and the work simply waits longer.

The surfaces, and which link each one means:

* **A pull request** — the PR URL, **and** the Linear review link where `linear-code[bot]` has posted one, because the review surface is where the Owner actually reviews. The PR alone is the diff, not the review.
* **A deployed preview** — the preview URL.
* **A ticket needing his decision** — the ticket URL.
* **A document, deck or design** — its link.
* **A design-review round** — the round document.
* **A component build** — the Storybook or Chromatic URL for the story under review, not the build's landing page.
* **A design comparison** — the Figma reference being compared against (the frame or node link), beside the build it is compared with.

**A visual diff makes the visual artefact the trigger.** Where the Owner's review is being asked of a change with visual output — styling, layout, type, imagery, copy on a page — the review is of how it looks, not of the code, so the hand-off carries the PR link **and** a durable visual artefact: the deployed preview where one exists; where none does, a rendered before/after — screenshots or an Artifact — or, where the agent cannot render it at all, the operator step that produces one, named explicitly (a Shopify theme needs an operator `shopify theme push --unpublished`, `convention-shopify`). Before writing "waiting on your review", check whether the diff is visual; a visual review handed over as a GitHub link alone asks him to review the wrong thing. In the Owner's words: "the reason why we wait for me to review is when there is something that needs a visual approval. if you don't provide me with the link to the build then all I am looking at is technical stuff in github and not what the review is for." (Worked case: mbn-theme PR #15, an h6 heading-font CSS fix, was handed to the Owner as "waiting on your review" with only the GitHub link, although the same session had earlier built an Artifact type specimen for exactly this kind of look — APP-1543.)

**Name what each link is for.** "Review in Linear" and "the diff on GitHub" are different asks; a bare row of URLs restores the retrieval cost in another form. One link per line, labelled with the ask it carries.

This is the **reply-side** rule and it sits alongside the pinning rule below, not instead of it: where the thing he must open is a review artefact with a durable home, it is *also* attached as a native Linear Link. The Link makes it findable later; the link in the reply makes it openable now.

**A leg's handoff does not reach him until the driving session repeats it.** Where a sub-agent or delivery leg writes the review handoff — a `[qa-review]` comment on Linear naming the PR, the Storybook or Chromatic build and the Figma reference — that comment is the durable record, not the reply. The session he is talking to **repeats every link the handoff names in its own reply in the conversation**, one per line and labelled with its ask, whenever it hands a human review to him; a pointer to the Linear comment restores the retrieval cost this section removes. In the Owner's words: "share the links here for me to review – this needs to be a standard throughout each human review." (Worked case: the A1-461 handoff for PR #149 put the PR, Storybook/Chromatic and Figma links only in a `[qa-review]` Linear comment, and the Owner had to ask for them — APP-1620, 2026-09-21.)

(Worked case: the 2026-09-10 A1-412 session opened a PR on `assoc-one/meirionpritchard-com`, filed three tickets and reported on all of them. The preview URL was volunteered, because looking at the preview was obviously the point — and that is the shape the rest should have followed. The Linear review link, posted on the PR by `linear-code[bot]` and already read by the session, was never surfaced, and the Owner had to ask for it — APP-1306.)

## Review artefacts the Owner has to open — pin them, don't bury them

When an agent builds an artefact for the Owner to decide on — a calibration page, a comparison tool, a preview surface — that artefact *is* the decision surface, and he has to be able to reach it in one move. A review artefact described across a run of exec comments is a correct record and an unreachable tool at the same time: he has to re-read the thread to relocate the thing he is meant to look at. So the durable home for it is a **native Linear Link on the ticket** (the Links sidebar), not a comment mid-thread. The comment may still describe what was built, for the audit reader; the Link is what makes it openable without reading the thread.

The wrinkle is that a review artefact built in an unmerged PR has no durable URL — it lives only on that PR's preview, often behind Basic Auth, until the PR merges. So pinning is two-stage:

1. **A locator while the decision is live** — the throwaway preview URL plus the path (which PR/preview, which route), attached as a Link so the Owner can open it now. It is understood to be temporary and dies when the PR merges or the preview expires.
2. **A durable Link once merged** — when the PR lands and the artefact reaches its production surface (the `/prototypes` route, the published page), the **merge leg** attaches the durable production Link and supersedes the throwaway locator. Attaching it is part of closing the merge — the same actor that lands the PR — so the durable pin is never left to whoever happens to re-read the ticket later.

The Link mechanics themselves — how a Link attachment is shaped and added on the tracker — are `convention-linear`'s; this convention says only that a review artefact the Owner must open belongs in the Links, in these two stages, with the merge leg named for the durable one. (Worked case: A1-296, a nav-mark calibration page built on the PR #102 preview was described across several long exec comments rather than pinned, so relocating it took a re-read of the thread — APP-878.)

## What stays below

Everything that makes the record complete and auditable: the agent verdicts and their markers, the waivers and the signals they name, the diff and file paths, the framework and platform specifics. The block above is a lens onto that record for the Owner, never a substitute — do not drop detail to make the summary shorter, and do not let the summary drift from what the detail says.

## Relationship to convention-ticket

`convention-ticket` holds the Linear specifics of *an instruction the operator has to action* — numbered, novice-friendly, one action per line, a decision kept separate from a thing to type. This convention is the wider register and format standard it sits inside: it governs the header, the plain-language escalation, the operator standing report, and the write-for-no-familiarity rule across every Owner-facing surface, not only a ticket instruction. Where they touch, follow `convention-ticket` for the instruction mechanics and this for the surrounding brief.

## Quick checklist before handing anything to the Owner

- [ ] Does it open with **Decision / Action needed / Why**, above the detail?
- [ ] Is the required action stated plainly — numbered and literal where he must do something, or *"nothing beyond your yes"*?
- [ ] Does the opening avoid framework / API / internal names a non-engineer would not read?
- [ ] Is there a **stated recommendation**, with governance checked first — not a menu of co-equal options where canon has an answer?
- [ ] For an operator report or Owner-session agenda: the four-part skeleton (Status / Decisions pending / Decided / Forward), the RAG key, and the decision-item format (decision · recommendation · why it matters · risk of deciding vs not)?
- [ ] Every *Forward* line one of the three shapes — ticket cited, marked ownerless, or marked awaiting a named ruling? (APP-999)
- [ ] For an operator's forward to the Owner: category named, and the failed grant test stated concretely — never "needs your call"? (APP-962)
- [ ] The agenda found by its canonical name `<vertical>.owner-session-agenda` before writing, two sections (Open / Async), and nothing dropped that is not in the decision log? (APP-997, APP-1053)

- [ ] For an agenda refresh: was the **inbound scan** run — the vertical swept for tickets filed or escalated since the previous refresh, and each one placed under *Open* or *Async* or its exclusion recorded? An agenda refreshed without it is incomplete, not short. (APP-1473)
- [ ] For a recurring / scheduled producer: does it read its own last output in the cadence window and emit a **delta**, not a duplicate, with any health flag written deliberately? (APP-884)
- [ ] Does a recurring surface escalate a persistent lapse **by recommendation carried once**, not repeat it every run? (APP-866)
- [ ] No assertion of a control-plane state the agent cannot set? (A pause / resume / reschedule is written as an Owner recommendation with actor and mechanism, never as a fact.)
- [ ] Is every figure marked **observed** or **reported**, with a reported figure carrying its source — including a figure returned by a fan subagent? (APP-1150)
- [ ] Does an unattended run's Owner notification lead with the finding in its own remit, with a relayed cross-lane item below it and attributed? (APP-1150)
- [ ] Does any claim that something does not exist or is not done name the surface it covers — remote branches and open PRs, the board, production, the checkout's freshness — rather than asserting it flat? (APP-1721)
- [ ] For steps he must run: click paths named, what-he-should-see stated, one action per step, hidden UI revealed before it is referenced?
- [ ] Is every clock time in the Owner's timezone (Europe/London, offset resolved for the date, not assumed), with UTC bracketed only where a machine check needs it — and on a wait over about ten minutes, the next report time stated once? (APP-1722)
- [ ] Does everything the Owner is expected to look at carry its **direct link in the reply** — the PR *and* its Linear review link, the preview, the ticket, the document, the review round — each labelled with what the link is for, without him having to ask? (APP-1306)
- [ ] A review artefact the Owner must open (calibration page, preview, comparison tool) pinned as a native Linear Link — a preview locator now, a durable Link at merge with the merge leg named — not buried in a comment?
- [ ] Is the full audit detail still present below, and consistent with the summary?
- [ ] Tone clean per `cos.tov`?

## Tone

Calm, precise, sentence case, British spelling, no exclamation marks, outcome before adjective. (cos.tov.)