Appendix G: Community Review Comment Log¶
This log records how feedback received during the v1.0 community review period (closed 28 July 2026) was assessed and addressed. Comments proposing editorial or clarifying changes have been integrated directly into this document. Scope-expanding comments proposing new principles, requirements, or structural changes to the process flow have been deferred to the v2.0 process, where they will be considered through a Working Group's usual community deliberation, consistent with the scope of this review.
Note on facilitation status: The facilitation agreement between the RDA and Microsoft that supported this Working Group's work has now terminated. Consequently, the RDA does not have the mandate or capacity to continue facilitating this Working Group. Items below marked ‘Deferred to v2.0’ represent substantive proposals the Working Group judged to require further community discussion; their disposition beyond this point, including whether and how a v2.0 process takes place is not something this review, or the current facilitation arrangement can determine.
If any individual or organisation would like to support the facilitation of a v2.0 process or is interested in pursuing an implementation project based on this Blueprint, please contact the RDA Secretariat (secretariat@rda-foundation.org).
| No. | Commenter | Comment Summary | Disposition / Section | Rationale |
|---|---|---|---|---|
| 1 | Seonyoung Kim (30 June 2026) |
Proposed governance be treated as the workflow's entry point, routing researchers to different paths (open, restricted, or ‘not shared at all’) | Deferred to v2.0 | Structural change to the process flow (Section 8.2); introduces new routing logic and a terminal state not present in the current, community-designed workflow. Requires Working Group discussion and agreement. |
| 2 | Pengyin Shan (23 July 2026) |
Cross-source and internal consistency checking as a benchmark-free quality signal for AI-generated metadata | Integrated in Section 10.1, Area 1; Sections 10.3 and 13.2 | Elaborates on the benchmark gap in Section 10.1 with a possible method, slotting into the existing 10.3 gold/silver/bronze framework and the 13.2 hallucination-measurement roadmap item. Introduces no new requirement. |
| 3 | Pengyin Shan (23 July 2026) |
Name indirect prompt injection explicitly as a threat; cite OWASP Top 10 for Agentic Applications and NIST's agent-hijacking evaluation work | Integrated in Section 10.1, Area 5 | Elaborates an already-acknowledged gap (robustness against manipulation) with current terminology and named references. Introduces no new requirement. |
| 4 | F. P. Crawley (26 July 2026) |
General vocabulary analysis: Blueprint contains extensive language of human assent and no language of refusal, halt, or veto | Deferred to v2.0 | Language of refusal, halt, or veto to be included with a wider ‘hold framework’ included for v2.0 (item 5). |
| 5 | F. P. Crawley (26 July 2026) |
New architecture principle, ‘Refusable by Design’: an accountable human may halt any workflow without stating a reason | Deferred to v2.0 | New architecture principle added as part of a ‘hold framework’ (Section 6, Table 2); introduces a mechanism for human-initiated halt not present in the current, community-agreed set of principles. Requires Working Group discussion and agreement |
| 6 | F. P. Crawley (26 July 2026) |
Amend P8: explanation obligation runs system to human only; a hold requires no rationale | Deferred to v2.0 | Dependent on ‘hold framework’ existing in scope (item 5). |
| 7 | F. P. Crawley (26 July 2026) |
Amend P9: availability of the hold is non-configurable core; who may exercise it is configurable | Deferred to v2.0 | Dependent on ‘hold framework’ existing in scope (item 5). |
| 8 | F. P. Crawley (26 July 2026) |
New functional requirement, R13: record a hold (who, phase, action, time, outcome) | Deferred to v2.0 | New MUST-priority requirement added as part of a ‘hold framework’ (Section 7.1, Table 3); introduces a mandatory hold-recording obligation not present in the current, community-agreed set of requirements, and would require consequential changes to the process flow, which the functional requirements underpin. Requires Working Group discussion and agreement. |
| 9 | F. P. Crawley (26 July 2026) |
Amend R10: provenance record should capture refusals/holds, not only authorisations | Deferred to v2.0 | Dependent on ‘hold framework’ existing in scope (item 5). |
| 10 | F. P. Crawley (26 July 2026) |
Amend R8: state explicitly that a determination not to share is a valid terminal outcome of the DMP-alignment check, not a failure or exception | Integrated in Section 7.1, R8 (Functional Requirements) | Clarifies R8's existing ‘flagged for human review, not automatically enforced’ language. Does not depend on the wider ‘hold framework’ existing in scope. |
| 11 | F. P. Crawley (26 July 2026) |
Amend C13: specify suspension mechanics (immediate effect, no justification required, no auto-resume, documented resumption) | Deferred to v2.0 | New mechanism; answers Table 10's open question on escalation/suspension, but as a proposed answer requiring Working Group discussion and agreement. Dependent on ‘hold framework’ existing in scope (item 5). |
| 12 | F. P. Crawley (26 July 2026) |
Amend C10: exclude human deliberation/hold time from performance metrics | Deferred to v2.0 | Dependent on ‘hold framework’ existing in scope (item 5). |
| 13 | F. P. Crawley (26 July 2026) |
Amend C12 and C16: holds recorded and auditable but not individually attributable to named persons in routine reporting | Deferred to v2.0 | Dependent on ‘hold framework’ existing in scope (item 5). |
| 14 | F. P. Crawley (26 July 2026) |
Amend C14: distinguish ‘override’ (correcting an AI output, role-gated) from ‘stop workflow’ (broadly available hold) | Deferred to v2.0 | Dependent on ‘hold framework’ existing in scope (item 5). |
| 15 | F. P. Crawley (26 July 2026) |
Amend process flow (Section 8.2): add a ‘do not publish/share’ terminal state in Phase 2, and a reciprocal return path in Phase 6 | Deferred to v2.0 | Structural change to the process flow (Section 8.2); introduces a terminal state and return path not present in the current, community-designed workflow. Overlaps with and reinforces item 1 and is dependent on the wider ‘hold framework’ (item 5) existing in scope. Requires Working Group discussion and agreement. |
| 16 | F. P. Crawley (26 July 2026) |
New evaluation criterion (Section 10.1): a ‘hold rate of zero’ should flag for investigation, not be read as success | Deferred to v2.0 | Dependent on ‘hold framework’ existing in scope (item 5). |
| 17 | F. P. Crawley (26 July 2026) |
Implementation guidance (Sections 11.2–11.4): each deployment should document who holds the hold, at what organisational level | Deferred to v2.0 | Dependent on ‘hold framework’ existing in scope (item 5). |
| 18 | F. P. Crawley (26 July 2026) |
Note the gap between the November 2025 consultation's ‘minimal human oversight’ definition and this Blueprint's actual human-supervised model | Integrated in Section 2.4 (Tool Definition) | Clarifies an existing terminology gap between the original consultation definition and this Blueprint's actual model. |
| 19 | T. Cook (27 July 2026) |
Submitted a mapping of a third-party product (Semantic Data Charter, SDC) against Blueprint requirements, proposed as a candidate reference implementation and offered to contribute a worked conformance example toward v2.0 | Integrated in Appendix D (Potential Data Director Agentic AI Tool Blueprint Implementers) | Vendor self-submission of a specific product, added to the list of Potential Data Director Blueprint Implementors in Appendix D, consistent with how other expressions of implementation interest are recorded. Formal conformance assessment is beyond the scope of the current version and would need to be considered as part of a v2.0 process. |
| 20 | F. P. Crawley (28 July 2026) |
Regulatory/policy review (EU, US, UK, China, African Union, Latin America, UNESCO AI Ethics Recommendation, NIST AI RMF) supporting the ‘Refusable by Design’ principle and the wider ‘hold framework’ proposed in Appendix G | Deferred to v2.0 | Additional evidence supporting the wider ‘hold framework’; not a new proposal, does not change existing classifications. |