<div dir="auto">Dear colleagues,<div dir="auto"><br></div><div dir="auto">A separate concern is where implementing an existing policy ends and creating a new compliance requirement begins. Paragraph 2 acknowledges that compliance cannot always be objectively measured, while requiring the dashboard’s automation to evolve alongside the CPM. However, the proposed text does not specify how changes to the meaning of a compliance test will be distinguished from ordinary software updates. </div><div dir="auto"><br></div><div dir="auto">The appendix includes outdated Whois information among the possible dashboard checks.  Consider a hypothetical implementation that flags a record because it has not been edited for twelve months. That measures the record’s age, not whether its contents are wrong. Information may remain unchanged precisely because it remains accurate. Unless the applicable policy requires periodic reconfirmation, turning that age threshold into a compliance requirement would introduce an additional obligation through software configuration.</div><div dir="auto"><br></div><div dir="auto">This distinction matters because the proposal anticipates incorporating different parts of the RSA and CPM progressively, according to Board and staff decisions, without a predefined completion timetable.  Phased development can be practical, but members need to know whether a later phase merely introduces another way to check an existing obligation or introduces a stricter interpretation that was never established in the policy itself.</div><div dir="auto"><br></div><div dir="auto">There is also an implementation question to resolve. CPM section 3.4.5 states that the implementation date should be less than six months after Last Call unless a waiver is requested. The authors should explain what would constitute implementation of this proposal, which checks would be included initially, and how subsequent phases would be governed. Open-ended development should not leave the substantive boundaries of the policy open-ended as well. </div><div dir="auto"><br></div><div dir="auto">A clearer specification would make each check independently reproducible, disclose its assumptions and thresholds, and publish a version history explaining changes. This reflects the principle that shared technical rules should be narrowly defined and independently verifiable, rather than depend on continuing institutional interpretation. </div><div dir="auto"><br></div><div dir="auto">Routine bug fixes would not need a new policy debate. But a change that introduces a new duty, stricter compliance condition or wider applicability should be identified and considered as a substantive policy change, not treated as routine dashboard maintenance. The software should implement the agreed rule, not become the place where additional rules are made.</div><div dir="auto"><br></div><div dir="auto">Regards,</div><div dir="auto">Nonjabulo</div></div>