Arc Skills / Architecture and engineering budgets
Compare architecture alternatives in a trade study
A trade study should eliminate an option only on a stated constraint and expose what remains uncertain. Arc Skills takes alternative architectures and evidence and returns a comparison that supports a conditional decision.
Use this skill
Use Arc Skills to compare my architecture alternatives at the same System boundary.
Inputs:
- Decision question, alternatives, operating scenario, and must-meet constraints
- Criterion values with units, configuration, source and evidence quality
- Agreed preference weights if they exist, plus key uncertain assumptions
Return a hard-constraint screen, comparable evidence table, sensitivity note, and the smallest check that could change the decision. Do not score unknown evidence as failure or invent weights.What you provide and what you get
| What you have | How it is used | What you get |
|---|---|---|
| Mission need and hard constraints | Separates feasibility from preference | Must-meet screen |
| Alternative configurations | Keeps both options at the same boundary | Comparable criteria rows |
| Evidence and weights | Qualifies confidence and ranking | Decision conditions rather than invented score |
A lighter option has an unverified bus
Illustrative engineering example.
Two fictional navigation assemblies meet the same processing need. Their measured masses are below the illustrative 5.0 kg allocation, but only one has bus-throughput evidence under the proposed traffic pattern.
Option A: 4.2 kg measured; bus capacity vendor estimate 25 Mbit/s
Option B: 4.6 kg measured; bus capacity tested 22 Mbit/s
Must-meet: ≤5.0 kg and ≥20 Mbit/s in operating mode| Criterion | Option A | Option B | Decision effect |
|---|---|---|---|
| Installed mass ≤5.0 kg | 4.2 kg measured; +0.8 kg raw headroom | 4.6 kg measured; +0.4 kg raw headroom | Both meet stated mass constraint for illustrative configuration |
| Bus ≥20 Mbit/s | 25 Mbit/s vendor estimate; configuration not matched | 22 Mbit/s tested in stated mode | A remains unverified; B has supporting evidence for stated mode |
| Integration evidence | Protocol timing test TBD | Test report available | A needs focused traffic test |
| Preference weights | Not supplied | Not supplied | No weighted total computed |
The 0.4 kg mass advantage of A follows from the illustrative mass evidence, but the bus criterion is a gate, not a preference that can be traded away with a score. A should remain conditional until a capacity test or guaranteed supplier bound covers the actual message mix and mode.
If the bus result for A is confirmed at or above 20 Mbit/s, the next decision depends on the team’s actual priorities and lifecycle evidence. If A falls below the threshold, it fails the stated architecture constraint regardless of its lower mass. This is the sensitivity that matters before weights are debated.
Keep gates separate from preferences
- Fix the same system boundary, operating need and mandatory constraints for every option.
- Screen each constraint using evidence at matching configuration and conditions.
- Compare remaining decision criteria with raw values and evidence maturity.
- Identify the one measurement or supplier response that could reverse the provisional result.
Questions about this task
Should I score an unknown bus value as zero?
No. Unknown evidence is not evidence of failure. Keep the option conditional and name the needed test.
When are weighted totals useful?
When decision owners have agreed criteria, scales and weights, and sensitivity shows the ranking is reasonably stable.
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.