Semantic Authority¶
Bytes do not explain themselves.
Core Idea¶
A protocol artifact can prove that some structure was observed: an identifier, a label, a register address, a service ID, a payload length, a checksum, or a timestamp. It does not automatically prove the engineering meaning of those fields.
Semantic authority is the source that converts evidence into named meaning. It may be a DBC file, J1939DA-derived PGN/SPN definition, ARINC label table, Modbus register map, UDS DID catalog, LIN LDF, CANopen object dictionary, ARXML model, MDF channel metadata, or a validated vendor profile.
Authority Map¶
| Artifact | Field evidence | Semantic authority |
|---|---|---|
| CAN frame | ID, DLC, payload | DBC, J1939, CANopen, OEM convention |
| ARINC 429 word | label, SDI, data, SSM | label assignment and LRU/aircraft context |
| Modbus RTU frame | address, function, register offset | device register map |
| UDS message | service, DID, response | ISO service definition plus ECU DID catalog |
| MDF file | samples, channels, conversions | channel metadata and capture provenance |
Wrong Authority¶
Wrong authority is dangerous because it often looks successful. A decoder may output a realistic speed, pressure, altitude, or state string even when the source database belongs to a different platform or firmware version. The result is not random noise; it is a plausible false value.
Observer Rule¶
A passive observer may say:
I observed these bytes.
I decoded these fields under this framing hypothesis.
I applied this named authority.
Therefore this is a state hypothesis with this provenance.
The observer should not say:
The machine was definitely in this state.
unless the authority, timing, and provenance support that claim.
Binder Rule¶
Every semantic page must identify where meaning comes from, who defines it, what version or provenance is known, and what ambiguity remains. Pages that skip this step are not final-copy-ready.