Thread `posture-score`: plan (2026-11-04)

From posture-score-prompt.md. Everything here stays in the lab: the shared world, part/FrameworkDetail.vue, no layer release and no qdash port until the picks are made.

Built 2026-11-04 through step 3, plus the Compliance listing; see CYCLE.md Key Changes. Mark's changes to this plan when he said go:

• Q3: only the column's name changes, and its content stays. (That is what got built.)
• Items Qpoint can't address leave the table and stay under Gaps, replacing trap 4's grey row.
• The Compliance listing moved up from "where else" and shows both metrics. Score also shows on untracked frameworks, as Violations did, rather than blank.
• The window counts findings detected in the last 30 days plus any older one still open, since hiding an open finding is worse than a slightly uneven base.

The two metrics

Each one covers the other's blind spot, so they should always appear together. A policy that is Off raises no findings, so its Score looks spotless while its Posture is red.

Decisions to make first

These are the places the request meets an earlier ruling or leaves room for two readings. Each has a default, and the plan runs on the defaults unless Mark changes them.

Compliance Posture: the model

Formula (per policy, then per row):

• For each person a policy can reach, take the mode they actually get, using applicability() as Teams does: Enforce = 1, Observe = 0.25, Off = 0.
• Average that across people. Loosening exceptions lower it and tightening pilots raise it, with no special case.
• Each live advanced exception (the allow of one resource) takes a flat 10 points off, because the lab can't say how much activity one allow covers.
• A row is the plain average of its mapped policies. Its hover lists them: "3 enforced, 1 observed, Platform team at Observe by exception".

Colours (Mark's rule, with the thresholds made exact): green at exactly 100%, orange below that, red under 25%. An all-Observe row lands exactly at 25%, so it is orange, and red always means part of the row is Off. The number always sits beside the bar, so colour never carries it alone.

Dry run on the lab's story world (the end of runStory(RULED); 19 policies, 14 named subjects; advanced exceptions not yet counted):

The bars vary, so the rule does tell rows apart. The run turned up four traps:

1. Observe-only policies can never reach 100%. 8 of the 19 policies can't enforce (enforceable: false). Default: these count as full when they are observing, because that is all they can do. Without this, no row mapped to one can ever go green.
2. Pills and bars will disagree. standing() reports the strongest setting anywhere, so P-DATA-BOUNDARY and P-FILES (mode Off, one enforcing exception) read "enforced" while reaching 14% of people. P-MCP reads "enforced" at 43%. Default: the pill shows the policy's own mode, and the bar and its hover carry the exceptions.
3. Procedural rows can go green. A row can be fully configured and still need process Qpoint doesn't provide (one each in OWASP LLM and NIST). Default: it stays green, since Posture measures configuration, but the note moves from the removed Coverage cell to under the bar ("needs process too"). "Mapping never implies Qpoint alone satisfies" has to survive somewhere.
4. No policy isn't 0%. Rows with no mapping show a grey "No Qpoint policy", not a red bar, and they stay out of rollups. The Gaps section stays. A row whose policies are all Off is the red one.

Left out for now: enforcement reach (rollout.reach, an Enforce that has reached 8 of 10 devices). The data exists, and it's the next honest refinement if the bar feels too generous.

Non-policy evidence is also unaddressed: the redline's "Evidenced" state and the brief's "strongest evidence shouldn't read as a gap" both still have no home. Peterson's intents may settle it.

Compliance Score: the options

The missing piece is the denominator. The lab world has no count of what was checked: only session summaries, plus daily sessions and tokens in reports-c128.ts. In qdash, rule signals look aggregated ("one row per tool + decision group", "one row per host"), so rule evaluations don't equal calls. session.tool_calls and provider requests do exist. I read the signal comments and API types, not the pipeline, so a real count of checks needs confirming with the backend. In the lab the number is seeded per policy per day, and marked with the existing projected ring.

What every option has to get right:

• Off shows "—", never clean. Nothing was looking.
• Rollups count distinct findings. One policy maps to many rows: OWASP LLM's rows sum to 8 open findings against 6 distinct, NIST's to 23 against 6.
• Same window on both sides. "Open now" over "checks in 30 days" mixes two times. Default: findings detected in the window, with how many are still open.
• Blocked isn't failed. D16's Enforced findings mean the policy worked. Default: they count, and the hover splits blocked from observed. Mark can rule otherwise.

Options, built side by side behind ?v.score= (the mechanism Teams uses for ?v.posture=). The sample figures are illustrative.

Recommendation going in: A, with C's base if the backend can't give checks. D is worth seeing so it can be ruled out by looking. E is the likely answer for Teams rather than this page.

Build

1. Model. Add postureOf() and scoreOf() beside coverage() in governance-fixture.ts, plus seeded check counts. Add scripts/c123-metrics-check.mts covering the four traps, the thresholds and distinct rollups.
2. Framework detail (part/FrameworkDetail.vue; the record page shares it):
   • Remove the Coverage machine and column, and the row above the table (Q2).
   • Columns: Name · Enforcement Posture · Compliance Posture · Compliance Score, with Findings folded into Score.
   • Add the posture bar: lab-local, composed from DataSegmentBar. The layer's PolicyCompletenessCell is grape and hard-codes "Controls", so it doesn't fit.
   • Make Posture and Score sortable.
   • Rewrite "What coverage means" as "How these are worked out". coverage() stays, for Gaps.
3. Score options behind ?v.score=, A–F.
4. Review with Mark: pick a Score, confirm the formula and the Q1 wording.
5. Apply elsewhere from the picks below, one surface at a time.
6. Record: run scripts/tours-walk.mjs (the OWASP Agentic tour stops on the Compliance row), add captures and the CYCLE.md Key Changes entry. Update explain in the guide if it defines coverage. Extract the bar to the layer only once it has settled. Deploy when asked.

Checked in the browser on the running :3000, in light and dark, at 768–1600px. The tree is shared with other sessions, so check for foreign staged paths before any commit.

Where else these should apply

From walking the lab's pages. Ranked by how much each one gains.

The word "posture"

It already means three things, and this adds a fourth:

• qdash /posture and its fleet score are about launch settings on harnesses.
• The c128 Posture report opens on that same score (78, with "what lowers the score"), so a report would show Posture score, Compliance Posture and Compliance Score together.
• Teams' posture is modes by team, the same idea as the new metric.

Compliance Posture is clear on framework pages. The report is where it collides, so I'd take that up at step 5 and rename the fleet one ("Fleet score" or similar) rather than the new one. X11 already lists /posture as part of the Frankenstein.