Clarity Spec — Feedback for Mockups
Date: 2026-02-27 Spec reviewed: Clarity: so what? / what do I do now? Purpose: Technical feedback before Sergey starts mockups in Stitch.
Overall Verdict: Good to Build — With 4 Notes
The three-step flow, the execution-determined framing, and the CISO/Analyst layer separation are all sound and implementable. Sergey can start mockups. These notes are things to be aware of during design, not blockers.
What's Good — Build As-Is
The three-step mental model works. Overview → Cluster Exposure Brief → Authority Paths → Path Evidence maps cleanly to existing screens. No new top-level pages needed.
"Functional cluster name" over attribute labels is right. "Orphaned + Sensitive" as a primary label forces the CISO to decode two dimensions simultaneously. A functional name like "Unowned HR Automation" is immediately comprehensible.
Section D remediation bullets are the right scope. 1-3 advisory bullets, no enforcement logic. This is deliverable now.
"View Authority Paths (N)" button is smart UX. Hiding the table behind a click prevents cognitive overload on the Exposure Brief page. Good decision.
Observed vs. Potential separation in Path Detail (Step 3) is minimal work. The current page already shows authority. Adding a collapsed "Standing Authority (Not Exercised)" panel is a minor UI change.
4 Notes for Mockup Design
1. The verdict sentence needs "Endpoint Type" — but it's available
The template:
<N> autonomous paths exercised <Domain>-scoped authority and invoked <Endpoint Type> <X> times in the last 30 days.
"Endpoint Type" is not a current entity, but it maps to data we already collect:
- Foundry:
connection_type(e.g., AzureOpenAI, AzureBlob) +egress_category(llm, cloud, external) - Entra:
resource_display_namefrom sign-in logs (e.g., "Microsoft Graph") - ServiceNow:
connection_subtype(rest_message, soap_message, http_connection)
For mockups: Use concrete examples like "invoked LLM API endpoints" or "invoked Microsoft Graph" rather than a generic placeholder. This will look right in the final product.
Full analysis: Endpoint Type Feasibility
2. Evidence grades should be visible — the spec doesn't mention them
The spec frames everything as "observed authority" but doesn't address the reality that not all paths have the same quality of evidence. Per the Execution Evidence Feasibility Study, we recommend Evidence-Graded Authority Paths:
- Grade A — Confirmed execution (deterministic proof)
- Grade B — Inferred execution (temporal correlation, partial evidence)
- Grade C — Standing authority (configured but no proof of exercise)
Why this matters for mockups:
- The Overview (Step 1) risk badge should reflect evidence grade, not just governance condition.
- The Exposure Brief (Step 2) Section B ("Am I Exposed?") should show the evidence grade distribution — e.g., "14 paths confirmed, 38 inferred, 90 unconfirmed."
- The Authority Path table should have a visible grade column.
Suggestion for Sergey: Add a small evidence grade indicator (A/B/C or a colored dot) next to path counts wherever they appear. This is SV0's differentiator — no competitor grades evidence quality.
3. Section C governance items have mixed availability
The spec lists four governance conditions:
| Condition | Status | Notes |
|---|---|---|
| Orphaned? | Available now | ownership_status already evaluated |
| Long-lived? | Available now | Token/credential age tracked via created_at |
| Drift? | Not built yet | Requires temporal diff engine — DRAFT feature |
| Identity reuse? | Not built yet | Requires cross-path identity correlation — not in current evaluator |
For mockups: Design all four in the layout (they're all valid concepts), but Sergey should know that Drift and Identity Reuse will show "Not yet analyzed" or similar placeholder states in the near-term build. Orphaned and Long-lived are ready to populate.
4. The "Standing Authority (Not Exercised)" panel in Step 3 needs path materializer awareness
The spec says: "Add collapsed panel: Additional Standing Authority (Not Exercised)"
Today the path materializer (authority-path-materializer.ts) is structural-only — it traverses the permission graph (HAS_ROLE → GRANTS → APPLIES_TO) without distinguishing observed from potential. To split paths into "exercised" and "not exercised" panels, we need the materializer to join against execution evidence.
For mockups: Design the collapsed panel as shown. The backend work to split observed vs. standing is scoped at ~1-2 Claude Code sessions and is already on the roadmap.
Summary Table
| Spec Element | Build Status | Mockup Guidance |
|---|---|---|
| Three-step flow | Ready | Build as-is |
| Functional cluster names | Ready | Build as-is |
| Verdict sentence | Ready (endpoint type composable) | Use concrete examples ("LLM API", "Microsoft Graph") |
| Risk badge | Ready, but needs evidence grade | Add evidence grade indicator |
| Section A — What Happened | Ready | Build as-is |
| Section B — Am I Exposed? | Ready, needs grade distribution | Add grade breakdown (14 confirmed / 38 inferred / 90 standing) |
| Section C — Governance | 2 of 4 conditions ready | Design all 4; Drift + Identity Reuse show placeholder |
| Section D — Remediation | Ready | Build as-is |
| Authority Path table | Ready | Add evidence grade column |
| Standing Authority panel | Backend ~1-2 sessions | Design the collapsed panel as-is |
| Observed vs Potential separation | Conceptually ready | Build as-is |
Bottom line: The spec is well-structured and implementable. The biggest design-level addition is making evidence grades visible — this is what differentiates SV0 from every competitor that shows paths flat without evidence quality.