Skip to content

Protocol Support Policy

Protocol support is tiered so the project can grow without becoming a protocol museum. Protocols must justify inclusion pedagogically.

Tier 1: Core Lab Scope

Core Lab is a curriculum and investment commitment, not a claim that every named surface is implemented today. A protocol can enter Core Lab scope before its runtime model, runnable example, or final-copy page exists. The maturity map is the authority for current runtime and page status.

Implemented Core Labs receive real code, explainability, tests, examples, docs, sample traces, and small simulations where practical. Planned Core Labs remain explicitly marked draft-core-lab and not yet available until those surfaces land.

Initial Core Labs:

  • Automotive: CAN, CAN FD, J1939, LIN, ISO-TP, UDS, OBD-II
  • Aviation and defense: ARINC 429, MIL-STD-1553, conceptual AFDX support
  • Serial foundations: UART, RS-232, RS-422, RS-485
  • Marine: NMEA 0183, limited NMEA 2000

Completed Core Lab implementations should include at least one decoder path, one explanation path, focused tests, clear limitations, and a route to a sample trace or lab.

Tier 2: Field Notes

Field Notes receive structured metadata, explainers, diagrams, references, and limited parsing where practical.

Examples include FlexRay, SENT, PSI5, CAN XL, ARINC 717, ARINC 629, ARINC 825, SpaceWire, TTEthernet, SOME/IP, DoIP, Modbus TCP and broader Modbus-family field notes, EtherCAT, PROFINET, CANopen, and MOST.

Field Notes should make source quality and implementation risk visible. They should not pretend to be complete protocol implementations.

Tier 3: Appendix And Metadata

Appendix protocols or standards are tracked primarily for historical context, citation completeness, taxonomy completeness, or future scoping.

Appendix entries may live only in atlas metadata and docs until a teaching use case justifies more.

Promotion Criteria

A protocol can move up a tier when it has:

  • a clear teaching hook
  • public or metadata-only canonical references
  • a safe synthetic example path
  • enough implementation scope to support .explain()
  • maintainable tests and documentation

Promotion does not require full conformance. It requires a better teaching surface.

Sample Expectations

Samples should tell operational stories such as cold start, braking event, hill climb, air-data descent, sensor failure, stale message, arbitration collision, or degraded bus.

Samples should prefer synthetic or redistributable data. A sample set should eventually include raw trace, decoded trace, README, expected state, and known anomalies.