1. Start in Cockpit and set your scope

• Open Cockpit first to see the current hotspots, blockers, and drill-down actions for the requirement set.
• Use it as your orientation screen before you decide whether the next step is intake, modeling, draft review, or cleanup.

2. Bring in source material

• Open Requirements → Sources and register the documents, workshop notes, process files, or code artifacts you are working from.
• Keep related source material together here so later review, traceability, and export conversations stay grounded in the same evidence.

3. Build the business context

• Use Glossary to define roles, business terms, and objects that the requirements should reference consistently.
• Use BPMN when the process flow is the clearest starting point for functions, actors, and step order.
• Use Requirements → Journey when stage and step flow explains the user path better than BPMN.

Optional supporting views: use Data model, UI, or Scenario only when they help explain the current scope. They support the main flow, but they do not need to come first.

4. Create or refine requirements

• Use Requirements → List to create, edit, and organize EPICs, HLRs, User Stories, and Acceptance Criteria directly.
• Use Requirements → Parser when you are starting from source text and want to draft structured candidates from that material before promotion.
• If you need AI-supported work, use AI Workbench for governed proposal packets, validation, and draft-only staging; use Local AI or Refinement local LLM review only after the source and scope are clear so advisory local model output stays bounded.
• If your starting point is process or journey modeling, generate drafts from BPMN or Journey, then keep the requirement wording aligned with the source and glossary language.

5. Review draft candidates and promote what is worth keeping

• Open Requirements → Inbox when BPMN, Journey, Parser, or other flows have produced drafts that still need analyst review.
• Promote only the drafts that are clear enough to join the main hierarchy, and leave rejected or weak candidates out of the canonical set.

6. Clean up and review the requirement set

• Use Requirements → Review to find duplicates, wording issues, weak structure, and other analyst cleanup work.
• Use Requirements → Traceability to inspect coverage across processes, journeys, intents, and linked artifacts.
• Use Change Impact when an incoming change needs read-only impact triage before you edit, refine, or promote requirements.
• Use Ask / Inspect when you have a question and need deterministic Q&A, search, or explanation over requirements and traceability.
• Use AI Workbench when you want governed AI context packets, strict proposal validation, Reality Extraction, or draft-only staging.
• Use Local AI when you want Ollama/local LLM review over normalized outbound packets with advisory human-readable results; it does not persist chat history, mutate canonical requirements, or change traceability.
• Use Requirements → Refinement when you want proposal-based rewrite, intent alignment, process-mapping help, or Run with Local LLM staged review without changing canonical requirements automatically.

7. Finalize requirements and prepare Governed Handoff

• Return to Cockpit or Requirements → List to confirm the set is ready enough for business review.
• Use Spec to generate stakeholder-facing HTML, Word, Obsidian, or governed Narrative Export bundles for NotebookLM from the reviewed requirement set.
• For ARIS delivery, open Requirements → List / ARIS readiness, set Work profile = ARIS delivery, keep the current filtered List scope, and follow Export / baseline readiness as one governed handoff preparation path.
• Open Governed Handoff to inspect purpose, audience, authority / trust, readiness, included and excluded scope, transformation risk, and the next action for the selected outbound package.
• Only after Governed Handoff shows the selected package is understood and unblocked, run the downstream export or external handoff action.