governance: final consultation draft, two-level status model

[artvana]

Final consultation draft. Two-level status model (Conformant automated, Verified reviewed). Steward removed. Partner requires Verified. Technical committee recommends; steering committee changes the specification and grants; Chair merges. Phase 2: maintainers merge on recommendation, no discretion. Source declarations: update rights restricted to submitter or listed maintainers, automated check on every version, committee may recommend archival of unused declarations with published threshold and 30 days' notice.

Replaces the root GOVERNANCE.md in full. This PR opened as the Steward removal alone; the final draft supersedes and contains it.

Carried forward from #267

The supplied draft predated #267, so three edits already on main were re-applied on top of it rather than reverted:

• §2's unnumbered Pre row and the "four stages" wording
• 3. Full rather than 3. Elected
• §0's sentence recording that the Vana Foundation started the project and that PDPP is a community specification owned, governed and managed by the community

§5.7's "until PDP-Connect holds a legal home" was already present in the new draft.

Stale references

Grepped the repo and site source for Official Source, Steward, recognition route, Identified, board and committee decides.

• apps/site-blume-spike/content/governance.md — generated from the root document by that spike's own scripts/sync-canonical-content.mjs, and stale at the pre-consultation draft, so it still carried the board, Official Source, Steward and the recognition route. Regenerated. Its two stale specification copies are the same generator's output but a separate drift, and are left alone.
• recognition route and a status named Identified appear nowhere in the repo. The Identified grep hits are the TypeScript type names IdentifiedAction and IdentifiedTargetRegistrationInput in the reference implementation.
• committee decides survives twice in GOVERNANCE.md, both correct under the new model: "the steering committee decides on the recommendation by majority vote and the Chair merges".
• Steward survives once per copy, as §1.1's LF Decentralized Trust Labs Stewards — a different body, which approves entry to the Labs programme.
• board and Official Source survive only in docs/community/working-sessions/2026-08-26-session-4-governance-membership-conformance.md, dated minutes recording what was discussed at that session. Left as the historical record.

The site renders GOVERNANCE.md rather than restating it, so no site copy named the statuses or the bodies.

Source declarations: update rights and archival

• §5.5 "Who may update a declaration." A declaration may be updated only by the account that submitted it or one listed in the declaration's own maintainers field; a pull request from any other account is returned at the admissions check. Every new version passes the automated check whatever status level it carries, and a Verified declaration whose new version widens scope returns to review under §5.8.
• §5.5 "Archival." The technical committee may recommend archiving a declaration with low or no usage, against a threshold and measurement published before any archival is proposed, with the accountable party notified and given 30 days to respond first. Archival merges by the same route as any other register change. An archived declaration stays readable, is marked archived, is not presented by default by an authorization server, and does not affect grants already issued against it; the accountable party reinstates it by submitting a new version.
• §5.8 Change restated to match: every version passes the automated check before publication, and widening scope is what additionally returns through the route by which the status was obtained.
• Appendix A item 8a puts the submitter check at the step that actually returns submissions, rather than leaving it stated only in §5.5.

apps/site-blume-spike/content/governance.md is regenerated from the root document in the same series, so the spike copy does not drift again.

Note on rendering: 8a. is not a valid CommonMark ordered-list marker (the marker must be digits followed by . or )), so it renders as a paragraph directly under item 8 rather than as an indented list item. The text reads as intended. Say the word if you would rather it were indented as a continuation of item 8, or renumbered so the list carries it.

Checks

spec:check passes. pnpm --dir apps/site types:check, test (202 passed, 0 failed), check (0 errors; the 4 suppressions/unused warnings are pre-existing) and build all pass, with /governance and /principles prerendering. The sync-spec-docs header parser reads the new draft's status block unchanged — the labels are the same — and src/generated/spec-front-matter.ts still resolves the governance rail card.

Verified on the served production build that /governance returns 200 and renders no Official Source, no recognition and no Identified; that Conformant, the Partner-requires-Verified rule, "Chair merges" and the phase-2 no-discretion clause are all present; and that the Pre row, "four stages", 3. Full and the §0 sentence survived the replacement.

Assisted-by: AI

🤖 Generated with Claude Code

https://claude.ai/code/session_01NECjjZbYWNTzq3bu7nuiDP

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
pdpp	Ready	Preview	Sep 2, 2026 3:02pm UTC

[artvana]

@tnunamak @annakaz — three PRs are open and they interlock. Review in this order, please.

1. #279, governance final consultation draft

Replaces GOVERNANCE.md in full with the final consultation draft.

• Status becomes two levels: Conformant is automated (admissions check plus schema validation, no human judgement) and confers no membership; Verified is reviewed.
• Steward is gone. Membership is Supporter and Partner, and Partner now requires a Verified status rather than any status.
• Official Source and the recognition route are gone.
• Authority is stated the same way throughout: the technical committee reviews pull requests and recommends and merges nothing; the steering committee changes the specification and grants status by majority vote; the Chair merges. In phase 2 the maintainers merge on the committee's adopted recommendation with no discretion.
• §5.5 gains update rights for source declarations (only the submitting account or one listed in the declaration's maintainers field) and an archival route for unused declarations, with a published threshold and 30 days' notice.
• §2 keeps the unnumbered Pre stage and 3. Full, and §0 keeps the sentence recording that the Vana Foundation started the project and that PDPP is a community specification. The supplied draft predated those, so they were re-applied on top rather than reverted.

2. #283, consolidate normative scope into Core

Stacked on #279's branch, so it needs #279 first. Retarget it at main if you would rather take them separately.

• Core §5 gains Declaration acceptance, which states in RFC 2119 terms what previously lived only in Discovery and Trust: how a declaration may be accepted, the provider_native identifier rule, publisher.id being an unauthenticated claim, equivocation on an accepted key, and the retrieval rules (HTTPS, no ambient credentials, size/time/redirect limits, fresh DNS, no remote schema, fail closed).
• Discovery and Trust and the Collection Profile become informative. Discovery and Trust loses its RFC 2119 keyword paragraph. Core is now the only normative PDPP document, and its Requirements Language section says so.
• Two lines in Core contradicted the demotion and are fixed with it: the Collection Profile no longer "uses the same requirements language" and no longer "standardizes" the collection bridge.
• The site groups both under "Implementer guidance, informative" rather than beside Core.

One thing to look at: Discovery and Trust keeps its SHALL/MUST wording, per the brief to leave the content intact. With the keyword paragraph gone those words no longer have a defined meaning in that document. Worth a follow-up pass before the lock if you agree.

3. #313, the new site

Independent of the other two on the branch graph, but coupled in content: /specification renders the repo-root GOVERNANCE.md, so #279's text lands on the site the moment it merges. Until then that section still shows Official Source and Steward.

Seven routes on the four-intent structure: /, /principles, /specification, /build, /participate, /review, /privacy, with /governance redirecting to the governance anchor of /specification. Built from the design handoff, now committed at design_handoff_pdpp_site/.

• /principles and /specification render PRINCIPLES.md and GOVERNANCE.md from the repo. Nothing is retyped in site source; the generator throws unless exactly six principles parse.
• Interim Supporter signing is written but behind signingLive, default off, and none of it has run. There is no KV store, no mail provider and no deploy key yet. Every external seam fails closed rather than degrading.
• The private signatory repository is not created. It holds personal data and its settings need org rights I do not have. The README, publish and export scripts, scheduled workflow and a settings checklist are staged outside the repo, ready to push to PDP-Connect/supporters-private. docs/registers.md documents the three stores, the one-way data flow and the handover and deletion procedure.
• Conformance registers ship as /register/index.json (empty) and /register/trust-registries.json (the DTI Data Trust Registry), both PR-driven and holding no personal data, with apply templates for the three roles.

The PR body lists every config value still on a placeholder. Each one renders as a visible bracketed placeholder until set, so nothing guessed ships as fact. The two that need a decision from us are the interim controller name and the general contact address.

Where the prototype and the design export disagreed, the resolutions are listed in the PR body. The one worth a second opinion: /build's copy cited Core by section number throughout, and the brief removes section citations from site copy outside the reader and /review, so the links are named rather than numbered ("Source declaration" rather than "Core §5") and still land on the same anchors.

Checks

All three pass spec:check, types:check, test, check and build. Note pnpm check already fails on main with 20 pre-existing errors; #313 fixes five of them as a side effect of touching those files.

[tnunamak]

Superseded by #285, merged to main as 99fcca3. This PR's commits were carried into that stack with authorship preserved (as #307 for the governance model and #308 for the normative-scope consolidation), with the follow-on changes recorded in the stack's decision rows. Closing without merge so the history has one path.