Arc Skills / Architecture and engineering budgets
Write a concept of operations
A ConOps explains how people and the System achieve the service goal through time. Arc Skills takes stakeholder needs and a boundary and returns a concise narrative and phase table suitable for discovering missing decisions.
Use this skill
Use Arc Skills to draft a concept of operations for my System.
Inputs:
- Stakeholder purpose, System boundary, operating environment and user roles
- Preparation, activation, routine use, off-nominal response and recovery evidence
- Existing requirements, handoff responsibilities and decision authority
Return a short purpose narrative and phase table with actor intent, System response, feedback and end condition. Keep unsupported restart or remote-control authority as an explicit open decision.What you provide and what you get
| What you have | How it is used | What you get |
|---|---|---|
| Stakeholder need and boundary | Defines the service from the operator viewpoint | Purpose and operating context |
| Phases and actors | Orders actions and handoffs | Phase-by-phase ConOps excerpt |
| Fault and recovery constraints | Separates known protection from open authority | Explicit operational decisions |
Remote pump-station ConOps excerpt
Illustrative engineering example.
This fictional station delivers water on an operator request when inlet conditions permit. The concept describes the service and observable behavior; it does not pick a particular sensor, controller or communications implementation. The quoted local pressure-loss stop is an illustrative known behavior, while remote recovery authority is missing.
Purpose: The operator requests flow and receives enough status to know whether pumping has begun or stopped. The station protects itself on loss of inlet pressure. Remote confirmation during a connectivity outage and restart authority are open.| Phase | Actor intent / trigger | Station response | Outcome or open decision |
|---|---|---|---|
| Prepare | Technician confirms station ready | Reports availability and inlet condition | Operator can request start |
| Start and run | Operator requests flow | Checks inlet pressure, starts pump, reports flow | Flow available if conditions permit |
| Pressure loss | Inlet pressure falls | Stops pump and raises local alarm | Protected stop; operator notification depends on link |
| Connectivity loss | Remote link unavailable | Local protective stop rule still applies | Remote acknowledgment and queued commands unresolved |
| Recovery | Operator or technician seeks restart | Authority not specified | Open: who confirms safe re-entry? |
The pressure-loss path has a known local protective response, so loss of the remote link must not be described as disabling that behavior. At the same time, this draft cannot promise that an alarm reaches the operator while connectivity is down. Those are different operational facts.
The unanswered recovery question affects requirements, access and verification. An approved ConOps would identify who checks inlet conditions after the fault and who authorizes restart; this excerpt leaves the decision visible rather than assuming autonomous restart.
Write the operating story
- Begin with the user goal, system boundary, roles and conditions for success.
- Describe preparation, activation, routine operation, fault response and recovery in time order.
- For each phase, state actor intent, system response and observable information.
- Mark any missing handoff or authority as an owner decision before baselining the concept.
Questions about this task
How detailed should a ConOps be?
Detailed enough for stakeholders to see the operating decisions and derive scenarios, without locking in an unsupported implementation.
Does this excerpt approve remote restart?
No. Restart authority remains an explicit operational decision for the responsible owners.
Sources and further reading
- NASA Systems Engineering Handbook: system design processes: Stakeholder expectations, logical decomposition, functional allocation and design decisions.
- NASA Systems Engineering Handbook: technical management: Technical assessment and decision records.