Failure And Ambiguity¶
A valid-looking decode can still be wrong.
Core Idea¶
Protocol inspection fails when field extraction is mistaken for truth. Checksums, parity, status bits, and parsers can prove limited structural facts. They do not prove that a value is fresh, semantically correct, physically true, or acted on by a controller.
Common Failure Modes¶
| Failure mode | Looks like | Better interpretation |
|---|---|---|
| Wrong dictionary | Plausible speed, pressure, altitude, state | Plausible false value until authority is verified |
| Stale data | Repeated valid value | Freshness hypothesis, not proof of stable state |
| Replay or buffering | Coherent sequence | Gateway/logging behavior may hide event time |
| Timing mismatch | Missing or late message | Sleep, bus load, schedule change, loss, or capture gap |
| Transport-vs-meaning confusion | Decoded frame or packet | Structure only; semantic source still required |
| Version mismatch | Decoder works but values drift | Database/profile may not match firmware or installation |
Visual Model¶
Observer Questions¶
- What assumption made this decode possible?
- Which authority assigns meaning?
- Could the value be stale, cached, replayed, or logged after the event?
- Does timing support the claimed state?
- What evidence would contradict this hypothesis?
Protocol Examples¶
CAN can carry valid bytes decoded with the wrong DBC. J1939 can expose a PGN while proprietary SPNs remain opaque. ARINC 429 can carry a valid label with an SSM that warns against using the data. MIL-STD-1553 can show a valid transaction whose data words are meaningless without RT maps. Modbus RTU can return valid registers whose engineering units come only from the device map. MDF can preserve samples while metadata controls the physical-value conversion.
Binder Rule¶
Every Tier 1 page must include Failure And Ambiguity. A page that cannot explain how interpretation fails is not ready to teach inspection.