Arc Skills / Interfaces
Review a data interface specification
Matching field names and numeric types do not guarantee matching meaning. Arc Skills takes both message definitions and returns a semantic reconciliation that exposes conversion and state gaps.
Use this skill
Use Arc Skills to review my sender–receiver data Interface.
Inputs:
- Message definitions, protocol versions, example payloads and document revisions
- Field types, units, scaling, encoding, reference frames and allowed ranges
- Update rates, timestamps, invalid/duplicate and stale-message rules
Return a semantic field and protocol table with sample boundary checks, discrepancies and owner actions. Keep any proposed translation separate from the currently agreed wire contract.What you provide and what you get
| What you have | How it is used | What you get |
|---|---|---|
| Sender schema and payload | Shows transmitted representation and meaning | Field-side evidence |
| Receiver contract | Shows expected interpretation and state behavior | Semantic comparison |
| Timing and version rules | Tests stale/invalid handling beyond wire syntax | Open protocol and recovery findings |
Heading number has incompatible meaning
Illustrative engineering example.
The fictional sender reports 0° as north and increases clockwise. The receiver treats 0 rad as east and increases counterclockwise. Both transmit a floating-point number, but a raw 90 from the sender must not be interpreted as 90 radians. Assume both endpoint definitions specify the same horizontal reference plane.
Sender heading: degrees clockwise from north; example 90° = east
Receiver heading: radians counterclockwise from east; east = 0 rad
Proposed conversion domain: sender 0–360° maps modulo 2π
Sender update: 10 Hz nominal; receiver stale threshold: not specified| Field or protocol rule | Sender | Receiver | Finding |
|---|---|---|---|
| Heading unit | Degrees | Radians | Conversion required; same numeric type is insufficient |
| Heading origin and direction | North, clockwise | East, counterclockwise | For sample 90° east, converted receiver value is 0 rad |
| Update and age | 10 Hz nominal | No stale threshold stated | Cannot define timeout response |
| Protocol version | Version 2 in example | Version 2 expected | Syntax version aligns; semantics still conflict |
For this sample, a possible explicit mapping under that shared horizontal plane is receiver angle = (π/2 − sender angle in radians) modulo 2π. With sender 90°, π/2 − π/2 = 0 rad, as expected for east. That formula is a proposed transformation, not evidence that an adapter exists or that all boundary values, including wraparound at north/east, have been tested.
A 10 Hz nominal update does not by itself define how long the receiver may use the last value. The owners need a freshness threshold and behavior for a missed, duplicate or malformed message. Those rules determine whether the system keeps steering, flags invalid data or changes mode.
Review meaning before bytes
- Pin exact message and protocol revisions for both endpoints.
- Compare type, units, scale, reference frame, range, encoding and invalid values field by field.
- Run a boundary or orientation sample through both interpretations.
- Review update age, sequence and stale-message response as explicit contract behavior.
Questions about this task
Can the receiver simply convert units?
Only after both owners agree the full reference-frame mapping, range and boundary behavior, then verify the implementation.
Does a matching protocol version prove compatibility?
No. It may show framing agreement while field semantics or timing still disagree.
Sources and further reading
- NASA Systems Engineering Handbook: product realization: Interface definition, integration sequence and verification context.
- NIST Guide to the SI: Chapter 8: Physical units and the distinction between temperature values and intervals.