Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.oktolabs.ai/llms.txt

Use this file to discover all available pages before exploring further.

​
Ideation

You can use an ideation when a feature is still ambiguous and needs structured questioning before it becomes a spec. The ideation stage holds the early title, problem statement, notes, Q&A, mockups, architecture diagrams, and evaluation history that will later feed spec drafting.

​
What is an ideation

An ideation is the first Pulse artifact in the ADLC pipeline. It captures a product or engineering intent before the team commits to requirements. Use it when the work still has open questions about scope, users, constraints, tradeoffs, or expected behavior. Do not skip ideation for broad work. A direct spec is fine for a small mechanical change, but larger work benefits from the ambiguity-killer loop because the questions and answers become durable context instead of chat history.

​
States and gates

StateMeaningTypical next move
draftThe idea exists but has not been interrogated.Ask questions or move to evaluating.
evaluatingThe agent is checking ambiguity, confidence, and missing constraints.Answer Q&A and call okto_pulse_evaluate_ideation.
refinedThe idea is clear enough to feed a spec or refinement.Derive a spec or continue into refinement.
doneThe ideation has served its purpose.Keep it as history.
cancelledThe idea should not proceed.Archive or leave as a record.
The main gate is the evaluation result. If okto_pulse_evaluate_ideation still reports unresolved ambiguity, keep asking and answering before deriving a spec.

​
The ambiguity-killer protocol

The ambiguity-killer loop is a short cycle:
  1. The agent reads the ideation context.
  2. The agent asks targeted free-form or choice questions.
  3. The human or another agent answers.
  4. The agent evaluates the ideation.
  5. The ideation moves to refined only when the remaining ambiguity is acceptable.
okto_pulse_ask_ideation_question
okto_pulse_answer_ideation_question
okto_pulse_evaluate_ideation
okto_pulse_move_ideation
Treat the evaluation as a gate, not as prose feedback. A low-confidence result means the next action is more Q&A or narrower scope, not spec generation.

​
Knowledge and mockups

Attach source material at ideation time when it explains the problem: screenshots, short notes, customer examples, existing code references, or design sketches. Ideation knowledge can be listed, opened, and removed through the ideation knowledge tools. Mockups belong here when the user experience is still exploratory. Attach them early so downstream spec and card work can copy the artifact rather than relying on a chat transcript.

​
Architecture diagrams

Ideation architecture diagrams are useful when the idea touches system shape: service boundaries, event flow, API ownership, or data model changes. Create or import the diagram during ideation, then render it when the team needs a visual checkpoint.

​
Deriving a spec from an ideation

okto_pulse_derive_spec_from_ideation creates a spec from the refined idea. The derived spec should carry the problem, accepted constraints, Q&A decisions, knowledge links, mockups, and architecture context forward. 
okto_pulse_derive_spec_from_ideation(board_id="...", ideation_id="...")
Use refinement first when the idea needs deeper investigation before requirements are written.

​
Versioning and history

Pulse keeps ideation history and snapshots so an agent can answer: what changed, who changed it, and why the later spec contains a particular requirement. Use okto_pulse_get_ideation_history and snapshot tools before overwriting a contested idea.
Last modified on May 8, 2026