Arc Skills / Technical management and design reviews
Define technical performance measures and monitoring thresholds
Use Arc Skills to define technical performance measures that tell an engineer when a design needs attention. Each measure connects a controlled limit to a planned trajectory, current evidence, uncertainty and a specific response.
Use this skill
Use Arc Skills to define technical performance measures for this design.
Inputs:
- Controlled performance requirements and units
- Planned trajectories and current estimates or measurements
- Uncertainty, data sources, configurations and decision lead times
Return a TPM table with limit direction, planned/actual values, margin convention, evidence, owner and response. Propose warning thresholds only from supplied criteria; leave unknown thresholds as owner decisions.What you provide and what you get
| What you have | How it is used | What you get |
|---|---|---|
| Performance requirements | Define direction and units | Measures tied to real obligations |
| Planned trajectory and dated results | Track progress rather than one isolated number | Configuration-specific comparisons |
| Uncertainty and response criteria | Check decision significance | Warning and action logic with owners |
Three measures with different directions and evidence
Illustrative engineering example.
A sensor payload tracks mass, processing latency and signal margin. The example supplies engineering limits and current estimates, but no approved warning bands.
Mass: limit ≤50 kg; current 47 kg; possible growth +2 kg.
Processing latency: limit ≤100 ms; current measured 96 ms ±6 ms under a supplied bounded interpretation.
Signal margin: minimum ≥3 dB; current analysis 4 dB; degradation allowance unknown.
Review snapshots retain method, date, hardware revision and firmware revision.| Measure | Limit / direction | Current evidence | Comparison | Owner response |
|---|---|---|---|---|
| Payload mass | ≤50 kg; lower is better | 47 kg estimate, +2 kg potential growth | 3 kg nominal allowance; 1 kg after stated growth | Mechanical owner maintains component ledger and approves trajectory/alert criteria |
| Processing latency | ≤100 ms; lower is better | 96 ±6 ms bounded result | Upper bound 102 ms crosses the limit; acceptance rule absent | Processing owner resolves decision rule and relevant worst-case evidence |
| Signal margin | ≥3 dB; higher is better | 4 dB analytical estimate | 1 dB nominal surplus; degradation not bounded | RF owner provides model validation and degradation assumptions |
These are useful technical measures because their values can change a design decision. Tracking them over named milestones requires a planned trajectory; without that trajectory, the example is a current status table rather than a complete progress history.
Mass headroom, latency uncertainty and signal surplus cannot be combined into one percentage. The owner response follows the physical mechanism and supplied evidence. Warning thresholds remain unresolved instead of adopting a generic red/amber/green band.
Make every measure trigger a concrete response
- Distinguish mission effectiveness, technical performance and a TPM tracked across milestones.
- Define parameter, unit, limit direction, trajectory and evidence configuration.
- Show the formula and uncertainty interpretation used for comparisons.
- Connect warning/action criteria to margin, decision lead time and an accountable response; retain history after each update.
Questions about this task
Should we use the same percentage warning threshold for every TPM?
Only if the governing criteria justify it. Mass growth, latency uncertainty and signal degradation have different behavior and decision lead times. Start from those mechanisms.
Sources and further reading
- NASA Systems Engineering Handbook: technical assessment: Background on measures, review evidence and action resolution.
References inspected on 3 October 2026. The worked output is an authored example using the stated inputs.