[spec] Nothing states when an event must be emitted, and that condition belongs to the licence #42

Specification section

5.7 Conformance levels, and 5.7.1 to 5.7.3

What you observed

Section 5.7 defines conformance as capability rather than coverage. Emitters "advertise a standard capability tier", "a level proves the emitter produces that event and everything below it", the levels "describe what an emitter reports", and the Citation level "proves citation support, not full retrieval-to-engagement coverage".

Every MUST in 5.7.1 to 5.7.3 is about the shape of an event once it is sent. Set source_role on content_retrieved events. Include at least one of content_url or content_id on every event. Emit content_grounded events with data.scope. These say what a valid event looks like. None of them says an event must be sent when the thing it records actually happens.

I looked for the vocabulary that would carry such a rule anywhere in the specification. "Obligation", "obliged", "eligible", "qualifying", "trigger" and "completeness" appear zero times across all 1,447 lines. "Applicable" appears twice, once in "a Citation emitter SHOULD emit them when applicable", and is not defined. The nearest thing to a rule is "emitters SHOULD produce the events that reflect what actually happened", which is a SHOULD about fidelity of ordering rather than a requirement to report.

The consequence is that an emitter which grounds a thousand pieces of content and sends one content_grounded event appears fully conformant at Grounding level. I cannot find the sentence it breaches.

Relatedly, the fourth conformance question in SCOPE.md asks whether "all qualifying events were reported". That phrase appears twice in the project, in this conformance question and in the README's open question on verification of grounding and citation, and is defined in neither place. The README asks for input on what a verification layer should cover and says mechanisms testing completeness are of particular interest, which is what this issue is about.

Why it matters

We need to settle how "qualifying" events is defined.

Everything downstream assumes coverage. Attribution, reporting and any commercial settlement computed from these events only mean something if the events are reasonably complete. A count of grounding events is not a measure of grounding, it is a measure of what an emitter chose to send.

The emitter is the only party that knows what it actually did. If the specification does not state the condition, the emitter sets it, and a content owner has no basis in the text to say the set was short. That asymmetry is not created by bad faith, it is created by silence.

It also means two honest implementers can read section 5.7, build very different things, and both conform. One emits per grounding, one emits per session, one emits per licensed domain only. Nothing in the text separates them, and nothing lets a consumer tell which they are looking at.

To be clear about the fix I am asking for, because it is not the obvious one. I am not asking the specification to state centrally when each event is owed. That runs into the same wall as defining centrally what each event means, which is that no single rule fits every licence, and it is the point I have raised in #4. The condition belongs in the licence, alongside the meaning.

What the specification needs to do is state that the event vocabulary is a shared set of names and loose descriptions, that the operative definition of what an event means and when it must be sent comes from the governing terms, and that the reference to those terms travels with the event so a reader can find which definition applied. That is a small change to section 5.7 and it costs the standard nothing it currently delivers, because section 5.7 already declines to require coverage. It would only be saying out loud what the text already does, and pointing at where the missing half lives.

The standard being silent on the matter is the one option that does not work, because silence defaults to whoever is sending it and their incentives.

Your perspective

Standards / policy