[RFC]: Bring product discovery into the Ideation phase: an opt-in design-thinking flow that explores and validates an idea before building

[akash-doshi]

Summary

Ideation today accepts unverified answers, validates them only after commitment, burdens reviewers at identical weight regardless of stakes, and starts its record after the asks that formed the initiative are gone. This RFC proposes a second implementation that embeds design thinking in the phase's native machinery of stages, artifacts, gates and skills. The flow builds an evidenced current-state picture, expresses the future state as at least three structurally distinct options, carries the thinking in two working records (open questions and assumptions), tests the riskiest assumptions first through cheap composed tests, lets each cycle's evidence reshape both pictures, and ends in commit, pivot or park over a decision pack that is a projection of the phase's own records, current without anyone assembling it. We extend the existing intent-capture stage in place, additively and for every scope that runs it (materials-first intake, source-labeled answers, mandate and decide-by capture, two new produced records), and ship four new compiled stages (current state, future state, experimentation, decision), one stock scope named discovery, framework-default artifact templates, and a portfolio view as a severable slice, almost entirely authored core/ data. There is one intent stage: the flow enters through the stage every scope already runs, not through a parallel copy. The stages carry ordinary compiled frontmatter, so the 2.2.0 composer can EXECUTE or SKIP them per task. No stock scope gains or loses stages, and the six ideation files after intent-capture are untouched. Baseline: the v2 line at v2.2.10, HEAD 242953e. The implementation is PR #526 at version 2.2.11.

Motivation

Every current Ideation stage has one shape: questionnaire, answers, markdown, approval. The questionnaire is valuable. The problems sit around it. The observations below come from a two-day retro with five enterprise teams on real work items, a small sample stated as such, and each problem is also visible in the stage files themselves.

1. One knowledge instrument. The phase never analyzes the code, design system, data or standards a team already has (reverse-engineering exists, reachable only in Inception). Trusted retro outputs came from existing assets. Untrusted ones were unsourced estimates, including an untraceable twenty-two week figure.
2. Validation after commitment. Every output is a document, so a claim first meets reality in Construction, the most expensive place to learn it. The first retro artifact that executed was wrong on first run, fixed only because running it exposed the error.
3. Review weight does not match decision weight. Seven identical approvals. One retro team hand-cut thirty-two stages to twelve with two gates. The composer now owns stage selection, but a grid cannot express gate weight or which answers a decision needs.
4. The record starts too late. An initiative enters as a captured intent with no trace of the asks, hunches and support themes it condensed from, and nothing aggregates what waits on a person running several initiatives.

Detailed Proposal

Goals with success signals. Ground ideation in what exists (fewer questions asked of the user for the same initiative shape). Validate before commitment, measured by outcomes: a working artifact before every decision gate, few reversals of committed directions, rare post-commit surprises invalidating an assumption marked supported, parks that pay for themselves against testing cost. Gates where direction is decided, one warning tracked: a gate answered faster than its content could be read. Handoff without re-asking. Non-goals. No change to stock scopes or the seven files, no stage-selection machinery of ours, no Inception behavior change for stock runs (the implementation answers D3 with optional consumes that are silently dropped when the artifacts do not exist — see D3), no cycles.

Where initiatives come from, and the portfolio view. Teams keep their ideas in their existing tools, and the system consumes asks from wherever they live. It adds no board and no submission channel, because a second surface becomes a second source of truth. Starting an initiative is a human act: a person imports one or more asks, or states them directly, and the agent drafts the founding record. That record opens with where this came from (who asked, how often, what they said, the source of each ask), and the asks seed the first open questions, so the initiative starts warm instead of blank. Intent's mandate field records what is already decided and by whom, so the framing gate presents pre-closed choices as pre-closed. A late-arriving ask joins an in-flight initiative, agent-proposed and human-confirmed, surfaced in that cycle's recap. The portfolio view is a list, never a board: each initiative on one line with its name, progress word and next step, above it what waits on you with ages oldest first, then recent verdicts, then parked initiatives with ages and one-line reasons. The working view stays private, and a published projection carries the curated version to sponsors. This slice lands as its own PR (PR 3), and we invite the maintainer call on whether it should split into a follow-up issue.

The five stages (stage 1 is the existing intent-capture, extended in place, and the four new slugs are final at PR). The stock discovery grid runs all five, recompose can flip pending ones mid-run, and stage prose covers every legal flip (experimentation composed away leaves a decision gate saying no tests ran). Optional inputs declare required: false with fallbacks, deliberately skipped producers are marked expected-absent per 2.1.7 consumes_absent, and gates inherit 2.1.6 human-presence gating: asynchronous decision requests park until a person acts in session. Each test cycle ends in a recap, recaps batch into one cross-initiative digest, and a standing steer lets the person redirect at any moment (reframe, reorder assumptions, park).

Stage	Gate at exit	Produces
intent	light confirm	initiative-brief opening with where this came from, source-inventory, open-questions, stakeholder-register
current-state	playback gate	current-state, design language record
future-state	framing, then concept	framing-decision, future-state, concept-selection, assumptions, narrative-draft
experimentation	recaps, no gate	evidence-record, promoted artifacts
decision	commit (continue here via engine scope-change, or hand off), pivot or park	decision-pack, decision-record, handoff contract or park narrative

How progress reads. Progress reads as one of five computed words, not stage names: exploring, shaping, testing, deciding, decided. The word is a read-only function over question statuses and coverage, assumption statuses and their relevance to the verdict, evidence strength by risk type, pack part presence, and recorded gate events. Nobody asserts it and nothing drags it, a leaner composition carries a thin-evidence qualifier, and progress may move backward when an answer reopens, explained in the digest. At deciding the decision pack is issued to stakeholders, before the gate rather than at it. The stage names stay engine machinery.

The two records. The open questions hold what materials, research or people can answer, each entry with origin, status, dependencies, and a sourced answer with confidence. When an answer changes, dependent entries reopen. The assumptions, subtitled what must be true, hold claims only building, running or showing can settle, each carrying type (desirability, usability, feasibility, viability), origin, rests-on, disproved-if (written before anything runs), test, status, evidence, disposition (keep, promote, discard). A question moves to the assumptions when only building or showing something can settle it. Tests are composed plans over five primitives (Investigate, Walkthrough, Build, Run, Show), one plan serving several assumptions, each with its own verdict. Mock-ups render in the design language record, a persistent capture of the team's components, tokens and UX patterns.

A walkthrough, an accessibility remediation of an internal operations tool. A stakeholder ask, an engineer's hunch that the component library is the blocker, and a support theme about screen reader failures import into one initiative. intent opens the record with who asked and how often, inventories the audit report, repository and design system files, seeds the open questions from the asks, records the compliance deadline in the mandate field, captures the org's proposal format, and ends in a light confirm. current-state: mining answers the tool screen by screen, the design language record is captured, and the playback gate confirms the as-is picture. future-state: the framing gate presents the mandated part as pre-closed, the concept gate selects among mock-ups in the captured design language. experimentation: one composed plan, Build mock-up variants then Show them to assistive-technology users, serves a feasibility claim about the component library and a usability claim about the assisted journeys. A reaction invalidating an answer the framing rests on pauses the loop: adjust, continue or pivot. At deciding the pack goes to stakeholders before the gate: working artifact, one-page narrative in the org's format, source-labeled evidence summary. decision: commit emits the handoff contract (fields carry status, confidence and source), promoted artifacts and the evidence record, then asks where the build happens: continue in this workspace (the stage relays the engine's own scope-change and the same workflow proceeds into Inception with the full record, covered ideation stages marked skipped) or hand off to the team that owns the code (this workflow completes, the contract travels). Park would instead emit the park narrative: what was learned, why not now, what would reopen it.

Existing tools. The record never replaces the team's issue trackers, wikis, whiteboards or design files, and reads them as knowledge sources from day one. The on-disk record is the source of truth in this iteration. Entries carry stable identifiers, and a small mapping table remembers which entry became which external ticket or page, so a later iteration can project without duplication.

flowchart TD
    A[Asks in the team's existing tools] -->|a person starts an initiative| B[intent]
    B --> C[current state]
    C --> D{playback gate}
    D -->|correct| C
    D -->|confirm| E{framing gate: 3 or more distinct framings}
    E --> F[future state: 3 to 5 options]
    F --> G{concept gate}
    G --> H[experimentation: riskiest assumption first, one test plan per cycle]
    C --> R[(living artifacts: current and future state)]
    F --> R
    H -.->|corrections write back| R
    H -.->|reframe trigger| E
    H -->|open assumptions can no longer change the verdict| I[decision pack issued to stakeholders]
    I --> J{decision gate}
    J -->|commit| K[handoff contract into Inception]
    J -->|pivot| E
    J -->|park| L[park: record kept and resumable]

Loading

Files (new unless marked):

core/
  scopes/aidlc-discovery.md  name, depth, keywords, description, testStrategy
  aidlc-common/stages/ideation/  six existing files after intent-capture untouched
    intent-capture.md  EXTENDED in place, additively, non-breaking for its four stock scopes
    current-state.md
    future-state.md
    experimentation.md  per-entry iteration, pending D1
    decision.md
  skills/  mining, design capture, standards audit, market research, five primitives, narrative
  templates/  open-questions, assumptions, evidence-record, recap, decision-request, decision-pack
  templates/space/  portfolio  PR 3
  sensors/  question coverage, unsourced claims, pending D2
docs/reference/16-artifact-vocabulary.md  modified

Delivery and tests. Five PRs, each editing core/ only, regenerating dist/, passing --check and bumping the version trio, docs in the same PR. PR 1: the extended intent-capture stage (non-breaking for its four stock scopes, where this came from as a conditional section of the intent statement), the scope, the four new stage files with the fallback loop, nine framework-default templates (the intent statement deliberately ships none), required-question defaults (t39 scope loop extension, routing e2e modeled on t53, advisory-edge update). PR 2: the skills, authored fresh as agent-loadable knowledge (per-skill fixture runs). PR 1 and PR 2 are a pair: the first ships the flow's structure, the second the craft the agents load to execute it deeply, and we ask that both be reviewed and merged together, packaged however this repo prefers (one PR with two clean commits, two PRs with the second marked stacked, or a staging branch). PR 3: portfolio view. PR 4: the D2 tools (unit tests per tool). PR 5: per-entry iteration (tests modeled on the per-unit precedent).

Graduation. The scope is a pilot: promotion needs real initiatives across at least two shapes with the signals met, then a follow-up RFC may propose it as the default ideation. Unused for two minor releases, it is removed.

Decisions requested.

• D1. Experimentation repeats once per assumption entry. The engine already iterates per unit of work via for_each (PR fix(engine): drive per-unit for_each iteration for Construction stages (#368) #444). We ask to generalize that mechanic to assumption entries: per-entry record directories as the coverage ledger, an assumption analog of the unit directive, gate suppression until every entry has a verdict, a recap per entry. Fallback, shipped in PR 1 either way: a bounded prose loop resuming from artifacts on disk.
• D2. Small deterministic tools, or advisory prose only in v1? Bundled here: sensors for question coverage and unsourced claims, read-state for digests so an unread recap never counts as a review, and the maturity rollup if the word wants a home in the status command. Deterministic checks rather than model-graded scores, since model judges are unreliable on open-ended quality. One optional extra, take or decline independently: a similarity check flagging near-duplicate candidate framings before they count toward the framing gate's minimum of three. Advisory prose is a fine v1 for the sensors, while read-state and the rollup have no prose fallback: PR 4 or wait, per maintainer call.
• D3. How does Inception consume the handoff contract, promoted artifacts and evidence record? PR feat: bring product discovery into Ideation — an idea-to-decision flow that feeds Inception (2.2.11) #526 implements the proposal as ordinary optional consumes: requirements-analysis and user-stories declare decision-pack (required: false), refined-mockups declares design-language-record and evidence-record the same way, and the decision stage folds a "What Discovery Validated" section into the intent statement at commit. Absent the artifacts (every stock run), the resolver drops the entries silently. Maintainer preference still governs the final shape.
• D4. Delivery vehicle. The plugin mechanism (roadmap 2.3.0) is in open review at PR feat: AIDLC plugin mechanism (2.3.0) #475. Preference: core now, since the mechanism is unmerged, its compile-side carry-through of authored stage numbering is deferred per its own notes, and Codex runs plugin stages without persona specialization. Migrating into a plugin once it lands is a clean move we welcome.

How this graduates or retires. We do not ask the framework to carry two ideation implementations indefinitely. The discovery path is a pilot behind an explicit opt-in, and its future is decided by evidence against five criteria: at least ten completed discovery runs on real initiatives across at least three independent teams, each ending in an explicit commit, pivot, or park; outcomes at least as good as the questionnaire path on comparable work (no commit later reversed for a reason the flow should have caught, at least one park whose testing cost was demonstrably lower than the build it avoided, gate responses consistent with the content actually being read); zero hard failures attributable to the new stages; artifact parity confirmed for everything the delivery path consumes from ideation today (per the D3 answer); and maintainer acceptance of a follow-up RFC. Met, that RFC proposes the stock scopes adopt the four discovery stages behind the shared intent stage and the six questionnaire stages retire behind a deprecation release. Not met, the scope is removed with a written account of what was learned.

Alternatives Considered

1. Do nothing. The composer right-sizes ceremony but selects among stages that all gather knowledge one way. Answers stay unsourced and validation stays in Construction.
2. Keep the seven stages and add revision loops. Loops widen no knowledge source and add no tests.
3. Fewer stages, more stages, or in-place edits. Merging current and future state hides where the as-is picture is confirmed. In-place edits break the zero-change guarantee and forfeit the pilot.
4. Ship as a plugin. The strongest alternative and a live decision, see D4. The mechanism is in open review and not yet merged.

Drawbacks

• Maintainer surface: one extended stage file, four new stage files, one scope file, roughly ten skills, nine templates and two sensor manifests, close to thirty new files under core/, plus docs and tests in lockstep. We maintain the scope through the pilot.
• Context cost: the stages load the open questions and assumptions each turn, mitigated by the opt-in scope.
• Experimentation adds wall-clock time before commitment, deliberately: parking a bad idea early is the payoff.
• The portfolio view depends on team adoption habits, mitigated by keeping it a read-only derived list with nothing to groom, and severable as its own slice (PR 3).

Additional Context

Prior art. The agentic-product-discovery project supplies discovery skills and the handoff contract format (license confirmed before PR 2, re-authoring as fallback). In this repo: per-unit iteration, reverse-engineering, park.

Future possibilities. Composed scopes with empty keyword lists already give repeatable work a reusable stage set behind a human gate. Standing open questions and design language records that repeat runs read remain ours. Projecting record entries into the team's existing trackers and wikis is a later iteration.

Related issues. #407 (Ideation and Inception sequence), #478 (stage numbering), #368 (per-unit iteration).