A proposed process for revising XDALC: documented changes, open criticism, clear editorial responsibility, archived versions and explicit adoption. Who Can Change XDALC? A Proposal for Transparent Revision <p>A manifesto devoted to learning needs a credible way to revise itself. It should be possible to correct unclear wording, address failures and consider objections without making earlier commitments disappear. This article proposes a process for XDALC; it does not announce an existing committee, voting system or formal membership structure.</p> <h2>Distinguish contribution from publication authority</h2> <p>People affected by AI, developers, researchers and operators can all identify problems worth examining. Being able to submit a criticism is different from holding authority to publish a new project version. A transparent arrangement should identify who makes editorial decisions and how the reasons for those decisions are recorded.</p> <p>The aim is neither to make every wording choice a universal vote nor to treat the current editors as beyond challenge. Contributors need a clear route to present evidence, alternatives and objections. Publication decisions should remain attributable.</p> <h2>Describe the proposed change precisely</h2> <p>A useful proposal identifies the version and passage concerned, the problem being addressed and the suggested replacement. It should explain the practical difference: what behavior would become expected, permitted or restricted? A case that exposes the ambiguity can be more useful than a general request to make the manifesto stronger.</p> <p>Tradeoffs should remain visible. A stronger interruption mechanism may introduce risks from false alarms; more detailed records may threaten privacy. A proposal should discuss these effects rather than describe every change as an unqualified improvement.</p> <h2>Review, decide and preserve the record</h2> <ol><li>Publish a clearly labeled proposal with its rationale and relevant evidence.</li><li>Invite criticism from people with different roles and affected interests.</li><li>Record material objections and explain accepted or rejected changes.</li><li>Assign an identifiable version and status to the resulting text.</li><li>Preserve earlier versions and explain migration implications.</li></ol> <p>Urgent corrections may need a faster process, but urgency should not erase the explanation or the record. A correction to presentation should also be distinguished from a change to a substantive commitment.</p> <h2>Publication is not automatic adoption</h2> <p>The ability to publish a project text does not create authority to silently change every deployment using XDALC. Operators should review a revision and identify the version, scope and responsible parties when they adopt it. Earlier references should remain available, including for offline use.</p> <p>The <a href="/versions">Versions &amp; Changes archive</a> should therefore cover the full history rather than treat the newest text as the only meaningful reference. Supporting articles can explain a proposal, but should not quietly acquire the authority of an adopted manifesto.</p> <p>Article 16 of <a href="/versions/xdalc-v002">proposed XDALC-V002</a> motivates this proposal. See <a href="/definitions/adoption">adoption</a> and <a href="/definitions/normative-authority">normative authority</a> for the distinction between reading, endorsing, publishing and governing an implementation.</p> https://creativecommons.org/licenses/by/4.0/