Contributor Policy

This policy turns the project charter into review expectations.

Design Review

Contributions should prefer concrete protocol objects over speculative frameworks.

Use direct models for protocol facts first. Add shared abstractions only when several implemented protocols create real duplication or inconsistent behavior.

Avoid universal transport factories, plugin registries, hidden runtime magic, and framework-shaped code that obscures the protocol.

Use structural contracts for cross-protocol expectations. Major public objects should support explain() and show_fields(). Optional behaviors such as raw construction, raw export, arbitration, framing, transactions, signals, and observations should be advertised through the protocol catalog only when they are actually implemented.

New Tier 1 protocol code should add or update a protocol descriptor and at least one safe tutorial example factory.

Explainability Review

Major protocol objects should support .explain(). Explanations should be useful to a systems programmer who is learning the protocol.

Reviewers should ask:

• Does the explanation name the important fields?
• Does it explain what the fields mean?
• Does it identify simplifications or uncertainty?
• Does it avoid unexplained acronyms?
• Does it avoid claiming conformance that the code does not provide?

Source Review

Protocol details should be grounded in public references, open-source tools, or clearly identified pedagogical simplifications.

Do not copy text from paywalled standards. Do not add proprietary captures, vendor IP, or scraped non-redistributable material.

When a contribution changes protocol scope, update the relevant documentation, catalog entry, source notes, and support posture.

Safety Review

Contributions must not add unsafe operational attack tooling, unauthorized manipulation guidance, or examples that transmit against real systems.

Allowed security-oriented work should stay focused on passive observation, synthetic lab traces, stale or impossible state, replay concepts, and threat-model explanation.

Tutorial examples must be deterministic, synthetic, and harmless. They should teach a shape or invariant without implying that they are captures from a real vehicle, aircraft, vessel, industrial system, or embedded target.

Test And Documentation Review

Code changes should include tests proportional to risk. Protocol parsing should test field extraction, boundary values, bit ordering, parity, checksums, arbitration, transactions, or explanations as applicable.

Docs changes should preserve the protocol taxonomy and source policy. New Tier 1 protocol work should include a path to examples, labs, and sample traces.

Advisory GitHub Workflow

GitHub templates and labels are advisory. They guide review and scope control but do not replace engineering judgment or the just ci gate.