Arc Skills / Architecture and engineering budgets
Review a functional architecture for missing functions
A function diagram can look complete while failing to produce a required operator outcome. Arc Skills takes a named architecture revision and scenarios and returns a traceable coverage review with bounded findings.
Use this skill
Use Arc Skills to review my functional architecture against operational scenarios.
Inputs:
- Named architecture revision, function list, and System Interface map
- Scenarios with required triggers, responses and observable end states
- Source requirements that determine whether feedback or recovery is mandatory
Return scenario-to-function coverage, missing or duplicated behavior, handoff gaps and owner questions. Call a missing function a defect only when the source need supports it.What you provide and what you get
| What you have | How it is used | What you get |
|---|---|---|
| Architecture function list | Provides implemented or proposed responsibilities | Coverage status per function |
| Operational scenario | Tests trigger-to-outcome flow | Handoff and feedback path |
| Source requirements | Determines whether absence is a defect or an open need | Evidence-linked finding |
Valve opens, but can the operator tell?
Illustrative engineering example.
The fictional architecture receives an open command and energizes a valve. Its diagram says nothing about returning an observed valve state to the remote operator. Whether that omission is a defect depends on the controlling operational need.
Operator → open command → command receiver → actuator driver → valve
Potential feedback: valve-position sensor → status generator → operator
Requirement for remote confirmation: source TBD| Scenario obligation | Architecture function | Evidence status | Disposition |
|---|---|---|---|
| Accept remote open command | Command receiver | Shown | Covered at functional level |
| Drive valve toward open | Actuator driver | Shown | Covered function; achieved position not established |
| Determine achieved valve state | Sensor/status function absent | Not shown | Check whether remote confirmation is required |
| Notify operator of result | Status transmit function absent | Not shown | Gap only with controlling need |
The first two functions cover command and drive at this level; they do not establish actual valve movement. A returned “command accepted” message would also differ from measured “valve open” status. The review therefore asks what event the operator must know and what evidence produces it.
If the approved ConOps requires remote confirmation, add a proposed status-production and transmission path, then assign its owners and Interface exchange. If the need is only local movement, keep acknowledgment as a stakeholder question rather than manufacturing an architecture failure.
Walk from trigger to outcome
- Select one source-backed scenario and record its required observable end state.
- Trace transforms, decisions, commands, state retention and feedback across each System boundary.
- Classify each missing step as architecture gap, interface gap or unresolved requirement.
- Repeat the walk for a credible failed dependency or restart path.
Questions about this task
Is a missing label always a missing function?
No. Search for equivalent behavior under different wording and judge by the produced outcome.
Can this review verify valve performance?
No. It checks functional coverage and handoffs; physical performance needs analysis or test evidence.
Sources and further reading
- NASA Systems Engineering Handbook: system design processes: Stakeholder expectations, logical decomposition, functional allocation and design decisions.
- NASA Systems Engineering Handbook: product realization: Interface definition, integration sequence and verification context.