Arc Skills / Interfaces
Define an interface between two systems
Interface definition establishes what crosses a chosen boundary before document detail is drafted. Arc Skills takes endpoint Systems and intended exchanges and returns one proposed Interface summary plus specific owner questions.
Use this skill
Use Arc Skills to define the Interface between my two named Systems.
Inputs:
- Actual endpoint boundaries, owners, and source Requirements
- Each exchanged item with producer, consumer, purpose, mode and direction
- Known failure, startup or degraded behavior and unresolved parameter owners
Return one Interface proposal for the System pair plus an exchange table and open decisions. Do not create a duplicate reverse relationship or invent undocumented rate, connector or message details.What you provide and what you get
| What you have | How it is used | What you get |
|---|---|---|
| Endpoint Systems | Fixes the actual boundary and pair | One proposed Interface relationship |
| Exchange evidence | Names producer, consumer, item and mode | Directional exchange table |
| Requirements and owner decisions | Links need and exposes unknown authority | Open questions without invented parameters |
Payload and recorder exchange in two directions
Illustrative engineering example.
This illustrative pair contains a payload that generates image frames and a recorder that grants capture enable. Both exchanges cross the same two-System boundary; the rate authority is not yet agreed.
Payload → Recorder: image frames in Capture mode
Recorder → Payload: capture-enable control
Frame-rate owner: unresolved between two source drafts| Exchange | Producer → consumer | Purpose and mode | Open detail |
|---|---|---|---|
| Image frames | Payload → recorder | Store accepted frames during Capture | Frame format and allowed rate TBD |
| Capture-enable | Recorder → payload | Permit frame production when ready | Startup and denial behavior TBD |
| Frame-rate authority | Either owner claimed in drafts | Changes pacing in Capture mode | Owners must agree before assigning control |
| Relationship summary | Payload ↔ recorder | One bidirectional Interface; exchanged items described | Proposal, not approved baseline |
The two exchanges belong to one relationship between the unordered System pair. Its scalar summary can say bidirectional and name the pair, while the description or controlled document carries direction for each exchange. A second reverse Interface would duplicate the same pair and create competing records.
This page stops at defining the exchange and ownership. It does not invent message encoding, frame-rate numbers or a released ICD. Those details can be written once the payload and recorder owners agree who controls pacing and what happens when capture is denied.
Define the crossing first
- Confirm both endpoints are Systems and each exchange truly crosses their chosen boundary.
- For every item, record producer, consumer, purpose, mode and expected response.
- Group opposite directions under the same pair and link source requirements.
- Give unresolved rates, formats and authority to named owners for later control.
Questions about this task
Does bidirectional mean every item travels both ways?
No. It summarizes the relationship; each exchange still needs its own explicit direction.
When should I write an ICD?
After the basic exchange and owners are agreed enough to control detailed parameters, revisions and verification.
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.