Strip process narration; pre-announcement review fixes

.github/ISSUE_TEMPLATE/spec-feedback.yml

@@ -6,14 +6,13 @@ body:
   - type: markdown
     attributes:
       value: |
-        The formal v1 public comment period closed on 24 July 2026. This template
-        remains available for questions, unclear or contradictory requirements,
+        Use this for questions, unclear or contradictory requirements,
         implementation evidence, and gaps in the specification as written.
 
         For a new capability or change in behaviour, submit a short human-written
         note to [proposals/](../tree/main/proposals) instead. Please wait for
         explicit maintainer alignment before beginning implementation. New
-        proposals are not automatically part of the v1 scope.
+        proposals are not automatically accepted into a 1.x release.
 
         For a concrete bug in a schema file or a worked example, use the
         **Schema or example bug** template instead.

CODE_OF_CONDUCT.md

@@ -1,5 +1,5 @@
 # Code of conduct
 
-Participation in this project - issues, pull requests, and the public comment process - is expected to be professional and respectful. Critique ideas, not people. Harassment, personal attacks, and bad-faith disruption are not tolerated.
+Participation in this project - issues, pull requests, and proposals - is expected to be professional and respectful. Critique ideas, not people. Harassment, personal attacks, and bad-faith disruption are not tolerated.
 
 The maintainer may edit, lock, or remove contributions that breach this, and may block repeat offenders. To report a problem, email alex@spurcoalition.org.

CONTRIBUTING.md

@@ -10,8 +10,11 @@ This repo contains the **specification** - the data model, event types, privacy
 | [telemetry-session.json](./telemetry-session.json) | JSON Schema for session validation |
 | [telemetry-event.json](./telemetry-event.json) | JSON Schema for standalone event validation |
 | [telemetry-event-batch.json](./telemetry-event-batch.json) | JSON Schema for event batch validation |
+| [manifest.json](./manifest.json) | JSON Schema for the well-known manifest |
+| [SCOPE.md](./SCOPE.md) | The boundary between core, profiles and governing terms |
+| [proposals/](./proposals/) | Human-written proposals for new capabilities |
 | [tests/](./tests/) | Conformance test suite |
-| [GOVERNANCE.md](./GOVERNANCE.md) | Stewardship and preview-status policy |
+| [GOVERNANCE.md](./GOVERNANCE.md) | Stewardship, versioning status, relationship to profiles |
 | [LICENSE](./LICENSE) | Apache License 2.0 |
 
 ## Proposing changes
@@ -75,13 +78,14 @@ implementation pull request should:
 From a clean checkout, with no setup beyond [uv](https://docs.astral.sh/uv/):
 
 ```sh
-uv run --with jsonschema python tests/validate.py        # conformance suite
-uv run --with jsonschema python tests/check_examples.py  # examples in the spec validate against the schemas
+uv run --with "jsonschema[format-nongpl]" python tests/validate.py        # conformance suite
+uv run --with "jsonschema[format-nongpl]" python tests/check_examples.py  # examples in the spec validate against the schemas
+uv run --with "jsonschema[format-nongpl]" python tests/mutation_smoke.py  # suite-weakening mutations are caught
 ```
 
-(Without uv: `pip install jsonschema` then `python3 tests/validate.py`.)
+(Without uv: `pip install "jsonschema[format-nongpl]"` then `python3 tests/validate.py`.)
 
-`check_examples.py` validates every complete worked example in SPECIFICATION.md and README.md against its schema; an example that no longer matches its schema fails the build. Both commands run in CI on every pull request (`.github/workflows/ci.yml`).
+`check_examples.py` validates every complete worked example in SPECIFICATION.md and README.md against its schema; an example that no longer matches its schema fails the build. All three commands run in CI on every pull request (`.github/workflows/ci.yml`).
 
 ## Conformance levels
 

GOVERNANCE.md

@@ -16,24 +16,22 @@ The SPUR Coalition stewards the specification and holds this repository. The sta
 
 ## Who the SPUR Coalition is
 
-The SPUR Coalition is a group of publishers and content owners that maintains the Content Telemetry standard. It holds the intellectual property through the preview period and releases the standard under Apache 2.0 from 12 June 2026.
+The SPUR Coalition is a group of publishers and content owners that maintains the Content Telemetry standard and releases it under Apache 2.0.
 
-Contributing to the standard does not require membership. The wire format is developed in the open, and anyone - content owner, agent operator, intermediary, or implementer - can take part through the issue tracker and the process described in the [README](./README.md#consultation-record).
+Contributing to the standard does not require membership. The wire format is developed in the open, and anyone - content owner, agent operator, intermediary, or implementer - can take part through the issue tracker and the process described in the [README](./README.md#feedback).
 
 The standard is maintained by Alex Springer (alex@spurcoalition.org).
 
-## Version 1.0 and decisions
-
-The specification reached 1.0 on 2 September 2026, following the public consultation of 12 June to 24 July 2026 and the release-candidate work recorded on the issue tracker.
+## Decisions
 
 Decisions follow the proposal and alignment process in [CONTRIBUTING.md](./CONTRIBUTING.md): anyone may propose a change, a maintainer records the disposition publicly on the issue tracker, and the SPUR Steering Board approves releases. The tracker and pull-request history are the public decision record. Minor versions add optional fields and event types; breaking changes require a major version (SPECIFICATION.md section 12).
 
 ## How to participate
 
 - File questions and bugs on the [issue tracker](https://github.com/SPUR-Coalition/telemetry/issues) (see the templates).
-- See the [consultation record](./README.md#consultation-record). The formal
-  v1 comment window is closed, but concrete bugs and implementation evidence
-  remain welcome on the issue tracker.
+- The issue tracker and pull-request history are the public decision record
+  (see the [README](./README.md#feedback)); concrete bugs and implementation
+  evidence are always welcome.
 - Propose new capabilities or changes in behaviour as a short human-written note
   in [`proposals/`](./proposals/), following
   [CONTRIBUTING.md](./CONTRIBUTING.md).

README.md

@@ -2,7 +2,7 @@
 
 **Signal format for AI content usage reporting.**
 
-**Version 1.0** is the current specification, published 2 September 2026. It replaces the v0.1 preview; the changes and migration steps are recorded in [SPECIFICATION.md section 12.1](./SPECIFICATION.md#121-migration-from-the-v01-preview).
+**Version 1.0** is the current specification. Migration from the v0.1 preview is recorded in [SPECIFICATION.md section 12.1](./SPECIFICATION.md#121-migration-from-the-v01-preview).
 
 ## Contents
 
@@ -12,7 +12,7 @@
 - [Repo contents](#repo-contents)
 - [Example](#example)
 - [Relationship to other protocols](#relationship-to-other-protocols)
-- [Consultation record](#consultation-record)
+- [Feedback](#feedback)
 - [Open questions in v1](#open-questions-in-v1)
 - [Versioning](#versioning)
 
@@ -40,7 +40,8 @@ The gaps between stages show how content was used:
 
 - **Retrieval without grounding** - your content was fetched but not used
 - **Grounding without citation** - your content influenced the answer but you got no credit
-- **Citation without engagement** - your content was cited but the user didn't click through
+- **Citation without presentation** - your content was credited in the output but the credit never reached the user
+- **Presentation without engagement** - your link was shown but the user didn't click through
 
 The grounding event captures the boundary "this content entered the agent's generation context." It is architecture-neutral and decoupled from retrieval: content cached by the agent for days still produces a grounding event in every session it influences.
 
@@ -152,30 +153,23 @@ The content owner can derive: FT article `abc123` was in context for the respons
 
 Content Telemetry is focussed on **reporting**, while content **access** protocols (Really Simple Licensing, peek-then-pay, IAB CoMP, bilateral APIs) aim to govern how agents discover and license content. The `license_ref` field on events connects telemetry to whatever access protocol issued the licence, but the schemas are independent - telemetry works with any access protocol, or none.
 
-## Consultation record
+## Feedback
 
-The public comment period ran from **12 June to 24 July 2026**. Thank you to
-everyone who opened an issue, submitted a pull request, joined a working
-session or supplied implementation evidence.
-
-The consultation produced 29 specification issue threads, three profile issue
-threads and five pull requests. Every thread carries a recorded outcome, and
-the issue tracker and pull-request history remain the public decision record.
-The accepted core changes were tracked on the
-[v1 release candidate milestone](https://github.com/SPUR-Coalition/telemetry/milestone/1),
-merged on the `v1-draft` integration line, and published as version 1.0 on
-2 September 2026.
-
-Concrete schema, fixture and documentation bugs may be filed using the
-*Schema or example bug* template, and questions or unclear requirements using
-*Spec feedback / open question*. For a new capability or change in behaviour,
-submit a short human-written note to [`proposals/`](./proposals/) and wait for
+File concrete schema, fixture and documentation bugs with the *Schema or
+example bug* template, and questions or unclear requirements with *Spec
+feedback / open question*. For a new capability or change in behaviour, submit
+a short human-written note to [`proposals/`](./proposals/) and wait for
 explicit maintainer alignment before beginning implementation (see
-[CONTRIBUTING.md](./CONTRIBUTING.md)). Pull requests remain welcome for
-specific fixes. Feedback on accreditation or the conformance mark belongs on
-the [profile
+[CONTRIBUTING.md](./CONTRIBUTING.md)). Pull requests are welcome for specific
+fixes. Feedback on accreditation or the conformance mark belongs on the
+[profile
 repository](https://github.com/SPUR-Coalition/telemetry-profile/issues).
 
+The [issue tracker](https://github.com/SPUR-Coalition/telemetry/issues) and
+pull-request history are the public decision record, including the v1
+consultation (12 June - 24 July 2026) and the
+[v1 release candidate milestone](https://github.com/SPUR-Coalition/telemetry/milestone/1).
+
 ## Open questions in v1
 
 The following areas are expected to develop in 1.x minor versions and profiles, with implementer input:
@@ -184,7 +178,7 @@ The following areas are expected to develop in 1.x minor versions and profiles,
 
 **Event volume at scale.** A single deep-research query can produce 100+ retrieval events and dozens of grounding/citation events. The session document format already handles transport - one POST with all events after the session ends, not one request per event. Volume management beyond that (storage, processing, consumer-side aggregation) is an implementation concern, not a protocol gap. Version 1 adds an explicit coverage declaration - `complete`, `sampled`, `aggregated` or `selected` (section 5.7.6) - and a manifest field for it (section 8.5); the standard still sets no default for reporting granularity, leaving it to profiles and deployments.
 
-**Verification of grounding and citation.** Grounding and citation events are reported by the agent, which is also the party that may owe compensation under a licence. In v1, manifest signing is informational: consumers may verify signatures but are not required to, and the specification defines no required proof binding an event to its emitter (sections 8.4 and 8.9). The events attribution depends on are therefore self-reported by the reporting party. Verifiable credentials and signed events are deferred (section 8.9). One corroboration mechanism works without signing: the `Content-Telemetry-ID` field correlates an agent-reported retrieval with an origin- or edge-reported one (section 7.2), but it covers retrieval only - grounding, citation, presentation, and engagement have no independent observer. Signing, even once required, would prove who reported an event, not that the event is true or that all qualifying events were reported. Input is wanted on what a verification layer should cover and where it belongs. Mechanisms that test truthfulness and completeness rather than origin, such as sampled audits or publisher-seeded canary content, are of particular interest.
+**Verification of grounding and citation.** Grounding and citation events are reported by the agent, which is also the party that may owe compensation under a licence. In v1, manifest signing is informational: consumers may verify signatures but are not required to, and the specification defines no required proof binding an event to its emitter (sections 8.4 and 8.9). The events attribution depends on are therefore self-reported by the reporting party. Verifiable credentials and signed events are deferred (section 8.9). One corroboration mechanism works without signing: the `Content-Telemetry-ID` header correlates an agent-reported retrieval with an origin- or edge-reported one (section 7.2), but it covers retrieval only - grounding, citation, presentation, and engagement have no independent observer. Signing, even once required, would prove who reported an event, not that the event is true or that all qualifying events were reported. Input is wanted on what a verification layer should cover and where it belongs. Mechanisms that test truthfulness and completeness rather than origin, such as sampled audits or publisher-seeded canary content, are of particular interest.
 
 **Reporting granularity.** The standard sets no default for reporting granularity, leaving it to profiles and deployments (see *Event volume* above). The SPUR profile requires event-level delivery and does not permit aggregation. Version 1 answers the first half of the question: coverage modes are defined once, in section 5.7.6, so that profiles reference them rather than each define their own. How event-level delivery scales for the highest-volume case remains open.
 

SCOPE.md

@@ -26,4 +26,4 @@ An implementation uses the core schema and specification, a small profile bundle
 
 For example, an operator could choose a SPUR advertising deployment recipe and supply the publisher endpoints and commercial requirements. The SDK or collector would resolve the required delivery, advertising and evidence capabilities at startup. The agent would then emit ordinary lifecycle events; the collector would route publisher reports and send relevant evidence to the configured verification service. The developer would not select profiles or negotiate capabilities inside each agent turn.
 
-The closed consultation feeds a v1 release candidate rather than an intermediate v0.2 release. Compatibility with a mistake in the preview version is not a constraint. A breaking change is acceptable when it makes v1 easier to implement. It must include migration notes and replacement fixtures, and must not silently change meaning within an existing version.
+Breaking changes follow the versioning policy in SPECIFICATION.md section 12: they require a major version, migration notes and replacement fixtures, and meaning never changes silently within an existing version.