Feedback on the intents, from building v1 in the lab

For Mark Peterson, from c121 (2026-10-23). We built your v1 scope into the phase-4 lab (/pages/phase4/mock/* on the design site) and ruled a few things the intents leave open or answer differently. Each item below cites the intent file and line at qpoint-io/intents ce9ce2b (PR #4). Mark Parson decides whether this goes to the repo as a PR comment.

Where we went further than the intents

1. Reasons are required on loosen and revoke (c121 D1). enforce_configure-policies-and-exceptions.md:34 asks for a strong prompt that never blocks the save, and :57 leaves mandatory reasons open. In the lab, Save stays disabled until a loosening edit has a reason, whether it's a policy's mode or an exception, and every revoke takes one too. Tightening keeps the reason optional. Our view is that loosening is where an auditor or the next admin needs the why, and a prompt that can be dismissed fails exactly when it matters. It costs one sentence per loosening. If you'd rather keep the nonblocking minimum, :57 is the place to settle it either way.

2. Local staging in front of the shared draft (c121 D4). enforce_publish-policy-configuration.md:27 saves each edit straight into the one shared draft. The lab keeps a local layer in front of it: edits stage in your browser across pages, and "Save to draft" writes them into the shared draft with you as the author of each line. Publish still takes the whole draft (:28, :42, :43 all hold). The reason is noise. Half-finished edits, like an exception you're still sizing up against its impact preview, don't belong in the list every other admin reads. It's a small layer and doesn't change the publication model.

Where the intents leave a question open

3. Equal-specificity ties: the stricter mode wins (c121 D15). enforce_configure-policies-and-exceptions.md:55 asks what decides for a person in two teams whose exceptions disagree. The lab keeps c114 D9: the stricter mode wins. Alex, in Engineering (Observe on the MCP policy) and Finance (Enforce), is enforced, and the tie shows as a note on both exceptions and on the team page. It's deterministic, it fails safe, and it needs no primary-team concept.

4. A policy's Until reverts to the mode it replaced (c121 D6). enforce_configure-policies-and-exceptions.md:56 asks what a time-bound policy default reverts to. The lab's answer: the mode it replaced, read as "Observe until Nov 15, then Enforce". It matches what :50 already says for exceptions, where the remaining applicable exception or the default applies when one lapses. The versioning half of :56, how a lapse propagates to offline endpoints, we haven't drawn.

5. Pending edits on rollback (enforce_publish-policy-configuration.md:58). The draft stays and is re-based on the new live version. Any line live already has after the move is marked redundant, and it doesn't publish. Nothing is discarded silently, and the admin can remove the redundant lines or leave them.

6. Concurrent edits to the same setting (enforce_publish-policy-configuration.md:57), and one exception per context (c121 D17). In the lab the draft holds one line per setting, and the last value wins. The line keeps who it replaced, and the expanded row names them. That rule needs a definition of "setting" for exceptions, so we made one: one exception per policy and context. Adding an exception where the context already has one edits it, and history keeps the old value. The intents don't say this anywhere. A guardrail in enforce_configure-policies-and-exceptions.md would make it explicit.

Where we agree, with one addition

7. Outcome at detection, and "now enforced" (c121 D16). This agrees with enforce_resolve-a-finding.md:21 and enforce_re-evaluate-findings-after-policy-change.md:31. A finding's outcome, Enforced or Observed, is stamped at detection and never changes. Enforced means the activity was actually blocked. The addition is the transition :31 describes only by what it isn't. When enforcement is later confirmed on the person's endpoint, an open Observed finding resolves by re-evaluation with the cause "now enforced on this endpoint". It's Resolved, it still reads Observed, and it links to the config version that did it. A name for that resolution in the re-evaluate intent would keep surfaces from inventing their own.

Housekeeping

8. Four intents that PR #4 supersedes are still in the repo. They now contradict it:

• enforce_manage-policy-groups.md: policy groups are no longer managed objects (enforce_configure-policies-and-exceptions.md:38).
• enforce_manually-resolve-with-ignore.md: finding-level Ignore with a required duration. Resolve now records a decision (enforce_resolve-a-finding.md).
• enforce_configure-policy-scope.md: explicit scope assignment by dimension. Exceptions are now the only way to vary a policy (:31).
• enforce_enable-disable-policy-enforcement.md: enforcement per scope. Mode now lives on the policy (:28).

Deleting them, or marking them superseded with a pointer, would stop readers and agents from following the older model.

Also from v1, for your next pass

• The adoption lifecycle. Your observation from 2026-10-23 is now a lab switch (?stage=adoption) and a docs section on /pages/phase4/governance-model. enforce_configure-policies-and-exceptions.md:33 ("Observe organization-wide with Enforce for a test team") covers the first stage. The second stage, Enforce broadly with Observe or Off where needed, isn't written down in the intents yet.
• Expiry stays optional (c121 D7), as :35 says. When an edit loosens, a hint under Until reads "No end date: this stays open until someone revokes it". It never blocks.