Arc Skills / Architecture and engineering budgets
Perform a make-or-buy technical assessment
A supplier claim may satisfy one parameter while leaving the actual integration uncertain. Arc Skills takes make and buy evidence for a defined deliverable and returns a conditional decision with the exact missing proof.
Use this skill
Use Arc Skills to assess making or buying my defined subsystem.
Inputs:
- Same deliverable boundary and acceptance requirements for both paths
- Supplier claims, technical data, Interface detail, qualification and change evidence
- Internal build, calibration, test-access and lifecycle capability evidence
Return a make/buy comparison separating facts, claims and unknowns, with retained integrator duties and conditions for selection. Do not invent cost, schedule or supplier qualification.What you provide and what you get
| What you have | How it is used | What you get |
|---|---|---|
| Common deliverable and requirements | Makes both paths comparable | Acceptance boundary |
| Supplier claims and evidence | Separates range claim from integration proof | Buy-side gaps and requests |
| Internal resources and test method | Tests feasibility of in-house path | Make-side capability gap |
Inertial unit choice with two different gaps
Illustrative engineering example.
A fictional purchased unit advertises the required angular-rate range. Its public sheet omits latency and connector pinout. The in-house option is conceptually possible, but the team has not shown calibration equipment or procedure capability.
Required angular-rate range: ±200 °/s
Buy candidate: supplier sheet claims ±250 °/s
Make candidate: proposed design, calibration capability unverified| Decision criterion | Buy | Make | Next evidence |
|---|---|---|---|
| Measurement range | Claimed ±250 °/s covers stated ±200 °/s interval | Design target not yet demonstrated | Supplier test conditions; internal prototype evidence |
| Latency | Not published | TBD architecture estimate | Bound in operating mode |
| Connector and data mapping | Pinout not supplied | Team could define, not yet baselined | Supplier ICD or internal design |
| Calibration and acceptance | Supplier process evidence TBD | Internal capability unproven | Calibration method and traceable records |
The supplier’s claimed ±250 °/s interval encloses the stated ±200 °/s need, but that is only one favorable supplier claim. It does not prove latency, electrical fit or acceptance in the assembled navigation system. Buying still leaves the integrator responsible for interface definition and system verification. Making the unit likewise requires more than a schematic: calibration and test access are decision gates.
The provisional outcome is to request supplier latency and pinout and demonstrate whether the internal team can calibrate to the required range and accuracy. If either option fails a must-meet requirement, that path drops out; without those inputs a price or schedule preference would be premature.
Compare identical deliverables
- Define one subsystem boundary, performance need and acceptance evidence for both paths.
- List what the supplier guarantees versus what the internal team can demonstrate.
- Expose integration, diagnosis, change control and lifecycle duties retained by the system owner.
- Recommend only conditional next steps until the missing hard constraints are resolved.
Questions about this task
Does supplier certification prove system compatibility?
No. It may support a component claim, but the configured interface and system-level behavior still need evidence.
Should commercial data be added?
Yes when supplied and decision-relevant; keep it separate from technical facts and do not manufacture costs.
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.