The Testable Model: Format, Parser, and Oracle

SPAR’s Babel example has established two facts that need to be held together: packet validity depends on relationships among fields, and an implementation can fail by accepting a relationship the RFC forbids. This checkpoint turns those facts into one operational model. The useful judgment is not simply that a semantic bug exists, but that a tester can state the expected behavior, construct a packet that probes it, and distinguish disagreement among the formal description, a reference parser, and the implementation under test.

One contract, two deliberate tests

A semantic protocol test begins with a contract. In the Babel Update case, the contract includes the condition that AE = 3 requires Omitted = 0, along with the related conditions that determine how Prefix data is interpreted and sized. The contract says which combinations belong to the protocol’s language and which do not.

From that contract come two complementary test cases. A positive packet satisfies the relevant structure and constraints. It should be accepted by a parser that implements the model. A negative packet preserves as much of the same structure as possible while violating one selected constraint. In the Babel example, a candidate with the special address encoding and a nonzero omitted-byte count is negative because it breaks that specific relationship.

The distinction gives each test a clear expected outcome. A positive packet being rejected signals a mismatch between the packet model and the parser’s behavior. A targeted negative packet being accepted signals that the parser or the model has failed to enforce, or correctly state, the selected rule. Neither observation identifies the cause by itself. That is the point of the model: it makes the disagreement visible and narrow enough to investigate.

The implementation under test adds a third observation. The reference model may say that a packet should be rejected, while a deployed parser accepts it. In that situation, the implementation has not met the semantic contract as represented by the test. The result is stronger than “the input was strange” because the test names the relationship that gives the input its expected meaning.

flowchart LR C["Semantic contract"] --> P["Positive packet"] C --> N["Targeted negative packet"] P --> PE["Expected acceptance"] N --> NE["Expected rejection"] P --> R["Reference parser"] N --> R R --> O{"Observed behavior"} O --> M["Mismatch to investigate"] PE --> O NE --> O M --> Q["Review format, parser, RFC context, or implementation"]

This is the smallest complete model of a semantic protocol test: a stated invariant, an input that satisfies or challenges it, an expected outcome, and an observed outcome that can be compared with that expectation. It is small enough to apply to a single Babel field relationship and general enough to organize SPAR’s larger workflow.

Three artifacts, three failure surfaces

The model becomes more useful when the sources of evidence are kept separate. The RFC is the normative source for the protocol rule. The formal format is a structured interpretation of that source. The reference parser is an executable interpretation. The deployed implementation is the system whose conformance matters. These are related artifacts, but they do not answer the same question and should not be collapsed into one “truth” object.

The formal format owns the explicit statement of the contract.