Thread: inbox rename — the plan

Written: 2026-11-13, from inbox-rename-prompt.md and the Qpoint Product session of 2026-11-12 (f8d58bc9). Reader: Mark, then Mark Peterson (the session's to-do: "Discuss the remediation and inbox direction with Mark Peterson"). Status: proposal, nothing built; every call in §9 is open. Problems: problem:enforcement-without-local-context (1b21a3ce), problem:findings-resolution-workflow (f8d58bc9). Touches: this cycle's inventory, bones and ports; qnative c4's inbox and settings pages; the lab mocks /pages/phase4/messaging-*; c133's training copy; c0's role words.

0. What the meeting said (f8d58bc9, 2026-11-12)

Mark demoed the native app's "Messages" section as a remediation engine: Gene in finance uses a personal account, HQ sends "stop using a personal ChatGPT account for work", Gene takes the training and the quiz, and the audit log records that something went wrong and was corrected. He framed it with Mark Peterson's point that a company never reaches 100%: security sets a posture as close to ideal as it can, then deals with the gaps as they come up.

Where the confusion came from (Rob, 48:02 and 55:57): an inbox is "another thing to check", and employees should not have to make it part of their lives. The homepage hero promises no changes for end users: qcontrol runs quietly, like endpoint protection. Rob would put the quizzes in the backlog and make this notifications, through the channels people already have, such as email.

Mark agreed (54:17, 54:48, 55:14): "I don't think it should really be an inbox"; it is "a way that security can say this finding's been resolved"; no channels of our own where channels exist, maybe not in V1; "let's not make this another thing that I'm supposed to be aware of on the daily… when I come looking, let's make it easy to find the thing."

Adopted (Mark, 56:35): ask the person "how noisy do you want me to be", and make it valuable before any plane: "if I see you trying to send credentials… I could just tell you."

The session's decision (Rob's, recorded as decided but tentative, waiting on Peterson): defer the findings inbox and the quizzes to the backlog, use email and in-app notifications, keep the promise, record remediation in the audit log.

1. The idea

It is not an inbox, and nothing in it waits to be read. It is the place where the person, when they choose to look, sees what their co-pilot saw: what qcontrol stopped before it happened, what it noticed after, and what HQ followed up on. It also holds the one setting the meeting adopted, how much qcontrol should say. The default keeps the promise on the homepage: nothing changes for the person until something needs them. Every word treats a stopped paste as a save and a gap as something to fix together, never as an offence. The person drives; qcontrol watches the road and speaks up as much as they asked it to; HQ follows up gently and by name.

2. The section's name

Ruled (Mark, 2026-11-13): Safety & Security. Safety leads, the person's word; Security names the company's side and ties the section to the web app's GOVERN + SECURE. The proposal's other "Safety" mentions below read as this name.

Rail: section Safety & Security with two items, Safety & Security (the record and the noise setting) and Settings (each kind, quiet hours, mutes: D9's detail). The rail's own precedent is Help → Help; at 17 characters the name fits the 212 px rail. The tray's "Inbox" item becomes "Safety & Security".

3. How much qcontrol says (the meeting's adopted idea)

The top of the Safety page, one control, asked once at first run as well. It sets D9's per-kind delivery in one move; Settings keeps the per-kind detail for anyone who wants it.

How much should qcontrol tell you?

Below it: "Change this any time. It changes what interrupts you, never what is recorded."

The tray counts only what needs the person (an HQ request to acknowledge, a training due), never what was stopped or noticed. No unread state for the person on Stopped in time or Noticed: nothing here asks to be cleared. This is the answer to "another thing to check". Quietly works with no plane at all, so the section is useful on a standalone machine (Mark, 56:35).

4. Two sources, three groups

Mark's structure, mapped to what the web app already records (c121 D16: a finding's outcome is enforced or observed, stamped at detection, never changed).

Consequences for this cycle's records:

• Noticed comes back. The inventory dropped the observe-mode nudge (row 19) on Rob's concern that agents run wild (5c8785e2). One entry per new finding, not per event, keeps it quiet, and under Quietly it never interrupts.
• enforcement-notice splits by outcome, the field the finding carries, so the message and the finding agree on what happened.
• From HQ in V1 follows the meeting: HQ reaches the person through the channels they already have (email, Slack); in the app, From HQ is the record the person finds when they look, and the place to mark a follow-up done so the finding closes. The training and quiz stay built in c133 and move to the backlog for V1, pending Peterson.

5. The stance in words

The person is never the subject of a bad sentence. The thing that happened is.

Five rules for every entry and help line:

1. Say what stayed safe first. "The key stayed on this machine."
2. Name the policy, the company and the people. The authority is a policy someone at the company wrote, never Qpoint.
3. Give the person the next move, including "nothing to fix" and a way to say "this was work I needed" (ask IT, ask for it to be added).
4. Say what is recorded. Nothing is hidden, so nobody wonders.
5. Qpoint is the co-pilot. It observes and tells, as much as it was asked to; it does not judge.

6. Help text, drafted

All checked with the brand MCP's check-brand-voice (productUI): zero violations, with §3's text.

7. Entries, rewritten

Stopped in time (E1 today: "A paste into ChatGPT was blocked") An AWS key stayed on this machine

1. At 14:02 qcontrol stopped a paste into chat.openai.com because the text held an AWS access key.
2. Your company's policy Secrets in prompts keeps credentials out of AI tools, so the paste never left.
3. Nothing to fix; if you needed this for work, ask IT from here.

Noticed (new; the lab world's Vanta MCP finding) Claude Code connected an MCP server not on Team A's list

1. At 15:41 Claude Code on this machine connected to Vanta MCP, which is not on Team A's approved list.
2. The list tells your company where an agent's tools send data, so HQ sees this as a finding to look at.
3. If you need Vanta MCP, ask for it to be added; a two-minute training explains the list.

Request from HQ (E5, today a "censure"; the meeting's Gene scenario): the words stay HQ's, shown as sent (D6). What changes is the frame: the label, and the send form's voice lint, which suggests the gentler sentence to HQ ("Stop using…" → "Please switch to…") without blocking it (D13).

8. The audit log's softer stance

Mark's ruling in the prompt: prevented moments go in the audit log, in a softer stance than what is dangerous or found after the fact. Rob's model is the audit log in Joey's demos, where flagged and blocked are colour-coded and easy to tell apart. Two axes set the stance, and only the first reaches the person:

• When: prevented (before) is softest; noticed (after) is a finding; HQ's follow-ups are the record of a correction.
• How dangerous: the finding's severity (critical · high · medium · low), for operators only.

Prevented moments are resolved at birth, counted in Reports as the policy working, and kept out of any per-person tally. A noticed finding closes with the line Peterson says an auditor needs: something went wrong, and it was corrected (c133's training.completed, or HQ's follow-up marked done). Whether a company can record prevented moments as counts only, without the person's name, is a plane setting for Tyler (§9, call 6).

9. Calls for Mark

1. The name: Safety (recommended), or Compliance, Security, Guardrails. Ruled 2026-11-13: Safety & Security (§2).
2. The three groups and the rail: Stopped in time · Noticed · From HQ; Safety → Safety, Settings.
3. How much qcontrol says: Quietly · When it matters · Teach me, Quietly the default, asked at first run; the tray counts only what needs the person; no unread state on what was stopped or noticed.
4. From HQ in V1: HQ's own channels (email, Slack) carry the message; the app holds the record and the "done" that closes the finding; the training and quiz to the backlog. This follows f8d58bc9's tentative decision and waits on Peterson.
5. The wire words: censure becomes request; enforcement-notice carries the finding's outcome; overseer and citizen retire from this cycle's docs and its title in favour of HQ and the person.
6. Prevented in the audit log: resolved at birth and never counted against the person (the default); count-only as a company setting is a question for Tyler.
7. "It does not count against you": a promise the plane must keep (Reports, any per-person view). Keep the sentence only if we hold the plane to it.

For the Peterson conversation: calls 4, 6 and 7 are his ground (what an auditor needs, what a security team does with prevented moments, whether a correction can stay this gentle).

10. Reframe under discussion: Findings first (2026-11-13, later)

Mark: "I'm realizing there is already the notion of findings, should we start by replicating that as a way to note and communicate violations to policy? … this is probably a higher level question questioning the purpose of the cycle and how it should be approached … you'll want to check design, our latest phase of work, it hasn't made it further than that yet."

What design's latest Findings is (phase 4: c114 → c118 → c121 → c133, lab only; qdash still shows the older Security Findings at the control grain, and the native app says "This app has no policy engine yet"):

• A finding is immutable: policy, Policy Config version, outcome Enforced or Observed, stamped at detection, never relabelled (c121 D16), subject (person and device), resource, session, severity at generation, evidence.
• Everything that changes is an append-only event: detect, resolve with a reason, ignore with an end date, reopen, re-evaluate (now enforced, policy changed, allowed by an exception), and c133's training-completed (proof; the status does not move, D9).
• S2 Findings (/pages/phase4/findings, composed at mock/findings-design): grouped by policy, Grouped ⇄ Individual, one filter bar (Outcome · Severity · Status · Framework), Observed hidden by default (c121 D3).
• S1 Finding detail (/pages/phase4/finding-detail, mock/finding-detail): What happened, Why it violates, the lifecycle rows, related findings, Respond (Resolve, Ignore, Create exception); c133's training row and Corrections block.

It already holds the prompt's structure: before and after are the outcome; the Qplane's remediation is events on the finding; "something went wrong, and it was corrected" is its lifecycle rows. c137's message types collapse into the finding (the enforcement notice is the finding) or into events on it (a training assignment, HQ's follow-up).

Where it disagrees with today's prompt: an Enforced finding is born Open and sits in the operator's default view, while Observed is hidden by default (D3). The prompt makes the prevented moment the softest and the one that happened the more serious. One of the two has to give.

What the person's slice needs that the model lacks: the person's own verbs as events (ask IT, ask for access, a follow-up done; c133's event-shape.md is the precedent for an endpoint-written event), findings derived on a machine with no plane (the native app has the sensor's raw policy events but no policy engine), and the person's words beside the operator's ("Why it violates" included).

Ruled the same day (Mark): findings bubble up to a company plane when connected and trainings bubble down, "so they speak a common tongue"; close c137 into a new cycle (c147, Findings, a Common Tongue, Stage 1); prevented is softest (revisits c121 D3); every finding bubbles up, prevented ones softer; Findings replaces qnative c4's inbox and keeps its plumbing. The group names (call 2) wait for the copied Findings view; calls 3 (the noise control), 5, 6 and 7 carry into c147. Everything below this line is superseded by c147.

After the rulings: the lab mocks first (/pages/phase4/messaging-*), then qnative (the rail, the tray, the Safety page's control and groups, the kind words in messaging.rs, the ten examples' copy and the drift test that reads bones.md), then this cycle's inventory, bones and ports, and c0's role words.