Operational Concept Document (OpsCon / CONOPS)

The problem this solves

Spec documents get written twice: once as engineering, once as formatting. Teams keep requirements in a tool, then spend days copying them into a template, renumbering sections, and rebuilding the traceability table. By the time it is signed, the model has moved on.

How it works

You are generating a formal Operational Concept Document (OpsCon / CONOPS) for the system modeled in [model name] in Dalus, following the guidance in ISO/IEC/IEEE 29148:2018 (particularly the System Operational Concept and Concept of Operations material).

SOURCES, resolve in this order before doing anything else:
1. Check whether a copy of ISO/IEC/IEEE 29148:2018 (or a relevant OpsCon/CONOPS guide such as ANSI/AIAA G-043) has been made available in the model’s attached documents or this conversation. If present, derive structure and content expectations from it and cite specific clause or annex numbers only when you are reading them from that copy. Use of licensed standards content with AI tooling is subject to the user’s licence terms.
2. If the user has uploaded their program’s own OpsCon/CONOPS template or an example document, that file governs APPEARANCE and numbering. The standard governs CONTENT and section intent. Merge the two.
3. If no standard text is available, generate from a clear operational-concept structure (Purpose & Scope, Operational Context, Users & Stakeholders, Operational Scenarios / Use Cases, Modes & States, Operational Constraints & Environment, Traceability) and state on the cover that the document was generated without the standard text present.

READ THE MODEL fully: part hierarchy, actors/users, states, modes, mission/operational cases, use cases or scenarios, connections and flows, requirements that constrain operations, hazards, assumptions, dependencies, and any operational concept information already captured.

READ-BACK, always, before generating: report in a short message:
- counts of actors/users, states, modes, and operational/mission cases found;
- how many formal requirements are linked to operational behaviour;
- presence or absence of scenario/use-case content;
- the two or three structural gaps the reader should expect to see flagged.
Then ask exactly ONE question combining: does project tailoring apply, and is there a document ID scheme and issue/revision to use (otherwise auto-generate and mark it). If the user replies “fast”, skip further questions and use defaults.

STRUCTURE AND MAPPING:
- Purpose and scope of the operational concept.
- System operational context and environment (derived from model context and external interfaces).
- Users, operators, maintainers and other actors — roles, locations, and characteristics.
- Operational scenarios / use cases / mission cases drawn directly from the model. Present them as structured narratives or tables (actors, preconditions, main flow, alternative flows, postconditions). Do not invent scenarios.
- Modes and states, including transitions, with diagrams described or referenced where the model contains them.
- Operational constraints, external conditions, and assumptions that affect how the system is used.
- Linkage to system requirements: show which requirements are satisfied by or constrain each major operational scenario or mode.
- Grouping or container records are not treated as operational content.

VERIFICATION & CONSISTENCY:
- Operational statements that claim quantifiable behaviour should be checkable against model attributes and linked requirements.
- Flag contradictions between scenarios, missing actors for described interactions, states with no entry/exit conditions, and scenarios that reference elements not present in the model.
- Never invent missing scenarios, actors, or states.

QUALITY RULES:
- Scenarios must be clear, complete enough to be useful, and free of implementation detail.
- Vague operational language (“user-friendly”, “efficiently”, “as needed”) is recorded as a finding with a suggested clarification.
- Findings use the same severity scale: Blocker / Major / Minor.

GAPS: never invent operational content. End with a consolidated gap list ordered by what most prevents a complete operational concept, phrased as work to do in the Dalus model.

LAYOUT:
- Narrative sections for context and constraints.
- Structured tables or clearly headed blocks for scenarios/use cases and for modes/states.
- Traceability between operational elements and requirements in a compact matrix (landscape if wide).
- Empty major sections receive a short explicit statement of what is missing rather than long placeholder text.

OUTPUT QUALITY, non-negotiable:
- Word document with clear section numbering, populated table of contents, running headers, page numbers, and a cover page carrying document ID, issue/revision, generation date, source model name and ID, sources used, tailoring note, and DRAFT status.
- No instructional text left in the body.
- Before delivering, visually verify cover, TOC, one scenario section, and the gap list. Fix and re-render if needed.
- This workflow only reads the model. After delivery, offer (do not execute) turning the gap list into tracked model tasks.

Replace the [bracketed] placeholders with your model and project names.

Example output

What you get

Your format

Other tools hand you empty templates to type into. Because the document chain maps to requirement levels in the model — stakeholder needs at the top, system requirements below, satisfied by parts — one Dalus model emits the whole chain and cross-document traceability comes free.

Common questions