Consolidate normative scope into Core: declaration acceptance moved from Discovery and Trust; Collection Profile and Discovery and Trust become informative

GOVERNANCE.md

@@ -210,6 +210,8 @@ A source enters the system as a published declaration of what it exposes: fields
 
 **Conformant Source.** The declaration validates against the PDPP schema. Anyone may publish one. The register records it as conformant and names the accountable party.
 
+A connector source conforms by producing a declaration that validates against Core §5 and serving its data through a resource server conforming to Core §8. No particular collection method is required.
+
 **Verified Source.** The declaration is published by the platform whose data it describes. The technical committee reviews the declaration for accuracy and completeness, confirms the publisher's identity against a recognised trust registry or by KYB-style check, and recommends. A Verified Source carries a verified tag and display priority: an authorization server presents it by default, with Conformant declarations for the same source reachable. Verified does not displace anything. Anyone remains free to publish and maintain a Conformant declaration for the same source, including one that exposes more.
 
 Existing grants remain bound to the declaration snapshot they were issued against and continue until expiry or revocation. Core §7 does not support grant narrowing, and no migration is forced.

README.md

@@ -14,21 +14,21 @@ reference implementation, and supporting documentation.
 
 The protocol is defined by the `spec-*.md` files at the repository root. Not
 every root spec carries the same authority: each file states its own status in
-a header near the top, and that header governs. Three of them are the normative
+a header near the top, and that header governs. One of them is the normative
 protocol; the rest are informative rationale, illustrative examples, or
 historical material superseded by the normative text. Where any downstream
 document, example, or superseded spec disagrees with the normative specs, the
 normative specs prevail.
 
 **Normative** — the protocol itself. Read these to implement PDPP:
 
-- [`spec-core.md`](spec-core.md) — core protocol: grants, sources, records, and the query surface (*Normative draft*). Core Section 8 is the authoritative definition of the resource-server query interface.
-- [`spec-discovery-and-trust.md`](spec-discovery-and-trust.md): source onboarding, provider-native discovery, authority, and accepted declaration revisions (*Companion specification draft*)
-- [`spec-collection-profile.md`](spec-collection-profile.md) — how a source is declared and collected; a companion profile to Core (*Companion profile draft*)
+- [`spec-core.md`](spec-core.md) — core protocol: grants, sources, records, and the query surface (*Normative draft*). Core Section 8 is the authoritative definition of the resource-server query interface, and Core Section 5 of declaration acceptance.
 
 **Informative** — rationale and context. These explain and situate the
 protocol but define no conformance requirements of their own:
 
+- [`spec-discovery-and-trust.md`](spec-discovery-and-trust.md) — implementation guidance for discovering and retrieving a declaration; the normative requirements live in Core Section 5 (*Informative*)
+- [`spec-collection-profile.md`](spec-collection-profile.md) — builder guidance for connector collection; not a conformance requirement (*Informative*)
 - [`spec-architecture.md`](spec-architecture.md) — the layered architecture and its boundaries (*Informative*)
 - [`spec-auth-design.md`](spec-auth-design.md) — authorization and consent design (*Informative*)
 - [`spec-connector-ecosystem.md`](spec-connector-ecosystem.md) — the connector model and runtime landscape (*Informative*)
@@ -80,11 +80,10 @@ are not the protocol boundary. The durable boundary between them lives in the
 
 This repository uses a strict authority order:
 
-1. **Root PDPP specs** (`spec-*.md`) define the protocol. The three normative
-   specs (`spec-core.md`, `spec-discovery-and-trust.md`, and
-   `spec-collection-profile.md`) define protocol
-   semantics; the other root specs are informative, illustrative, or
-   superseded, as each file's status header states.
+1. **Root PDPP specs** (`spec-*.md`) define the protocol. The normative spec
+   (`spec-core.md`) defines protocol semantics; the other root specs are
+   informative, illustrative, or superseded, as each file's status header
+   states.
 2. **Code and tests** define what the reference implementation actually does.
 3. **OpenSpec** (`openspec/`) defines project-level architecture and change
    planning.

apps/site-blume-spike/content/governance.md

@@ -213,6 +213,8 @@ A source enters the system as a published declaration of what it exposes: fields
 
 **Conformant Source.** The declaration validates against the PDPP schema. Anyone may publish one. The register records it as conformant and names the accountable party.
 
+A connector source conforms by producing a declaration that validates against Core §5 and serving its data through a resource server conforming to Core §8. No particular collection method is required.
+
 **Verified Source.** The declaration is published by the platform whose data it describes. The technical committee reviews the declaration for accuracy and completeness, confirms the publisher's identity against a recognised trust registry or by KYB-style check, and recommends. A Verified Source carries a verified tag and display priority: an authorization server presents it by default, with Conformant declarations for the same source reachable. Verified does not displace anything. Anyone remains free to publish and maintain a Conformant declaration for the same source, including one that exposes more.
 
 Existing grants remain bound to the declaration snapshot they were issued against and continue until expiry or revocation. Core §7 does not support grant narrowing, and no migration is forced.

apps/site/content/docs/index.mdx

@@ -7,11 +7,22 @@ These pages describe the **protocol**: what PDPP is, what it requires, and what
 
 ## Protocol
 
+The normative protocol is Core. Everything a conformant implementation must do
+is defined there.
+
+<Cards>
+  <Card title="Core Protocol" href="/specification" />
+  <Card title="Declaration Acceptance" href="/specification#declaration-acceptance" />
+  <Card title="Resource Server Interface" href="/specification#resource-server-interface" />
+</Cards>
+
+## Implementer guidance
+
+Informative. These define no conformance requirements.
+
 <Cards>
-  <Card title="Core Protocol" href="/docs/spec-core" />
-  <Card title="Resource Server Interface" href="/docs/spec-core#resource-server-interface" />
-  <Card title="Source Discovery and Trust" href="/docs/spec-discovery-and-trust" />
-  <Card title="Collection Profile" href="/docs/spec-collection-profile" />
+  <Card title="Source Discovery and Trust" href="/specification/spec-discovery-and-trust" />
+  <Card title="Collection Profile" href="/specification/spec-collection-profile" />
 </Cards>
 
 ## Reference implementation

apps/site/content/docs/meta.json

@@ -4,11 +4,12 @@
   "pages": [
     "---Specification---",
     "spec-core",
-    "spec-discovery-and-trust",
-    "spec-collection-profile",
     "spec-ext-lexical-search",
     "spec-ext-aggregation",
     "spec-semantic-retrieval-extension",
+    "---Implementer guidance---",
+    "spec-discovery-and-trust",
+    "spec-collection-profile",
     "spec-deferred",
     "open-questions",
     "---Programme---",

apps/site/spec-headers/spec-collection-profile.header.md

@@ -1,4 +1,8 @@
 ---
 title: "Collection Profile"
-description: "Companion to the Personal Data Portability Protocol (PDPP) core spec."
+description: "Informative builder guidance for connector collection. Not a conformance requirement."
 ---
+
+<Callout type="info" title="Informative">
+  Builder guidance for connector collection, not a conformance requirement. A connector conforms to PDPP by producing a source declaration valid under [Core Section 5](/specification#source-declaration) and serving its data through a resource server conforming to [Core Section 8](/specification#resource-server-interface). No particular collection method is required.
+</Callout>

apps/site/spec-headers/spec-discovery-and-trust.header.md

@@ -1,4 +1,8 @@
 ---
 title: "Discovery and Trust"
-description: "How an authorization server discovers, validates, and accepts PDPP source declarations."
+description: "Informative implementation guidance for discovering and retrieving a source declaration. The normative requirements live in Core Section 5."
 ---
+
+<Callout type="info" title="Informative">
+  Implementation guidance. This document defines no conformance requirements. The normative requirements for accepting a source declaration are in [Core Section 5, Declaration acceptance](/specification#declaration-acceptance).
+</Callout>

apps/site/src/components/specification/rail.tsx

@@ -56,17 +56,20 @@ function RailItem({ item }: { item: PageTree.Item }) {
   );
 }
 
-// The rail carries exactly two labels: "Specification" and "Programme". The
-// tree it renders holds the specification set and the programme documents (see
+// The rail carries exactly three labels: "Specification", "Implementer
+// guidance" and "Programme". The tree it renders holds the specification set,
+// the informative guidance documents and the programme documents (see
 // getSpecNavTree); any OTHER separator is still an empty divider — rendered as
 // a bare rule rather than a title, which keeps a stray tree entry from ever
 // reading as a rival section heading.
 //
 // "Programme" is a heading rather than more rows under "Specification" because
 // the two groups change by different routes: the specifications under the
 // Community Specification process, governance and the Principles by a vote of
-// Partners.
-const RAIL_SECTION_LABELS = new Set(["Specification", "Programme"]);
+// Partners. "Implementer guidance" is separate for a different reason: those
+// documents define no conformance requirements, and listing them beside the
+// normative core is what made readers treat their SHALLs as binding.
+const RAIL_SECTION_LABELS = new Set(["Specification", "Implementer guidance", "Programme"]);
 
 function RailSeparator({ item }: { item: PageTree.Separator }) {
   const label = typeof item.name === "string" ? item.name : "";

apps/site/src/lib/docs-source.ts

@@ -8,6 +8,7 @@ import { docs } from "../../.source/dynamic.ts";
 import {
   docsRoute,
   GOVERNANCE_SLUG,
+  GUIDANCE_SLUGS,
   governanceRoute,
   PRIMARY_SLUGS,
   PRINCIPLES_SLUG,
@@ -76,8 +77,14 @@ function programmeItems(byUrl: Map<string, PageTree.Item>): PageTree.Item[] {
 // see MAINTAINER_DOC_SLUGS.
 //
 // The separator names are load-bearing: components/specification/rail.tsx
-// renders "Specification" and "Programme" as the rail's two labels, and any
-// separator it does not recognise degrades to a bare rule.
+// renders "Specification", "Implementer guidance" and "Programme" as the
+// rail's three labels, and any separator it does not recognise degrades to a
+// bare rule.
+//
+// "Implementer guidance" exists so Discovery and Trust and the Collection
+// Profile are not read as part of the normative set. Both were listed beside
+// Core as companion specifications until the requirements for accepting a
+// declaration moved into Core §5; both are now informative.
 //
 // Governance sits under its OWN heading rather than as a seventh document in
 // the specification list. The six above are specifications under CSL-1.0 that
@@ -92,6 +99,8 @@ export function getSpecNavTree(): PageTree.Root {
     children: [
       { $id: "spec-rail-primary", name: "Specification", type: "separator" },
       ...pick(byUrl, PRIMARY_SLUGS),
+      { $id: "spec-rail-guidance", name: "Implementer guidance", type: "separator" },
+      ...pick(byUrl, GUIDANCE_SLUGS),
       { $id: "spec-rail-programme", name: "Programme", type: "separator" },
       ...programmeItems(byUrl),
     ],

apps/site/src/lib/spec-nav-slugs.ts

@@ -19,20 +19,30 @@ export const docsRoute = "/specification";
 // MAINTAINER_DOC_SLUGS.
 export const maintainersRoute = "/maintainers";
 
-// The specification IS the page. The rail lists the normative core, its
-// companion specification, and the three extension profiles — the whole of what
-// the protocol normatively defines, and nothing else.
+// The specification IS the page. The rail lists the normative core and the
+// three extension profiles — what the protocol defines, and nothing else.
+//
+// Discovery and Trust and the Collection Profile are NOT here. They were
+// listed as companion specifications until the normative requirements for
+// accepting a declaration moved into Core §5 Declaration acceptance; both are
+// now informative and sit under GUIDANCE_SLUGS below. Grouping an informative
+// document beside the normative core is the specific thing that made a reader
+// treat its SHALLs as conformance requirements.
 //
 // Order is the reading order of the specification set, not alphabetical.
 export const PRIMARY_SLUGS = [
   "spec-core",
-  "spec-discovery-and-trust",
-  "spec-collection-profile",
   "spec-ext-lexical-search",
   "spec-ext-aggregation",
   "spec-semantic-retrieval-extension",
 ] as const;
 
+// Informative implementer guidance, rendered under its own rail heading. These
+// define no conformance requirements: each states so in its own status header,
+// and the site copies carry an informative callout (see their header sidecars
+// in apps/site/spec-headers/).
+export const GUIDANCE_SLUGS = ["spec-discovery-and-trust", "spec-collection-profile"] as const;
+
 // Slugs sync-spec-docs.mjs generates from a root spec-*.md (that script's own
 // SPECS list). It writes these as .mdx — not .md — so each page's <Callout>
 // status banner parses as JSX instead of being dropped as a raw HTML block by

spec-collection-profile.md

@@ -1,10 +1,12 @@
 # PDPP Collection Profile v0.1.0
 
-Status: Companion profile draft
-Date: 2026-08-29
+Status: Informative. Builder guidance for connector collection. Not a conformance requirement.
+Date: 2026-09-02
 
 Companion to the Personal Data Portability Protocol (PDPP) core spec.
 
+A connector conforms to PDPP by producing a source declaration valid under Core §5 and serving its data through a resource server conforming to Core §8. No particular collection method is required.
+
 ---
 
 ## Overview