inventory.md

c137 Phase 0: the message inventory

Contents

The table
Counts
Default delivery, summarised for Phase 2
Not types: things the sources name that live elsewhere in the bones
Questions the inventory raised

Written: 2026-11-09, from the sources the plan names. Reader: Mark (review stop after Phase 2), Tyler at G2 (Q5: which messages flow first), c131's executor (the types entry), c133 and c136 (their one type each). Method: every message the roadmap implies gets a row; each row passes the brand's five questions (useful · clear · precise · necessary · beautiful) or is dropped. A thing that is not a message (a field, a rule, a port behaviour) is listed at the end so it is not re-proposed as a type.

Sources, as cited in the table

Cite	What it is
`1b21a3ce`	the 2026-11-05 roadmap session digest (`../market-analyst/sessions/2026-11-05-1b21a3ce.md`): Mark Peterson's ask for local feedback with a path to IT (first-hand advisor; parked idea), Tyler's open question on notifications ("I just don't know if we want that in people's faces"), Tyler's adopted idea of an OAuth-style Connect from the desktop app
prompt	Mark Parson's c130 initial prompt, "Conversant with web app": Notices from HQ; Confirmations: Identity, Censures ("Stop doing X, Y, Z"), "You are now responsible for.."; Training; Integrations: links to places on the web app
c133	Remediation Training plan: D8 (a `training-assignment` message with a `start-training` action; completion back as `training-completed`), D9 (not blocking by default), the trigger list (a finding, an enforcement, a censure, an assignment)
c136	Mechanic Access plan: R5 and the "grant notice is a message" pattern (operators are told when a grant opens; a summary at close), D7 (the native app's surface is a read-only Status line)
c131	Native App V1 plan: the Connect page and its states (not connected · signing in · connected · failed), D8 (ports and bones in V1, Connect confirmations flowing), D12 (grant line on Status), D13 (the plane connection); the connected-state sentence "You're connected to HQ. The configuration is managed there."
plan	this cycle's `plan.md`: the type list, D1–D8, R1–R7, Q1 (local enforcement notices before any plane)
c130	`research/platform.md` §2: the OS gives one notification channel with a per-app permission; per-type control is our layer; macOS and Windows deliver only from an installed, signed build

Direction words. overseer → citizen (the plane or a person at HQ to the person at the keyboard), citizen → overseer (a reply or a report back), qcontrol → citizen locally (no plane involved), and one more the roadmap implies: plane → operator (a message to the overseer's own inbox). Overseer and citizen are working words and never appear in a UI (D7).

Delivery words. off · inbox (kept, no signal) · tray (inbox + the tray count and its one line) · notify (tray + one OS notification). These are the citizen's defaults per type; the citizen changes them (Phase 2).

The table

Five questions: U useful · C clear · P precise · N necessary · B beautiful. A ✓ passes; a note says where it bends. V1 marks what flows at first (Mark, 2026-11-09): the Connect confirmation; local and plane enforcement notices if Tyler rules them in at G2 (Q5).

#	Type	Direction	Who sends	Source	Default	`required` may apply	U	C	P	N	B	Verdict	V1
1	`enforcement-notice`	overseer → citizen	the policy, automatically, when it acts on this machine	`1b21a3ce` (Peterson), plan	notify	yes: counted (D4)	✓ the Peterson message: what happened, how to reach IT	✓	✓ names the policy, the action, the time, the app	✓ the enforcement already interrupted the person; the notice is the context they lack	✓ a calm card, one action	keep	if ruled in
2	`enforcement-notice` (local)	qcontrol → citizen locally	qcontrol, from the local policy file; no plane	plan Q1 (default yes), `1b21a3ce`	notify	by the policy file; counted locally	✓ the same message should not wait for the plane	✓	✓	✓	✓	keep (same type, `from: qcontrol`; IT contact from qcontrol's config)	if ruled in
3	`hq-notice`	overseer → citizen	a person at HQ, signed	prompt ("Notices from HQ")	inbox	allowed when the plane allows it; off by default; counted	✓ announcements and letters: "what changes on Monday"	✓ a letter, signed	✓ when the sender is specific; the send form asks for a date and a scope	✓ the alternative is email nobody reads at the moment it matters	✓ letters, not alerts	keep	later
4	`identity-confirmation`	overseer → citizen	the plane, automatically, after Connect; again on re-sign-in and when HQ disconnects the machine	prompt ("Confirmations: Identity"), c131 Connect, `1b21a3ce` (Tyler's OAuth-style Connect)	tray	no	✓ "this machine is connected as…": the one fact the person should be able to check	✓	✓ machine, account, plane	✓ Connect is a trust act; the confirmation is its receipt and the first message in an honest inbox	✓	keep	✓ the V1 flow
5	`censure`	overseer → citizen	a person at HQ, in HQ's words verbatim, labelled (D6)	prompt ("Stop doing X, Y, Z"), c133 (a censure can trigger a training)	notify	yes: counted (D4)	✓	✓ when HQ writes plainly; we label, never rewrite	✓ names the behaviour and the period	✓ a censure that arrives by surprise in a review is worse	✓ labelled "From HQ", acknowledged, kept	keep	later
6	`responsibility`	overseer → citizen	a person at HQ	prompt ("You are now responsible for..")	tray	no	✓ ownership of an MCP server, a workspace, a policy exception	✓	✓ names the thing and what the owner does	✓ an assignment without an acknowledgement is an assumption	✓	keep (requires acknowledgement)	later
7	`training-assignment`	overseer → citizen	a policy (on a finding), an operator, or HQ with a notice	c133 D8, prompt ("Training")	tray	no (c133 D9: not blocking)	✓	✓	✓ this hazard, this length, this check	✓ the teaching moment is now, not at the yearly training	✓ hard-hat register, no shaming	keep (owned by c133)	later
8	`diagnostics-request`	overseer → citizen	a person at HQ	prompt and c130 plan ("diagnostics on request")	tray	no	✓ replaces a screen share or "send me your logs"	✓	✓ says what is in the package and what is not	✓ consent needs a message the person can read first	✓ a consent card: review, send, decline	keep	later
9	`sensor-state`	qcontrol → citizen locally	qcontrol, when it goes off or degraded and stays so	plan, c131 Status states (off · starting · on-local · on-connected · degraded)	tray	no	✓ an unprotected app is worth a line	✓	✓ names the app or the tap that went dark	✓ only for degraded and off that persist; routine on/off at boot stays in the tray icon	✓	keep, narrowed (the tray icon shows the state; a message only for a gap that lasts)	later (tray is c131 Phase 3)
10	`acknowledgement`	citizen → overseer	the person, by pressing Acknowledge	plan (R6), c130 ("what it sends: acknowledgements")	n/a (a state the operator sees)	—	✓	✓	✓	✓ the operator's proof that a notice landed	✓ shown as the message's state, never a new item	keep as a state transition carried back, not an inbox item	the mechanism ships in V1
11	`contact-it`	citizen → overseer	the person, from a message, with its context attached	`1b21a3ce` (Peterson: a path to IT), D5	operator's inbox	—	✓ the other half of the Peterson ask	✓ a reply with three prompts: what were you doing, what do you need	✓ the context (policy, finding, machine, time) travels with it	✓ without it the notice is a wall	✓	keep (in local mode: a mailto or URL from qcontrol's config)	with the enforcement notices, if ruled in
12	`reply`	both	a person at HQ answering in a thread; the person answering back	implied by 11 (a question needs an answer path)	tray for the citizen; inbox for the operator	no	✓	✓	✓ stays in its thread	✓ a contact-IT with no answer path is a black hole	✓	keep	later
13	`training-completed`	citizen → overseer	the app, when the check passes	c133 D8	operator's inbox (quiet) + audit log	—	✓ proof of correction	✓	✓ training, finding, time	✓ c133's record depends on it	✓ a state on the assignment in the operator's inbox, a row in the log	keep (owned by c133)	later
14	`diagnostics-sent`	citizen → overseer	the person, after reviewing the package	pairs with 8	operator's inbox	—	✓	✓	✓	✓	✓	keep (also `diagnostics-declined`: the same type, declined)	later
15	`connect-request`	citizen → overseer	the app's Connect, when the plane requires approval before an endpoint joins	`1b21a3ce` (Tyler's Connect idea), c131 D13	operator's inbox, only on planes that require approval	—	✓ on an approval plane	✓	✓ machine, account, requested by	bends: on a plane that admits any signed-in employee it is an audit event and an Endpoints row, not a message	✓	keep, conditional (a plane setting; question for Tyler)	V1 sends the connect; whether it is a message is the plane's
16	`grant-notice`	plane → operator	the plane, when a mechanic-access grant opens, acts for the first time, is revoked, or closes with its summary	c136 R5 and pattern; c134 D8	operator's inbox	—	✓	✓	✓ grant id, level, window, who	✓ the partner must know the door is open	✓	keep (owned by c136; the operator's inbox, c134)	later
17	`config-change` ("your plane changed X")	overseer → citizen	the plane, on publish	plan's type list	—	—	bends: the person has nothing to do with most changes	✓	✓	✗ a publish can touch twenty settings; the moment that matters is the enforcement (1) and the announcement is a letter (3)	—	drop: an announcement is an `hq-notice`; the moment is an `enforcement-notice`	—
18	mechanic-access notice to the citizen	overseer → citizen	the plane	plan's type list	—	—	bends	✓	✓	✗ the person at the keyboard has no action; c136 D7 and c131 D12 make it a read-only Status line	—	drop as a message; the Status line is the honest surface	—
19	observe-mode nudge ("we noticed X, nothing was blocked")	overseer → citizen	a policy in Observe	implied by the Observe mode	—	—	bends	✓	✓	✗ Rob's concern (`5c8785e2`): agents run wild, tons of attempts; the deliberate version is a `training-assignment` (7)	—	drop	—
20	endpoint-connected (to the operator)	plane → operator	the plane, per Connect	implied by 4	—	—	bends	✓	✓	✗ five hundred messages at rollout; the Endpoints page and the audit log are the surface; see 15 for the approval case	—	drop	—
21	reminder ("you have not acknowledged…")	overseer → citizen	the app	implied by `requires_ack`	—	—	✓	✓	✓	✗ as a type: it is the same message surfacing again; a rule in the bones (one re-surface in the tray the day before `expires_at`, never a notification)	—	drop as a type; keep as a rule	—
22	quiet-hours digest ("3 notices went to your inbox quietly")	app → citizen	the inbox	plan ("Nothing hidden")	—	—	✓	✓	✓	✗ as a type: it is the inbox's honesty line, a port behaviour	—	drop as a type; keep as the withheld-count line (Phase 2)	—
23	welcome / first run	app → citizen	the app, on install	implied by Peterson's "vacuum of information"	—	—	✓	✓	✓	✗ the inbox's empty state and the Connect page say it; an inbox should not be born with mail in it	—	drop; the empty state carries the sentence	—
24	app-update ("a new version…")	app → citizen	qupdate	c130 platform.md §5	—	—	bends	✓	✓	✗ invisible when working: the updater and the Status page's version line handle it	—	drop	—

Counts


Rows considered	24
Kept	16 rows, 15 distinct types (`enforcement-notice` appears twice: from the plane and from qcontrol locally)
Of which the citizen receives	9 (rows 1–9, plus `reply` when IT answers)
Of which the operator receives	`acknowledgement` (as a state), `contact-it`, `reply`, `training-completed`, `diagnostics-sent`, `connect-request` (conditional), `grant-notice`
Dropped	8: `config-change`, mechanic-access notice to the citizen, the observe-mode nudge, endpoint-connected, reminder, digest, welcome, app-update (three of them survive as rules or port behaviours, not types)
`required` may apply to	`enforcement-notice` and `censure` by default (D4); `hq-notice` only when the plane allows it. Always counted. Never the rest.
V1 set	`identity-confirmation` (the Connect confirmation) flows; `enforcement-notice` (plane and local) and `contact-it` if Tyler rules them in at G2; the `acknowledgement` state and the whole schema ship as plumbing (c131 D8)

Default delivery, summarised for Phase 2

Default	Types
notify	`enforcement-notice` (both senders), `censure`
tray	`identity-confirmation`, `responsibility`, `training-assignment`, `diagnostics-request`, `sensor-state`, `reply`
inbox	`hq-notice`
off	none by default; the citizen may set any type to off except that a `required` message still arrives once (Phase 2)

Not types: things the sources name that live elsewhere in the bones

"Integrations: links to places on the web app" (prompt) is the actions and links fields on every message: open-page to a finding, a policy, a training, a grant. One mechanism, not a type.
Acknowledgement is a state (acknowledged) carried back to the plane, and a row in the audit log (R6).
Reminders are one rule: a message with expires_at surfaces once more in the tray the day before, never as a notification.
The withheld count is the inbox's honesty line ("3 notices went to your inbox quietly during quiet hours").
The required count is a number on both sides, not a message.
Sender label "HQ" is a plane-set string (c0's proposal: the plane sets "HQ", "Security" or "IT"; we choose the default).

Questions the inventory raised

Local mode's path to IT (row 2, 11): with no plane there are no org settings. Default: qcontrol's config carries an it_contact (a mailto or URL) that the local enforcement notice's Contact IT uses; absent, the notice says so plainly ("This machine's configuration names no IT contact").
Approval planes (row 15): is "an endpoint must be approved before it joins" a plane setting Tyler wants in V1? If yes, connect-request is the second V1 message type.
Sensor-state threshold (row 9): how long must degraded last before it is a message? Default: five minutes, and only once per gap.
Does the overseer see seen? (plan Q2) The inventory assumes yes for requires_ack messages (seen, then acknowledged) and no dwell or read time anywhere (R6).