c16 — Cycle History & the Question Model

How the agent control plane evolved, where the four questions came from, and which new questions rise to the same level (with the sub-questions that should fold into a parent instead). Companion to analysis.md, phase2-review.md, seat-framing-review.md, seat-composition-review.md, and qdash-premise-eval.md.

1. Progression — the story so far

The throughline: the build kept gaining interpretation — from raw state (wf1) → value per page (wf2) → value per seat (wf3) → a conceptual map across seats (wf4).

2. The four questions — origin & definition

Origin: the qdash purpose doc, inbox/qdash — what each tab is for.md, opens by grouping the 12 tabs into four areas — before describing a single tab:

"The tabs are grouped into four areas: Assurance (is the fleet healthy?), Security (is it safe?), Identity & Access (who's accountable?), and Admin (how is it wired up?)."

They are the doc author's plain-language framing — what is the user actually asking? — laid over the feature list. They were absent from wf1–wf3 (persona-first) and re-introduced in wf4.

The escalation logic: the four are deliberately ordered — alive → safe → accountable → trustworthy-to-read. Admin closes the loop with an honesty check on the other three.

The cross-cutting thread (not a question — a design law): honesty about what's known vs guessed. It runs through every area — est cost badges, ghosted "not yet built" cards, shadow agents priced worst-case, "observed not verified," "evidence not conformance." Any new question inherits this law.

3. The bar — what makes a question first-class

A candidate is peer to the four only if it clears all of these:

1. Plain-language stake — a stakeholder asks it out loud, in their words.
2. Spans surfaces — it gathers several surfaces; it's an area, not a tab.
3. Distinct owner & register — its own primary persona and emotional tone.
4. MECE-ish — it does not collapse into an existing area.
5. Fits the escalation — it has a natural place in the alive → … → trustworthy arc.

4. New first-class concerns (recommended)

4a. "Is it working?" — Effectiveness / Outcomes (strong addition — the real hole)

The original four never ask whether the agents actually do their jobs well. Assurance asks alive & within budget; Performance measures latency & cost — how fast and expensive a model responds, not whether the task succeeded. The doc and wf3 both explicitly flag this as the named unmeasured gap.

• Stake: Are the agents accomplishing their tasks well — or running cheaply, quickly, and failing half the time? "Healthy" ≠ "effective."
• Owner: Engineering + the product/business owner; Executive on the ROI line ("are these agents earning their keep?").
• Surfaces it would gather: task success rate, goal completion, intervention / human-handoff rate, output-quality signals, rework / retry rate, per-workflow outcomes. (Today these are the ghosted cards on Performance.)
• Design feel: a report card / ROI read — not a speedometer.
• Clears the bar: ✅ plain stake, ✅ multi-surface, ✅ distinct owner (eng + business), ✅ does not fold into Assurance/Security, ✅ slots into the arc as alive → effective → safe.
• Corroboration: the eval's P1 gap Agent Reliability / Task Outcomes, and Performance's own ghosted "Task Outcomes & Quality — not yet built."
• Placement: a new top-level area, Effectiveness — is it working?; Performance becomes the latency/cost slice beneath it.

4b. "What happened?" — Activity / Explainability (recommended; borderline-but-rising)

The raw behavioral narrative — agent → action → outcome — reconstructable after the fact.

• Stake: Can I replay exactly what an agent did, step by step, for an incident or an audit?
• Owner: Security (incident response) + Compliance (audit) + Engineering (debugging).
• Surfaces: activity timeline, decision/action log, session replay, event families, the agent→action→outcome trail. (The data already carries it: activity event families + timeline in app/data/c16-fleet.ts; no surface exposes it yet.)
• Design feel: a flight recorder — exhaustive, queryable, timestamped. Distinct from Findings, which is the distilled worklist; this is the full record.
• Bar check: ✅ stake, ✅ multi-surface, ✅ owners, ⚠️ MECE — it can read as a layer under Security/Identity. The tie-breaker: regulatory explainability for agentic AI is becoming a first-order demand, which argues for elevating it.
• Corroboration: the eval's P1 gap Activity / Decision Log.
• Placement: a first-class area, Activity — what happened?, with Findings sitting on top of it as the curated view.

If both are adopted, the model grows from four questions to six, and the arc becomes: is it healthy → is it working → is it safe → who's accountable → what happened → how is it wired?

5. Sub-questions — fold into a parent, don't elevate

Real concerns that feel big but are deepenings of an existing area. Recommendation: fold, and revisit only if a specific buyer makes one their primary lens.

6. Open questions / next steps

• Adopt Effectiveness as the fifth question? It needs new data (task-outcome signals) the model doesn't yet carry — the biggest lift, but the clearest gap.
• Adopt Activity as the sixth, or keep it under Security/Compliance? Decide based on how hard the explainability/audit requirement lands for your buyers.
• Usage Limits is already being slotted under Assurance (Finance/Exec/Engineering seats) — confirm it stays a deepening of Cost Center rather than drifting into its own area.
• When testing any future candidate, run it through §3 The bar before giving it a top-level slot.