c12 T0 — First micro problems, hand-drafted (for review)

Written 2026-09-21 from the six phase-2 calls (data/processed/), briefs/cam-dashboard-directives.md, bob-wire c21.inventory/design-brief.md, design c55 page-persona-analysis.md, design c92 detail-pages-guide.md, and the qdash page tree. No code. Purpose: test the §2A shape in plan.md against real material before T1 builds it. Read §5 first if short on time — it is what T0 changes in the plan.

How to read a card. statement is the pain in the user's frame (canonical). question is what the user asks of the product (the promotion test). Standing is hand-computed under the plan's rule: observed = ≥1 first-hand observation from a non-internal source; recurring = ≥2 distinct companies first-hand. Companies with a first-hand external voice in the corpus: Tiled (Phil Chen, prospect), Zscaler (Sam Curry, prospect), Moto (Mark Peterson / "Mark M", ciso-advisory — first-hand about his own org, ceiling reaction-based). Internal and relayed evidence is listed and labelled; it never counts toward standing. Cam (Cisco, phase-1 archive) is cited as legacy, pending Q6 and not counted.

Call short ids: 1668d68e Tiled demo 08-25 · d232f12c Zscaler/AMZ demo 08-20 · 2100ac03 Mark M advisor-input 08-20 · 38075ead Mark P roadmap 08-31 · 09ecfede Mark P roadmap 09-03 · 6fe4a00b AMZ internal working session 09-02. Observation refs are <call>#<index> as printed by the extraction.

1. Promoted candidates (15)

P1 · unknown-agent-fleet — recurring

• statement: I have no idea what AI tools, agents, and models my people are actually running.
• question: Which agents, harnesses, and models are running across my fleet, including the ones I didn't know about, and how many of them am I actually monitoring versus just detecting?
• personas: engineering leader wearing security (P2/P3), founder/CTO (P1), security lead (P4)
• situation: Post "all-AI" rollout. MDM shows installs, not behaviour. Discovered by accident that people use tools the company moved away from.
• useCaseIds: agent-inventory
• surfaces: inventory, fleet-overview
• evidence:

• standing: recurring (Tiled first-hand, Moto first-hand reaction). Strongest problem in the corpus; also the one AMZ named as the free-tier "aha."
• status now: in-design (bob-wire c21 inventory; design c90/c92 Inventory listings)

P2 · personal-vs-enterprise-accounts — recurring

• statement: People use personal AI accounts on company machines, so my IP leaves through accounts I don't control and can't audit.
• question: Which users are on a personal account rather than our enterprise account, per provider, and can I flag or block it?
• personas: security lead (P3/P4), CISO (P7), GRC (P9)
• situation: Company standardised on one enterprise provider; found people still on personal ChatGPT; dual personal + enterprise licences of the same tool are the hard case.
• useCaseIds: agent-inventory, inline-enforcement (variant); displaces gateway-bypass-detection (see §4)
• surfaces: inventory, users-devices, user-detail, policy-enforcement
• evidence:

• standing: recurring (Tiled, Moto). Volunteered unprompted by two sources and observed as live behaviour at Tiled.
• status now: in-design (c21 brief §5 "the standout use case"; c21 decision 6 accounts surface in Inventory)

P3 · sensor-coverage-gap — observed (recurring-adjacent)

• statement: I can't tell which people and machines have the sensor installed, so I don't know what I'm not seeing, and I can't act on the gaps.
• question: Who has the sensor installed, who doesn't, against a definitive list of my people and workstations, and what do I do about the ones who don't?
• personas: IT / endpoint admin (P5), security lead (P3/P4)
• situation: Rolling Qpoint out; coverage needs a denominator from identity management and MDM; a gap should be one click from remediation (deep-link to Jamf/Intune).
• useCaseIds: agent-inventory
• surfaces: users-devices, device-detail, fleet-overview, install-onboarding
• evidence:

• standing: observed (Moto). Sam's fleet question is adjacent, not the same ask; recurring once a second org states the coverage problem.
• status now: in-design (c21 brief §4 "#1 story"; design c91 DataMachine "User Coverage" / "Devices Sensored" presets; c92 projected badges for the unserved denominator)

P4 · unexplained-ai-spend — recurring

• statement: AI spend varies wildly by person and I can't explain it, budget it, or tie it to output.
• question: Who is spending what on AI, on which models and accounts, how does it trend, and can I attribute it by team and department?
• personas: engineering leader (P2/P6), FinOps (P11), CFO (relayed through Mark P)
• situation: Overruns handled by "add another thousand to the limit"; top spenders show no visible productivity; the CFO attributes cost by department and wants AI spend rationalised the same way.
• useCaseIds: finops-context-waste (expands beyond idle-MCP framing), agent-inventory
• surfaces: cost, users-devices, user-detail, teams
• evidence:

• standing: recurring (Tiled, Moto).
• status now: partly shipped (qdash cost.vue exists; c55 notes showback is live, chargeback/budget alerts are not); per-user and per-department attribution in design (c92 people pages, listing bands)

P5 · per-user-ai-summary — observed

• statement: I can see raw activity but I can't tell what a given person is actually doing with AI.
• question: For this user, which tools and models do they use, when, at what cost, and what are they doing with them, in plain language?
• personas: engineering manager (P6), security lead (P3)
• situation: Investigating an anomalous spender or an unfamiliar tool; a log is not an answer.
• useCaseIds: agent-inventory (expands)
• surfaces: user-detail, session-detail
• evidence:

• standing: observed (Tiled).
• status now: in-design (design user-v3 mock; c92 User Details port; AI summary is a ProjectedBadge in qdash)

P6 · unsanctioned-external-services — observed

• statement: Employees sign up for free third-party AI and hosting services, and free accounts aren't compliant.
• question: Which external services are my users and agents sending data to, which are unsanctioned, and which are on free tiers?
• personas: security / compliance lead (P3/P9)
• situation: Found Netlify and Lovable free accounts in use instead of the sanctioned AWS path; compliance exposure the leadership hasn't reckoned with.
• useCaseIds: agent-inventory; egress angle has no named hypothesis (see §4)
• surfaces: inventory (external services / egress), findings, data-protection
• evidence:

• standing: observed (Tiled).
• status now: partly shipped (c55: shadow-AI discovery chips on Inventory; egress in Surface under ?agent= only)

P7 · findings-resolution-workflow — observed

• statement: A finding shows up and there's no way to clear it properly, so it either gets ignored or becomes a tracking problem outside the tool.
• question: For this finding, what can I do about it (acknowledge, except, ticket, enforce), who owns it, is it inside its SLA, are its duplicates grouped, and what is the audit record?
• personas: security engineer (P3), GRC (P9)
• situation: Daily triage; SLA clocks start at discovery, not triage; the same underlying issue recurs across many resources.
• useCaseIds: inline-enforcement, mcp-governance
• surfaces: findings, alerts
• evidence:

• standing: observed (Moto). Sam's assent is to the framing, not a stated need; recurring needs one more org with a triage pain.
• status now: partly shipped (c55: Findings is the one page with a write-path triage loop; SLA, grouping, delivery are not built)

P8 · prove-posture-over-time — recurring

• statement: A current-state score doesn't tell me whether we're moving the needle, and I can't hand my board or my auditor a report.
• question: How has our posture changed week over week, and can I export a board summary, a per-framework compliance report, an SLA report, and an inventory report, machine-readable for the GRC platform and human-readable for the auditor?
• personas: head of security / CISO (P4/P7), GRC (P9)
• situation: Quarterly reporting upward; audit evidence collection; the fleet overview as the landing page that summarises four reports.
• useCaseIds: none fits cleanly (mcp-governance touches framework mapping) → missing hypothesis: governance evidence & reporting (§4)
• surfaces: fleet-overview, posture, compliance, reports-exports
• evidence:

• standing: recurring (Moto, Tiled; Zscaler adjacent).
• status now: partly shipped (c55: Compliance evidence export live; posture trend exists on Overview; scheduled snapshots and PDF not built); design c78 fleet-overview-reports consumed the Cam brief for this

P9 · fleet-scale-compliance-state — observed

• statement: At thousands of endpoints I can't see which are in policy and which have drifted, so I can't give anyone proof.
• question: Of my N endpoints, how many are compliant with policy right now, which are not, what drifted since last week, and can I see that as evidence rather than per-device configuration?
• personas: CISO (P7), security engineer (P3), IT admin (P5)
• situation: Enterprise scale (9,000 users, 1,400 SaaS services in Sam's case); the workstation ↔ identity ↔ agent relationships are the accountability backbone.
• useCaseIds: agent-inventory (expands: drift)
• surfaces: fleet-overview, posture, users-devices
• evidence:

• standing: observed (Zscaler; Moto adjacent). Relation to P3: P3 is is the sensor there, P9 is is the endpoint in policy. Keep separate; the same page family answers both.
• status now: candidate in product (analysis.json recommendation 3 names it as the hardening objection)

P10 · safe-to-enforce — observed (weak)

• statement: I won't flip a policy from observe to enforce without knowing what it would break, and I don't trust a tool that asks me to.
• question: If I enforce this policy on this population, what would have been blocked over the last N days, for whom, and is it safe to turn on?
• personas: security engineer (P3), head of security (P4)
• situation: Sequencing adoption: observe → govern → enforce; the first enforcement is a trust event.
• useCaseIds: inline-enforcement
• surfaces: policy-enforcement, controls
• evidence:

• standing: observed (Moto states the sequencing pain; the specific dry-run ask is internal). Phil's line is challenge evidence: this is not the problem to lead with.
• status now: partly shipped (c55: Policy blast-radius dry run exists; enforcement itself projected)

P11 · web-ai-usage-blindspot — observed

• statement: The sensor sees local agents, but my business users do their AI work in the browser, and I can't see that.
• question: Is AI usage through browser chat interfaces (Claude.ai, ChatGPT web) covered, for whom, and how does it show up beside local agents?
• personas: CISO / IT (P4/P5), business-unit leadership
• situation: Finance and other non-developer teams rely on web apps; developers run local agents.
• useCaseIds: agent-inventory (expands; also challenges the endpoint-agent scope)
• surfaces: inventory, users-devices
• evidence:

• standing: observed (Moto). Single source; worth watching because it is a scope question, not a feature.
• status now: candidate (parked idea)

P12 · endpoint-coexistence-proof — observed

• statement: Another agent on the endpoint might collide with my EDR and DLP, and I can't accept "no impact" without numbers.
• question: Will this coexist with CrowdStrike / SentinelOne / DLP on the same box, how does it hook the OS, and what are the measured resource, latency, and telemetry costs?
• personas: enterprise CISO (P7), security engineer (P3), SOC (P8)
• situation: Security review before any pilot at scale; the answer is benchmarks and architecture docs, not a screen.
• useCaseIds: none (objection-shaped; see §4)
• surfaces: docs-onboarding, install-onboarding, performance
• evidence:

• standing: observed (Zscaler). An example of a problem whose answer is documentation, which is why docs-onboarding belongs in the surface vocabulary.
• status now: candidate

P13 · agent-identity-scoped-access — observed

• statement: A SaaS component used a person's identity to pull unrelated data from Workday; scoped access for non-human identity is fundamentally broken and I can't see it happen.
• question: Which agents and components act under a user's identity, what did they access beyond that user's scope, and can I prove the policy held?
• personas: enterprise CISO (P7), IAM architect (P10), SOC (P8)
• situation: Post-incident; UEBA, authenticity chains, verifiable policy for non-human identities.
• useCaseIds: sensitive-file-events (validates, reaction-based)
• surfaces: agent-detail, findings, identity, session-detail
• evidence:

• standing: observed (Zscaler).
• status now: partly shipped (c55: Identity page "observed, not verified"; agent detail forensics)

P14 · session-transcript-governance — observed (weak)

• statement: Storing agent session transcripts is the most powerful thing you show me and the thing that scares me most; I need to hold the keys.
• question: Who can see session transcripts, where are they stored, can I bring my own key, is retention immutable, and is access role-gated and audited?
• personas: CISO (P7), GRC (P9)
• situation: Evaluating whether session-level visibility is acceptable in production; the demo moment is also the privacy objection.
• useCaseIds: none → missing hypothesis: session-record governance (§4)
• surfaces: session-detail, settings-governance
• evidence:

• standing: observed (Moto, single first-hand item; the customer-facing claim is relayed).
• status now: decided (deferred to governance phase; direction set)

P15 · unreviewed-mcp-surface — observed

• statement: MCP servers and tools load into my agents' context without anyone having reviewed or approved them.
• question: Which MCP servers and tools are configured versus actually connected, which have never been approved, and has any agent tried to call an unapproved one?
• personas: security engineer (P3), platform lead
• situation: Developer machines accumulate MCP config; MDM cannot see it; approval has no home.
• useCaseIds: mcp-governance
• surfaces: inventory (MCP servers, tools listings/detail), controls
• evidence:

• standing: observed (Moto, reaction only). Under Q6 this becomes the best-evidenced problem in the registry; without Q6 it is the thinnest of the promoted set. This is the clearest argument for the legacy reconnect.
• status now: partly shipped (c92 MCP Server / Tool detail pages; configured / observed / both served)

2. Candidates not promoted (the test working)

• who-owns-this — Sam Curry: "Who's gonna run it on the backend? Is it my team? Is it the CIO? Is this actually a CIO purchase?" (d232f12c#4, first-hand). Real, recurring in enterprise, and not a question the product can answer. It is a positioning and packaging problem. Stays a market observation (risk/organizational); belongs in a position brief, not the registry.
• gamified-rollout — Mark P's parked idea (38075ead). A solution sketch, not a problem; folds into P3 as an affordance idea.
• auto-docs-from-transcripts — Mark P's parked idea. Internal tooling, not a user problem.
• c2-intent-detection — AMZ (6fe4a00b#10,#11, internal, tabled). Internal hypothesis with no external voice; register only if a first-hand source raises it.
• agent-fatigue / "not another agent" — expected objection; no first-hand instance in phase 2 yet. Watch.

3. Seed vocabularies that fell out

PRODUCT_SURFACES (page families, coarse on purpose; source: qdash pages/ + design qcontrol/ mocks + c55 nav sections, 2026-09-21)

Kept at page-family grain so c92-style renames (/teams → /teams-users-devices) don't churn it.

personas.json seed (c55 P1–P11, plus one gap)

c55's eleven: P1 founder/CTO · P2 lead engineer / de-facto IT · P3 security engineer (AI-governance owner by default) · P4 head of security / CISO-lite · P5 IT / endpoint admin · P6 engineering manager / AI-enablement lead · P7 CISO / VP Security · P8 SOC analyst · P9 GRC / compliance · P10 IAM architect · P11 FinOps analyst.

Gap found in T0: Mark M's third persona (2100ac03#6) is the end user / engineer who "doesn't care about any of this… all he cares is that he's playing within the bounds of what Moto is comfortable with." c55 has no end-user persona, and P11 (web usage, business-unit users) and the tray-app "aha" both need one. Proposed P12 end user / developer. Also: Phil Chen is P2+P3 in one person at a 20-person company — the registry should allow a person to map to two personas.

4. Missing hypotheses (problems with no clean use case)

The plan predicted an unlinked problem would be a signal. Three appeared:

1. Governance evidence & reporting (P8, partly P9): time-series posture, four-report suite, machine + human readable, scheduled snapshots. mcp-governance touches framework mapping but the hypothesis is about proof, not control. Recurring evidence today. Candidate for use-cases.json.
2. Session-record governance (P14): BYOK, WORM, role-gated access to transcripts. A precondition for selling session-level visibility at all. Single source today.
3. Endpoint coexistence proof (P12): not a product hypothesis but a trust precondition; its "surface" is documentation. Arguably belongs in positioning, but it is a real question buyers ask of the product, so it stays as a problem with docs-onboarding as its surface.

And one registry entry the problems keep displacing: gateway-bypass-detection has no problem under it; P2 (personal-vs-enterprise-accounts) is what the market actually says. Matches analysis.json recommendation 5. Proposal: rewrite the use case around accounts and keep gateway bypass as a note.

5. What T0 changes in the plan (§2 amendments)

1. problemId must be taggable on session items too. The best evidence for P3, P10, P14 lives in session.decisions[] / ideas[], not observations. Add problemId? to session decisions and ideas; standing counts them by their perspective.
2. Advisor first-hand counts toward standing, labelled. The rule as written ("first-hand from a non-internal source") already includes Mark P's own-org statements. T0 confirms this is right: a problem is about having the problem, not about validating our solution, so the c11 evidence ceiling (which caps use-case evidence at reaction-based for advisors) does not apply to problem standing. The site must still show source type beside the count so "recurring (Tiled, Moto-advisory)" reads honestly. Decision to confirm with Mark.
3. Challenge evidence is needed from day one. Phil on control-center-as-upsell (P10) and, from c21, Mark P on removing risk posturing. problemDirection: challenges stays in the design; the site shows it beside standing.
4. Surfaces must include non-screen answers. docs-onboarding, install-onboarding, settings-governance, reports-exports are surfaces because P12 / P3 / P14 / P8 are answered there. Coarse page families, as listed in §3.
5. Status has an honest "partly shipped." Many problems are partly answered by qdash today (c55 inventory of what is live vs projected). Add partial between in-design and shipped, or record status per surface. Recommend: keep the single status and let notes carry the partial detail, to stay simple.
6. A problem's origin is often a demo reaction. P3's sharpest line came from Mark P reacting to a mock ("15 of 18 people covered…"). This is exactly the artifactRef case: the Sep 3 call showed the Teams/Users and Device/Agent prototypes. Q10 (shown-artifacts at triage) earns its keep.
7. Personas: add P12 end user / developer; allow two personas per person.
8. Registry additions to propose to use-cases.json: governance evidence & reporting; session-record governance; rewrite gateway-bypass-detection as account-identity control. Not done in T0; a T1 decision.

6. Review questions for Mark

• Do the fifteen promoted problems read as addressable and solvable by our product? Which would you demote, merge (P3/P9? P2/P6?), or reword?
• §5.2: should advisor first-hand statements count toward "recurring" (recommended, labelled), or only prospects and build partners?
• §4: register the two missing hypotheses now, and rewrite gateway-bypass-detection around accounts?
• Q6 (legacy Cam reconnect) is now concrete: P15 and P1 are the problems it would strengthen. Yes or no?
• Are PRODUCT_SURFACES at the right grain, and is the persona list (with P12 added) the shared truth you want here?