[CfC] Call for Consensus (deadline: 2026-08-21)

Dear RecordWeb Community Group,

This is a new Call for Consensus (CfC) of the RecordWeb Community Group with a 14-day discussion period under GOVERNANCE.md §4.1 starts now and closes on 2026-08-21.

Please review and comment on the following issues:

Conformance model
- RWC#12 — Define conformance as an accountable implementation claim
  Defines RecordWeb conformance as a profile-, role-, and version-specific claim made by an identifiable implementation. It establishes the relevant trust boundary and distinguishes validation, assessment, attestation, and certification.

- RWP#5 — Add an explicit Conformance section to RWP
  Introduces a dedicated Conformance section in the protocol, formally introduces RFC 2119 terminology, and makes clear which requirements are mandatory for baseline conformance and which capabilities are optional extensions.

- RWP#12 — Define modular conformance profiles and implementation roles
  Defines the initial RWP profiles for Information Records, Case Records, and Source Integration, together with implementation roles such as producer, custodian, consumer, resolver, and source-adapter.

- RWP#13 — Define profile and role conformance requirements
  Adds a normative conformance matrix that connects profiles and roles to specific protocol capabilities, SystemRecord requirements, and testable validation requirements.

- RWP#14 — Define ConformanceRecord as a SystemRecord
  Defines a durable, machine-readable, and verifiable Record for conformance attestations, including implementation version, claimed profiles and roles, assessment method, attester, evidence, expiry, and supersession.

- RWP#15 — Define the RWP Source Integration Conformant profile
  Defines how a connector or capture component can make source objects traceable in an RWP context without claiming guarantees that the original source system does not provide.

Related protocol clarifications
- RWP#6 — Add a Privacy and Security Considerations section to RWP
  Adds a consolidated, jurisdiction-neutral discussion of cryptographic integrity, key-management expectations, personal-data implications of persistent identifiers, payload deletion, consent-based Solid Pod delivery, and data minimisation.

- RWP#19 — Define canonical Merkle hash inputs and domain separation
  Defines one byte-level canonical Merkle-root algorithm, including input representation, ordering, odd-element behaviour, domain separation for leaves and internal nodes, algorithm versioning, and interoperable test vectors.

How to participate

- Comment directly on the relevant issue with your support, concerns, or suggested edits. This is where the specification text and technical rationale should be developed.
- Please consider the conformance issues as one coherent architecture. In particular, comments on profiles, roles, the conformance matrix, ConformanceRecords, and Source Integration should identify any consequences for the related issues.
- Silence is not treated as an objection. Active review is particularly welcome from implementers, operators of records or case-management systems, connector developers, procurement specialists, security experts, and institutions that may rely on conformance claims.

What happens next

After the deadline has passed, the Editor (or a Chair, if no Editor is assigned) will summarise the outcome in the associated CfC tracking issue. If consensus is reached, the proposed text is merged. If consensus cannot be reached, the Chairs will decide and document the reasoning in the relevant issue, in accordance with GOVERNANCE.md §4.1.

Thank you for engaging with this second round.

Best regards,
Nik Jenzer
Co-Chair, RecordWeb Community Group