The draft is guidance for the policies and procedures an organisation uses to delete personally identifiable information. It sets a common vocabulary, a way to define deletion rules, the documentation to keep and the roles and processes behind them, and it leaves the law and the deletion tools to others. Clause 1 decides every later argument about what the draft can and cannot be used for. It starts from the organisation that holds the records, not from a product or a tool. The four deliverables it names are the shape of the work: agree the words, define the rules, document the rules, and assign the people and the process. A team that writes a deletion schedule but never agrees what deletion means, or never says who approves an exception, has done one quarter of what the clause describes. The exclusions are just as practical. The draft will not tell a bank how long it must keep a transaction record, because that is set by law. It will not tell a hospital which fields belong in a patient cluster, because the controller decides that. It will not compare secure erase tools, and it will not turn a record into an anonymous data set. Each of those is a separate decision with its own evidence. The clause also frames deletion as a control that supports privacy principles rather than a standalone project. That framing is why the draft sits beside a privacy framework and a privacy information management system instead of replacing either of them.
The graph holds this control, the 0 it maps to, and the evidence behind each claim, over MCP and REST.