Who Can Change XDALC? A Proposal for Transparent Revision

A proposed process for revising XDALC: documented changes, open criticism, clear editorial responsibility, archived versions and explicit adoption.

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.

Distinguish contribution from publication authority

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.

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.

Describe the proposed change precisely

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.

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.

Review, decide and preserve the record

1. Publish a clearly labeled proposal with its rationale and relevant evidence.
2. Invite criticism from people with different roles and affected interests.
3. Record material objections and explain accepted or rejected changes.
4. Assign an identifiable version and status to the resulting text.
5. Preserve earlier versions and explain migration implications.

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.

Publication is not automatic adoption

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.

The Versions & Changes archive 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.

Article 16 of proposed XDALC-V002 motivates this proposal. See adoption and normative authority for the distinction between reading, endorsing, publishing and governing an implementation.