Arc Skills / Architecture and engineering budgets
Allocate an end-to-end performance budget
An end-to-end limit is useful only when its start, finish and contributing path are explicit. Arc Skills takes a requirement and stage evidence and returns a proposed allocation with an honest uncommitted balance.
Use this skill
Use Arc Skills to allocate my end-to-end performance limit across its contributing stages.
Inputs:
- Requirement ID, metric and units, acceptance direction, start and finish events, and operating mode
- Current path, stage owners, measured or estimated bounds, and source revisions
- Applicable combination rule, shared-resource conditions, and reserve policy
Return a contribution table with proposed owner allocations, current bounds, aggregation equation, and uncommitted headroom. Leave unknown stages unresolved and distinguish allocation from achieved margin.What you provide and what you get
| What you have | How it is used | What you get |
|---|---|---|
| 100 ms detection-to-display requirement | Fixes the acceptance direction and observable endpoints | A top-level constraint retained verbatim |
| Path diagram and stage bounds | Identifies serial contributors and missing stages | One allocation row per stage and owner |
| Reserve policy and evidence revisions | Separates approved reserve from estimates | Reproducible total and open decisions |
Allocate 100 ms without hiding transport
Illustrative engineering example.
This fictional display path begins when the sensor detects a target and ends when the corresponding indication is visible. The 100 ms limit and proposed stage targets are illustrative; only the three named bounds have values. The proposed targets are not yet owner-approved.
Requirement: detection → visible indication ≤100 ms, nominal mode
Serial path: sensor → processing → transport → display
Known stage target candidates: 20 ms, 30 ms, TBD, 25 ms| Stage and owner | Proposed allocation | Current bound | Decision |
|---|---|---|---|
| Sensor / sensing owner | 20 ms | ≤18 ms, analysis | 2 ms local headroom on stated bound |
| Processing / software owner | 30 ms | ≤27 ms, estimate | 3 ms local headroom; confirm worst-case basis |
| Transport / bus owner | TBD | TBD | Must bound queuing and delivery |
| Display / display owner | 25 ms | ≤22 ms, vendor claim | 3 ms local headroom; verify configuration |
The known allocations add to 20 + 30 + 25 = 75 ms. The remaining 100 − 75 = 25 ms must cover transport and any separately approved reserve. It is not a measured 25 ms system margin. The known stage bounds sum to 18 + 27 + 22 = 67 ms only for the three represented stages; transport and any timing interactions remain unresolved.
The table is an allocation proposal rather than a review of an implemented bus. The transport owner needs an explicit bound under the same operating mode and percentile or worst-case definition. A 20 ms bus allocation, for example, would leave a proposed 5 ms reserve only after the owners accept that split; no such agreement is assumed here.
How to allocate the path
- Define the physical start and observable finish events, deadline direction, mode and source revision.
- Trace each serial or overlapping stage, including queues and shared resources, before assigning targets.
- Choose an aggregation rule; sum compatible serial worst-case bounds and identify any unknown term.
- Compare proposed allocations with current evidence and negotiate only the unresolved owner targets.
Questions about this task
Can I call unused allocation margin?
No. Allocation headroom is planning capacity; measured or justified performance margin requires a complete path under compatible conditions.
What if stages overlap?
Document the overlap and its scheduling evidence. Summing every duration may be conservative, but claiming a shorter total needs a justified timing model.
Sources and further reading
- NASA Systems Engineering Handbook: system design processes: Stakeholder expectations, logical decomposition, functional allocation and design decisions.
- NASA Systems Engineering Handbook: appendix: Terminology for budgets, margin and technical resources.