c12 — Analysis of the Existing Lens

Written 2026-09-21 from a re-read of ../design/brand/design_methodology.md, design_philosophy.md, design_methodology_analysis.md, pipeline.md, component_philosophy.md, design CLAUDE.md; and of this repo's goals.md, schemas/vocabularies.ts, pipeline/prompts/extract-call.md, briefs/, data/use-cases.json, data/analysis.json, the c8/c11 cycle records, bob-wire's brief-writer + c21.inventory/design-brief.md, and design's c55 / c62 / c91 / c92 records. Companion to plan.md.

1. The founding frame, restated

The design docs give the target its name. Design addresses wicked problems; forming the problem is the problem; a shapeless macro problem becomes addressable micro problems. Qpoint's product does this to data governance (flows → classified, addressable flows). This repo is asked to do the same thing to Qpoint's own problem space: take the wicked "what should the product be" and give it tangible form as micro problems — bounded, named, evidenced problems that a story, a priority call, a brief, or a page can be built on.

Two other methodology points matter for the shape of the work:

• Archaeology, not invention. The micro problems already exist in the corpus — as user questions, decisions, quotes, session ideas. The job is to surface them, not fabricate them. This argues for extraction that proposes candidates and a human who forms the registry, exactly the pattern use-cases.json already uses.
• Assemblage. The pieces are here: perspective tagging, evidence kinds, the validation gate, session records, the brief template with its Source block, personas. c12 should compose them into a new grain, not add a parallel system.

2. What the lens measures today

Every instrument in the pipeline, the question it answers, and who consumes it.

Reading the table: six of eight instruments are sales-motion instruments. They answer will they buy and does the pitch land. The organizing unit is the hypothesis (use case), and the gate is a PMF gate. That is the right lens for "hone use cases" (goals.md primary objective) and it should stay. But none of the instruments answers the design question at the grain design needs it: what is this person trying to see or do, in what situation, and what would the product have to answer?

3. What the design purpose actually needs — read off the artifacts that already exist

The best evidence for the missing grain is the two briefs that were written without it, by hand:

• briefs/cam-dashboard-directives.md is organized as "What the dashboard should answer" — lists of user questions per directive ("Which MCP servers are configured vs. connected right now?"), each followed by an "aha visualization" and a "money moment." Those questions are the micro problems. They exist only as prose in a brief; nothing in the corpus carries them as data.
• bob-wire c21.inventory/design-brief.md was assembled from the Aug 31 Mark Peterson session record plus Mark's notes. Its currency is: user stories in question form ("How many of those are we actually monitoring versus just detected?"), settled decisions as constraints, drill paths, a "standout use case," and explicit open questions. Again: user questions, persona, situation, and what the page must make obvious.
• Design c55 did persona work hypothesis-first because "there are no relevant agent-monitoring calls yet." It produced 11 persona hypotheses and a page × persona matrix — and none of it is linked back to this corpus now that calls exist.
• Design c92's detail-pages-guide.md is a purpose-and-value guide per page: what each page is for and who it serves. That is a product-surface vocabulary this repo does not have.

So the revealed design need is a set of things the corpus almost holds but does not name:

1. The user's question — the thing they want the product to answer, in their frame, persona-scoped. (Pain-point text holds it loosely; the category is thesis-level.)
2. The situation — what they were doing, what triggered the question, what they do instead today. (Urgency drivers are market-level; nothing captures workflow moments.)
3. The product surface — which page or view the question belongs to. (productArea is capability-level and predates the page vocabulary design now uses: Fleet Overview, Inventory, Users/Devices, Sessions, Session Details, Findings, Cost…)
4. The user's language — what they call things ("harness", "sensor", "agents at risk"), and mental-model statements. Value echoes capture our value in their words; nobody captures their nouns, which is what naming and brand voice need.
5. Reactions to artifacts — when a mock or page is shown on a call, which element drew the reaction. Since c90/c92 the team shows real mocks; the corpus cannot say "this was said about the Teams page."
6. Priority signal at problem grain — how many companies, how many first-hand, how intense, which persona, and whether it is already briefed or in design. The use-case scoreboard does this for hypotheses; nothing does it for problems.

4. Where the current lens serves design, where it is silent, where it distorts

Serves design well, keep untouched:

• Perspective + evidence ceiling + the code-computed gate. This is the honesty machinery, and the micro-problem layer should inherit it wholesale — a problem "is observed" only from first-hand perspective; advisor and internal statements are direction.
• Session records. Decisions-as-constraints is exactly what the c21 brief needed.
• The brief template's Source block and the three hand-off rules in pipeline.md.
• Verbatim quotes with speaker/date on every observation.

Silent (the gaps in §3): user questions, situations, surfaces, language, artifact reactions, problem-grain priority.

Distorts or misleads for design use:

• Category squeeze. A first-hand user question gets filed as pain-point / agent-visibility-gap and loses its specificity. README.md already warns about this ("an observation that fits no category can get squeezed into the nearest one"). Design needs the unsqueezed statement.
• Dashboard KPIs are sales-shaped. Avg Interest, Avg Urgency, Concrete Next Steps, Funnel. A designer opening the site gets a pipeline review, not a problem space.
• The triage workflow is dead weight. feedback.json has never held an item; its status lifecycle (new → acknowledged → committed → shipped → validated-in-use) is the lifecycle a problem wants, not a raw observation.
• The strongest voice is invisible. Cam's nine build-partner calls (the only usage-based, first-hand, agent-era evidence anyone has) sit in archive/phase-1/ under the old schema. The phase-2 gate cannot see them; the Cam brief cites them by hand.
• Calls are the only intake. inbox/ holds Cam's chat, the QControl-as-Signal docs; design cycles hold Mark's own reasoning; Slack and Linear hold more. "Source of truth for the problem space" fails if only transcripts count.
• Sister-project framing is stale. Design's CLAUDE.md still calls this repo "Customer intelligence & ICP data" and points at all-calls.json; pipeline.md says "insights and briefs." Neither says "problem space."

5. The micro problem — proposed shape

A micro problem is a question a specific kind of user needs the product to answer, in a specific situation, with the evidence that real people have it. It sits between the use case (macro, hypothesis) and the observation (atomic, one utterance):

use case  (hypothesis; validated by the gate)          e.g. agent-inventory
  └─ micro problem  (a user's question; observed/recurring)   e.g. "Who has the sensor installed, and who doesn't — and what do I do about it?"
       └─ observations  (utterances, perspective-tagged)      e.g. Mark P Aug 31, first-hand, "…that should be actionable"

Proposed record (data/problems.json, curated by Mark; extraction proposes, never writes):

Standing is computed, not narrated, mirroring the gate: observed = ≥1 first-hand observation tagged to it from a non-internal source; recurring = ≥2 distinct companies first-hand. Internal and relayed evidence is counted and shown, but labelled direction.

What changes in extraction is small: an optional problemId on any observation (as useCaseId is today), a per-call candidateProblems[] block (statement, persona, situation, speaker, perspective, verbatim, nearest existing id) for Mark to curate, an optional surface, and an optional artifactRef when a shown mock is being reacted to. Everything else in the schema stays.

6. What to keep, add, demote

• Keep every market instrument as-is. The use-case scoreboard, gate, positioning readout, and sales KPIs continue to answer "hone the use cases." goals.md gains a second lens rather than losing its first.
• Add the micro-problem layer (§5), a product-surface vocabulary, a persona registry, document intake, artifact-shown declaration at triage, and a /problems view with problem-grain priority.
• Demote (not remove): sales KPIs move off the dashboard's first row in favour of problem standing; feedback.json retires into the problem lifecycle (decision needed).
• Reconnect: phase-1 Cam calls as legacy build-partner evidence (decision needed); design c55 personas into the registry; design cycles cite problem ids so status can close the loop.

7. Recommendations

Ordered by leverage. Each maps to a thread in plan.md.

1. Hand-draft the first problems before writing code (archaeology). Read the six phase-2 calls, the Cam brief, the c21 brief, and c55's personas, and write the first 10–15 micro problems by hand in the proposed shape. If the shape does not hold against real material, fix it here, cheaply. Replicate first.
2. Add the problem layer to the pipeline — registry, problemId, candidateProblems[], computed standing. Same pattern as use cases, so the extraction prompt and the gate change by analogy.
3. Give the corpus a product-surface vocabulary sourced from design's page world (PRODUCT_SURFACES in vocabularies.ts, kept in sync with design's page registry by hand, single source here). Then a brief for a page can pull everything ever said about that page.
4. Declare shown artifacts at triage (a third triage field, optional): which mocks/pages were on screen. Reactions tagged with artifactRef become design feedback that routes to the cycle that owns the mock. This closes the wireframe → call → refinement loop that pipeline.md stage 6 leaves undefined.
5. Open a document intake. inbox/ material, Cam's chat, pasted Slack threads, Mark's notes enter the same observation stream under a declared profile (callType: document, source: document). Same prompt, same honesty rules, hand-authored sidecar. This is what makes "source of truth for the problem space" true.
6. Reconnect the Cam calls. Re-extract the nine phase-1 Cisco calls under the phase-2 schema as build-partner, flagged legacy so market KPIs can exclude them while the problem layer counts them. Roughly nine calls on the Batches API, well under a dollar.
7. Widen goals.md to two lenses. Keep "Hone the use cases." Add "Form the problem space": which questions do users ask of the product that no surface answers; which problems are recurring and first-hand; which surfaces attract the most friction; what do users call things; which problems are briefed but unshipped.
8. A persona registry as shared truth. data/personas.json seeded from c55's one-pagers; PERSONA_TYPES stays as the coarse attendee tag; problems and observations reference persona ids. Design's persona hypotheses then get evidence instead of staying hypothesis-first.
9. Briefs get kinds and a problem reference. kind: problem | story | position in INDEX.md; the Source block lists problem ids and their standing; /brief <problem-id> drafts from the registry. A story is a brief kind: a narrative that composes several problems, a persona, a situation, and verbatims — the "tell stories" artifact, usable for demos and for seeding fixture worlds like c92's Meridian data.
10. Close the loop with a consumers scan. A script reads ../design/cycles/*/ and ../bob-wire/cycles/*/ for brief filenames and problem:<id> references, writes data/consumers.json, and advances problem status to briefed / in-design. Add hand-off rule 4 to pipeline.md: a design cycle's initial prompt cites the problem ids it works.
11. Language capture. A small language[] block per call (term, meaning as used, speaker, perspective) — the user's nouns and mental-model statements. Cheap in extraction, high value for naming decisions design owns.
12. Re-shape the dashboard for the design reader. First row: problems observed / recurring / briefed / shipped; a /problems page with standing, persona, surface, use case, companies, and drill-down; sales KPIs one row down. Insights gains a "by surface" facet.

8. Avenues you may not be considering

• Challenge evidence for problems. The direction idea (validates / challenges) applies at problem grain too. Mark Peterson saying "remove the risk posturing, we don't have it flushed out" is evidence against a problem being real or ready. Recording it keeps the registry honest and gives "retired" a reason.
• The problem graph as a queryable thing. Problems ↔ use cases ↔ personas ↔ surfaces ↔ calls is a small graph. Design's HISTORY already floated promoting market-analyst to an MCP server (qpoint-market) if cross-project queries got frequent. Once problems exist, a get-problem, problems-for-surface, evidence-for tool set is the natural interface for bob-wire and design agents — better than pointing them at a 42K-token JSON.
• Stories as fixture seeds. c92 runs mocks against a populated "Meridian" seed. If stories are written from real problems, the demo world can be generated from them — the narrative and the sample data agree.
• Silence as signal. Track which surfaces and use cases have no first-hand problem after N calls. On a six-call corpus this is noise; at thirty it is the cheapest prioritization signal available.
• Problem lineage in time. A problem's first sighting, the date it was briefed, shipped, and re-heard after shipping is the validated-in-use moment nobody currently records. Dates on status transitions cost nothing and make the "feedback → roadmap → shipped loop" from design c62's partner research real.
• Internal working sessions in the design repo are inputs too. Mark's initial-prompt.md files and c55's persona reasoning are internal-perspective hypotheses. Registering the problems they assert (as internal origin) and then watching calls confirm or challenge them is the honest version of hypothesis-first work.
• Weekly problem digest. Design keeps digests/. A short generated digest — new candidates, standing changes, problems briefed this week — is a cheap routine once the registry exists. Not this cycle; worth naming.