GR1 verdict — normative adoption

This page records why SOVM-SYNC-RT §6 marks GR1 closed. It is a record of evidence, not part of the specification: it adds no requirement, and the gate’s text on the module page is what it answers to.

GR1 is an editorial gate, not an empirical one. A conformance module defines no bytes, so there is nothing to measure. What the gate asks is whether SSP/1 itself states what the module needs it to state. The evidence is therefore text, not a test run, and an outsider can check every line of this page by reading the published pages it cites.

1. The gate

The gate as the module page states it, with the state markers it carries since closing:

GR1  normative adoption                                          CLOSED
     (a) CLOSED: SSP/1 states the conformance clause as core plus the
         modules an implementation claims, naming SOVM-SYNC-RT
     (b) CLOSED: SSP/1 carries section 3.2's honest-advertisement
         requirement in the handshake section and the fail-closed
         inventory

The gate exists because the module page is not an amendment and cannot become one. Whatever binds an implementation has to be stated in SSP/1, where a reader who never opens the module page still meets it.

2. Where the evidence was read

• Commit. 0d29ccca6c05d3c6ca013d44909db6e8d48957f2, on develop. Every passage named below reads as quoted at that commit. The same passages read identically on main at 5b88ec17fe80fcf9f1dde5c74f619a5f78660fb7.
• Run. None. The evidence is the SSP/1 text in section 3, so there is no run to cite.

3. The conjuncts, and the text that carries each

Conjunct	Where SSP/1 carries it
(a) conformance is core plus the modules an implementation claims	Registry §55: “Conformance is core, plus the modules you claim.” §55.1 item 8 obliges every implementation to state its module set by identifier
(a) the clause names SOVM-SYNC-RT	Registry §55.2 has a row for SOVM-SYNC-RT with both halves. Claiming it means implementing realtime mode in full and answering supports_realtime true only where that is true. Omitting it means answering supports_realtime: false, answered and not withheld, and running every session in batch mode
(b) the honest-advertisement requirement, in the handshake section	Messages §33: the advertisement itself is bound. An implementation may advertise supports_realtime: true only where SOVM-SYNC-RT is in its stated module set and the session’s binding can carry peer-initiated one-way bodies, and advertises false otherwise. The same section obliges an omitting implementation to still emit and parse the member and still reject an unsolicited body
(b) the honest-advertisement requirement, in the fail-closed inventory	Limits §35 carries two rows. One is supports_realtime: true about to be advertised by an implementation that does not claim SOVM-SYNC-RT, or on a binding that cannot carry unsolicited one-way bodies: advertise false. The other is an unsolicited push without mutual supports_realtime: reject
negative control on (b)	Each row of limits §35 is a join key into the conformance vectors: the cases ssp.limits.fail_closed.realtime_advertised_without_capability and ssp.limits.fail_closed.unsolicited_push_without_mutual_realtime carry those two conditions verbatim. The conformance harness fails when the inventory and its transcription disagree, so the rows cannot be removed or reworded without the build noticing

Module §3.2 is the requirement that conjunct (b) asks SSP/1 to carry. Its first item, advertise false in every handshake, is the rule in messages §33 and the first of the two rows in limits §35. Its second and third items, never push and always reject an unsolicited body, are rules in messages §33 and the second of those rows.

4. The rulings that interpreted the gate

“The handshake section” is read as messages §33, not messages §31. The capability handshake’s member table is in messages §31, but the rule that binds the advertisement is in messages §33, the section that defines realtime mode. The gate asks where a reader meets the obligation, and a reader of the capability meets it in messages §33. Registry §55.2 links messages §31 for the same obligation, and both sections are on the same page.

The gate closes on its own text. GR1 closed by itself, while GR2 and GR3 stay open. This follows the rule SOVM/1’s other gated pages already apply: a gate closes when its own text is satisfied, not when all of its siblings are.

5. What the evidence does not show

GR1 shows that SSP/1 states the obligations. It does not show that any implementation meets them. It says nothing about interoperability between a claiming node and an omitting node (GR2), and nothing about whether a false claim is caught (GR3). The conformance corpus has no cases in SOVM-SYNC-RT’s own partition yet. The two rows in limits §35 execute under SOVM-SYNC, because the inventory is tier 1 in full.

6. Reproducibility

Anyone can check this verdict today by reading the passages in section 3 against the gate’s text. It depends on no unreleased code. That makes it different from the other verdicts in this section, which record test runs an outsider cannot yet re-run. The negative control in the last row of section 3 is the one exception: the harness it names lives in the unreleased workspace, so the control is a record, not a check, until that workspace is released.