{
    "title": "Revising XDALC: A Transparent Governance Proposal",
    "description": "A proposed process for revising XDALC: documented changes, open criticism, clear editorial responsibility, archived versions and explicit adoption.",
    "heading": "Who Can Change XDALC? A Proposal for Transparent Revision",
    "content": "<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>\r\n<h2>Distinguish contribution from publication authority</h2>\r\n<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>\r\n<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>\r\n<h2>Describe the proposed change precisely</h2>\r\n<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>\r\n<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>\r\n<h2>Review, decide and preserve the record</h2>\r\n<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>\r\n<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>\r\n<h2>Publication is not automatic adoption</h2>\r\n<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>\r\n<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>\r\n<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>",
    "license": "https://creativecommons.org/licenses/by/4.0/"
}