Summary

  • AFRINIC’s 9 November 2021 Draft 2 proposed a private, periodically refreshed compliance view, automatic notices, staff escalation after three unresolved months and a recurrence threshold of more than three confirmed violations in twelve months.
  • The proposal discussion’s unannounced-IPv6 example showed why an automated observation is not self-proving: a lack of public routing visibility could coexist with legitimate internal use.
  • Draft 2 did not define who confirms a violation, what evidence is sufficient, how a member challenges a flag, whether a dispute pauses either clock or whether correction erases an adverse count.
  • Notice and correction fit a private technical registry’s bookkeeping role; public recovery notices, name-server removal, service withholding, resource recovery, revocation and member closure are categorically different acts.
  • A safe dashboard needs explicit states, evidence provenance, human reasons, conflict separation, correction history and a hard technical barrier between the notice record and every consequence system.
  • AFRINIC is a private membership-based technical bookkeeper and coordinator, not a sovereign, regulator, police force, prosecutor, punisher, confiscator or public-law court.
  • The strongest version of the proposal would stop at visibility: disputed items would pause clocks and counts, corrected false positives would disappear from adverse totals, and consequential disputes would move to competent independent review while continuity was preserved.

The difference the machine could not explain

The IPv6 example matters because it begins with a fact rather than a theory. An automated system can query public routing information and find no announcement for a particular assignment. It can record the time of the query, the source examined and the absence it observed. Those are potentially useful data. None of them answers why the route is absent. The assignment could be dormant. A contact record could be stale. A member could have made an error. Or the addresses could be serving a legitimate internal network that was never meant to appear in the public routing table.

The same observable therefore supports several possible explanations. Automation can make the discrepancy visible; it cannot select the true explanation merely by displaying a compliance status. That was not an objection invented after the fact. In the 16 November 2021 RPD discussion, one of the proposal’s authors said the dashboard would use information AFRINIC already held, would remain private to the member, and could flag an unannounced IPv6 assignment even though the member was legitimately using it internally. The member’s explanation was not an indulgence added to the process. It was information necessary to interpret the signal.

That distinction became more consequential in Draft 2 because the proposed dashboard did not end with a private row on a screen. The text described automatic notification when RSA or policy non-compliance was detected, reminders, and notification to AFRINIC staff when an issue remained unresolved for three months. It also said that more than three confirmed violations during a twelve-month period should be treated as persistent non-compliance, with the trigger resetting after twelve months containing no policy violations.

Evidence of persistent lack of compliance could lead to a more exhaustive investigation and further action under the Registration Services Agreement.

The instrument was AFPUB-2021-GEN-003-DRAFT02, version 2.0, submitted on 9 November 2021. It proposed adding a section to the Consolidated Policy Manual. Its four named authors were Jordi Palet Martinez, Frank Habicht, Mark Elkins and Haitham El Nakhal. Those details identify a proposal and its terms; they establish neither ratification, effective force nor implementation.

The official page later recorded approximate consensus on 18 November 2021, a last-call period from 8 December 2021 to 5 January 2022, consensus announced and a ratification report sent to the Board on 14 January 2022, and an appeal filed that day and withdrawn on 9 August 2022. The record proves those procedural entries. It does not prove Board ratification, effective force, a working dashboard, an individual member flag or any adverse action. The appeal’s merits are a different subject.

The proposal must be read at the point where its words change function. “Observed” describes what a check found. “Unresolved” describes the absence of an accepted disposition after time has passed. “Confirmed” implies a decision about evidence and meaning. “Persistent” aggregates decisions across a period. Each word calls for a different process. Draft 2 supplied definite thresholds around these states but did not supply a complete bridge between them. The sharper the thresholds became, the more important that missing bridge became.

A useful service, up to a clear boundary

There is a strong case for giving members a private, consistent account of information that may need attention. Number-resource administration depends on records being accurate enough for coordination. Contacts change. Organisations restructure. Documents expire. Payment records can be misunderstood or overlooked. A policy may require a particular update that a member does not realise is missing. An exact notice can reduce the cost of discovering the problem for both the member and registry staff.

The proposed privacy of the dashboard is important in that benign case. A member-only view allows a discrepancy to be raised without prematurely turning it into a reputational claim. A periodic check can make treatment more consistent than occasional, informal enquiries. Reminders can prevent a correctable record defect from lingering because an email reached the wrong person or an operational team assumed another department had responded. A common record can preserve what was observed, when notice was sent, what the member supplied and how the matter was closed. Those are genuine service improvements.

The private view could also make AFRINIC’s own work more reviewable. If a dashboard row named the exact RSA or CPM provision and version, identified its data source, distinguished a measured fact from an interpretation and carried a correction history, a member could answer the real issue rather than guess at a broad allegation. Staff could see whether a rule check was producing recurring false positives. Policy authors could discover that a supposedly objective requirement depended on facts the registry did not possess. Good visibility can reveal defects in the checker as readily as defects in a member’s records.

This is why the right response is not to reject automation or dashboards. A registry should use tools that make its narrow administrative duties more precise. A machine is well suited to locating an empty field, comparing a stored date, recording a query result, checking whether a required artefact exists, or bringing an apparent mismatch to a person’s attention. It can reduce search costs and improve the audit trail. It can do all of that without pretending to decide a contested contractual, legal, business or operational meaning.

The limit is functional. A notice tells the member, “This check found this difference, using this source and this rule; please correct the data or explain why the observation is not a defect.” A verdict says, “This difference has become a violation that counts against you.” Those sentences are not two levels of the same user-interface feature. The second changes the member’s position and can supply a premise for more serious action. It therefore needs a decision-maker, a standard of evidence, a fair opportunity to answer, reasons, correction machinery and an avenue of review proportionate to the consequences.

A clean screen cannot substitute for any of them.

Five states that must not collapse into one

Draft 2’s central weakness is easiest to see by separating five states: observation, dispute, confirmation, recurrence and consequence.

An observation is the raw result of a check. The public routing source did not display an announcement at the recorded time. A contact field was empty. A payment record had a certain status. A document in AFRINIC’s possession lacked a particular item. The observation should be reproducible and tied to a source, timestamp and rule version. Even here, the system must be modest: “not visible in the checked source” is more accurate than “not used,” just as “no document found in this store” is not the same as “no document exists.”

A dispute begins when the affected member supplies information or contests the interpretation. The member may show that the IPv6 assignment serves an internal network, that the contact was updated through another channel, that a payment was allocated incorrectly, or that the invoked clause does not govern the situation. A dispute is not proof that the member is right. It is proof that the dashboard’s initial meaning is not settled. The record must change state accordingly. Time cannot fairly convert that live question into confirmation.

Confirmation is a reasoned disposition. Someone must identify the applicable rule, assess the evidence on both sides, distinguish an objective registry defect from an interpretive controversy and explain the result. Draft 2 used “confirmed violations,” and it also described “confirmed contractual non-compliance,” but the published text did not define who performed confirmation, the evidence threshold, the required reasons, the reviewer’s independence or the effect of a timely challenge. Without those elements, “confirmed” risks becoming a label applied by the same system or office that produced the original flag.

Recurrence is not merely another confirmation. It aggregates prior decisions and attributes significance to their pattern. Draft 2 proposed that more than three confirmed violations in twelve months be treated as persistent non-compliance. To calculate that count responsibly, each constituent item must be eligible. Corrected false positives must be excluded. Duplicated alerts arising from one underlying issue must not become several violations. A timely disputed item must not enter the total before a fair disposition. The system must say when the twelve-month window starts, how the no-violation reset works and whether a later reversal recalculates the historical count.

A consequence is an act taken because of a resolved finding under a separately legitimate process. Draft 2 described a chain that could go far beyond asking for corrected data. Its text linked confirmed contractual non-compliance, including unauthorised transfers, non-payment or document fraud, to service revocation and member closure under the RSA. It said repeated or continued RSA or policy non-compliance could lead to service withholding and resource revocation. The proposed recovery sequence involved attempts at contact and rectification, placement of resources on a public recovery page for up to three months, backup and removal of relevant NS records after two unresolved months, and recovery of resources plus removal of holder records from AFRINIC’s database after three months on the public page.

These five states carry different factual and institutional burdens. A useful design makes the separation visible and enforceable. An unsafe design allows a single “compliance” status to obscure them. Draft 2 did not specify a numerical composite score, and it should not be described as if it did. Yet its statuses, time thresholds and recurrence count could still behave as a score-like state from the member’s perspective: a machine-readable adverse condition could accumulate weight and move the member closer to consequences. The danger does not depend on a colourful gauge or a number out of one hundred.

It lies in what the state is allowed to trigger.

The missing bridge after detection

The word “detected” sounds more conclusive than the underlying process may be. Software detects a configured condition: a value differs, a route is absent from the source checked, a record has not changed by a deadline, a document does not match a rule encoded by its designers. Whether that condition constitutes non-compliance can be straightforward in some cases and deeply interpretive in others. Draft 2 did not publish a complete field-level model showing which checks were objective, which required judgement, which source controlled, how confidence was expressed or how competing evidence was handled.

That omission matters because unlike conditions should not be compressed into one compliance truth. A stale administrative contact, an apparent routing absence, an unpaid invoice, an alleged unauthorised transfer and suspected document fraud differ in evidence, seriousness and appropriate forum. Some are correctable data-quality issues. Some are contractual disputes. Some may involve disputed intent or contested documents. Displaying them in one dashboard can be convenient, but convenience does not erase their legal and factual differences.

The proposal’s text left basic questions unanswered. Who changes a detected item into a confirmed violation? Is it the author of the automated check, a hostmaster, a manager, a legal officer, the Board or someone independent of the original assessment? What evidence is sufficient? Does the member see the raw observable and the exact rule before the clock starts? Does proof of delivery matter? Can the member submit evidence in the same record? Must the decision address that evidence? What happens when the rule changed between observation and review?

The treatment of time was equally unclear. If a member disputes the IPv6 inference without delay and supplies a legitimate internal-use explanation, is the issue still “unresolved” for purposes of the three-month escalation? Does “unresolved” mean nobody has closed the row, or does it mean a competent reviewer has rejected the explanation? If AFRINIC takes weeks to consider the response, does its own delay consume the member’s clock? If the system later recognises a false positive, is the adverse state erased from the recurrence total as though it never qualified, or does it continue to stain the twelve-month record?

There was also no complete account of the relationship between the thresholds. The three-month provision concerned an issue that remained unresolved and notification to staff. The twelve-month provision concerned more than three confirmed violations and persistent non-compliance. Those could be separate tracks, but the proposal did not supply a state machine showing how they interact. A reader cannot safely assume that every three-month flag becomes a confirmed violation. Nor can a member rely on the text to guarantee that it does not.

Where the downstream stakes include publication and operational intervention, ambiguity itself is a governance risk.

“Human review” alone is not an answer. A person who simply accepts the machine’s label has not added meaningful judgement. A reviewer needs the relevant evidence, authority limited to the question at hand, separation from the original check where interpretation is contested, a conflict declaration and an obligation to give reasons. The member needs a practical way to correct facts and challenge meanings before any adverse count changes. Review must be a change in the quality of decision, not merely a person clicking a confirmation box.

How clocks turn ambiguity into leverage

Time thresholds can be valuable. They prevent issues from disappearing into an endless queue, tell members when a response is expected and cue staff to follow up. But a clock is never neutral when reaching its end changes institutional behaviour. It allocates the cost of delay. If a disputed dashboard state continues to age while the registry reviews it, the member bears the risk created by the registry’s pace. If the state enters a recurrence count before the dispute is decided, elapsed time begins to manufacture adverse evidence.

The three-month trigger in Draft 2 was formally a notification to AFRINIC staff. That is less severe than revocation. Even so, escalation can alter how a case is perceived. A row marked as unresolved for three months may look like member inaction when the record actually contains a timely explanation awaiting assessment. Staff attention can shift from “Is the check correct?” to “Why has this member failed to cure?” The status silently imports a conclusion about responsibility.

The twelve-month recurrence rule adds a second form of leverage. More than three confirmed violations were to constitute persistent non-compliance. The exact phrase “confirmed” should have been a safeguard, but only if confirmation had a defined meaning. Without an evidence standard and challenge rule, the count can inherit every weakness of the individual findings. Four doubtful items do not become reliable because they are added together. Repetition may instead reveal one flawed check firing four times, one underlying issue fragmented into several entries, or a policy interpretation that remains contested.

The reset provision—twelve months with no policy violations—also requires precision. If a finding is overturned ten months later, does the clean period begin at the original erroneous flag, at correction, or at reversal? If an item concerned an RSA question rather than a resource-policy question, does it interrupt a reset described in terms of policy violations? If the member’s record never shows the answer, the recurrence mechanism is not auditable. A threshold that can influence “persistent” status must be reproducible by the affected member, not merely calculated inside the registry.

The correct rule is simple even if its implementation requires care: a timely dispute pauses every adverse clock and keeps the item out of recurrence. The pause should last until a reasoned disposition is delivered through the agreed channel. A corrected false positive should be removed retroactively from every adverse total. The audit record may preserve that the check occurred and was corrected; the compliance count must not preserve the accusation as if it remained valid. Otherwise, correction fixes the screen while leaving the penalty logic contaminated.

Notice is not recovery

Draft 2’s most serious design problem was not the existence of notices. It was the proximity of the dashboard’s evidence language to a sequence of public and operational consequences. The proposal described contact and rectification before placing unresolved resources on a public recovery page for up to three months. After two months of publication, relevant NS records could be backed up and removed if the matter remained unresolved, with possible restoration after contact and resolution. After three months, the resources could be recovered and the holder records removed from AFRINIC’s database.

The Board could extend the revocation period, after staff assessment, for essential strategic infrastructure or exceptional conditions such as natural disaster or political instability.

Each step changes the nature of the act. A private notification is bilateral and correctable. Publication exposes the matter to third parties and can cause reputational effects even if the underlying interpretation is later reversed. Name-server record removal is an operational change, not an informational message. Service withholding alters the member’s relationship with the registry. Resource recovery and removal of holder records change the registry state on which other actors may rely. Revocation and member closure terminate rather than clarify.

The fact that these measures were described in a proposal referring to the RSA does not allow the dashboard to prove the contractual premise. A contract may set duties and remedies, but a disputed automated observation is not contractually conclusive merely because it appears beside them. There must still be a defensible route from evidence to finding and from finding to any authorised contractual process. The system that raises the question should not be able to execute the answer.

Continuity makes that separation especially important. Internet number-resource records are not ordinary loyalty points that can be frozen without effects beyond the immediate dispute. Operators plan networks, maintain customer commitments, manage routing and DNS dependencies, and coordinate with many third parties. LARUS has described documentation burden, delay, registry uncertainty and continuity exposure as channels through which registry governance reaches operators. That analysis does not establish that Draft 2 caused a particular outage, cost or sanction.

It explains why an ambiguous adverse state can produce real planning and operational risk long before a final measure is taken.

The uncertainty itself can change behaviour. A member that does not know whether its response paused a clock may divert technical and legal staff from other work. It may postpone infrastructure decisions because a resource’s registry status feels unstable. Counterparties may react to a public recovery notice without waiting for the underlying dispute to be resolved. Once name-server records or holder data change, restoration may not perfectly reverse every dependency, cache, customer reaction or lost opportunity. A later correction is not always equivalent to continuity.

This does not prove that any such outcome occurred under Draft 2. The available record establishes no implementation, actual dashboard state, confirmed member violation, public listing, NS removal, recovery, revocation, closure, quantified cost or outage. The point is prospective and institutional: when a proposed information system sits near actions capable of producing those effects, its architecture must prevent uncertain data from writing directly into them.

The necessary barrier should be technical as well as procedural. The dashboard may send a notice and open a review task. It should have no permission to publish a resource, alter NS records, withhold a service, recover an address block, revoke a registration or close membership. No recurrence counter should call those functions. No expired timer should change the registry. At most, a resolved administrative record can be supplied as evidence to a separate, independently authorised process that must establish its own jurisdiction, standard and continuity protections.

The staff recommendation identified the right line

The AFRINIC-34 policy-meeting material contained a significant recommendation: limit the proposal to improved compliance visibility for AFRINIC and the resource member, while leaving contract management outside the dashboard proposal. That assessment did not establish that the recommendation was adopted. It did, however, identify the functional line Draft 2 needed.

Visibility and contract management answer different questions. Visibility asks what the records show, whether a rule may apply, what information is missing and what the member says in response. Contract management asks whether an obligation was breached, what contractual procedure governs, who can decide the dispute and which remedy is authorised. Combining them in one policy object makes the ease of the first task appear to legitimise the second.

Narrowing the dashboard would not have made it toothless. A well-designed visibility service could have improved registry accuracy, reduced repetitive enquiries, created evidence of notice, prioritised staff assistance and shown where policies were too ambiguous to automate. It could have measured its own quality through correction rates and overturned flags. It could have helped members cure objective defects faster. Those are substantial gains precisely because they remain tied to the registry’s technical and administrative competence.

Nor would separation have prevented AFRINIC from addressing a genuine contractual question through whatever valid contractual mechanism existed. It would have required that mechanism to stand on its own rather than borrow conclusiveness from a dashboard. The record of a check could travel as evidence. Its adverse label, clock and count could not travel as a verdict. That distinction preserves useful information while forcing consequential actors to justify their authority and reasoning.

A private registry cannot promote itself through software

NRS describes AFRINIC as a membership-based nonprofit incorporated in Mauritius whose core role concerns Internet number-resource administration. That institutional form matters. AFRINIC performs important coordination work, and accurate registry records are valuable. Importance is not sovereignty. Technical necessity is not public-law authority.

AFRINIC is a private technical bookkeeper and coordinator. It is not a sovereign, legislature, regulator, police force, prosecutor, punisher, confiscator or public-law court. A policy meeting cannot manufacture those powers by voting. Consensus among participants cannot turn a private compliance status into law. Board discretion cannot transform a registry observation into a judicial finding. Repeated participation by members may support coordination rules; it does not give the registry a general mandate to police conduct or pronounce guilt.

Lu Heng’s distinction between administration and punishment provides the relevant institutional test. A registry may maintain accurate records, coordinate necessary changes, notify a member of a precise discrepancy and carry out narrow procedures needed for interoperability. It crosses the boundary when it uses control of the address book as leverage to punish contested conduct. The physical ability to edit a registry is not authority to confiscate what the record describes.

That boundary is sometimes obscured by the word “compliance.” In an administrative setting, the word can mean no more than whether a stored record appears to match a defined requirement. In an enforcement setting, it suggests a judgement about a person’s or organisation’s conduct. A dashboard that mixes the two can cause administrative power to expand without a direct argument. The screen looks technical, the checks look objective and the thresholds look consistent. Yet the eventual decision may concern disputed contracts, intentions, authorisations or business facts that the technical registry is not competent to adjudicate conclusively.

Consistency does not solve the authority problem. Applying the same inadequate process to every member is not fairness. Transparency does not solve it either if only the adverse label is visible while the inference, uncertainty and reviewer reasoning remain hidden. Consensus does not solve it because a private community cannot acquire sovereign powers through internal repetition. And exceptional Board discretion does not solve it.

The ability to delay a proposed revocation for strategic infrastructure, natural disaster or political instability may reduce immediate risk in some cases, but it does not create an independent tribunal or cure an uncertain finding.

This is not an argument that private organisations can never enforce contracts. It is an argument about the source and limits of any action. A contract-based consequence must arise through the contract’s valid terms and a fair method for resolving contested facts, subject to whatever competent independent authority applies. It cannot arise because a dashboard row aged, a recurrence count crossed a threshold or a coordination database could technically be changed. The more severe the consequence, the less acceptable it is to treat administrative possession of infrastructure as proof of jurisdiction.

Designing a dashboard that can be trusted

A safe alternative begins by refusing the single “compliance” bucket. Every row should identify one exact observation and move through explicit states. A workable sequence might be: observed difference; notice delivered; member response pending; disputed with clock paused; human review pending; corrected with no adverse count; verified registry defect with remediation open; resolved; or external independent process pending with continuity preserved.

The first row should answer basic reproducibility questions. Which RSA or CPM clause is implicated, and which version? What source was checked? At what time? What raw fact was observed? Was the check objective—for example, whether a required field was blank—or interpretive, such as whether an absence in one public dataset demonstrated non-use? What was the system’s confidence, and what alternative explanations were known? A member should not have to reverse-engineer a label.

Notice should have its own evidence. The record should show the channel used, recipient, time and proof of delivery. A timer should not begin merely because software attempted to send a message to an obsolete address. The member should be able to acknowledge, correct or dispute the item in the same record, attach supporting material and identify information that should not be exposed beyond the review. Privacy should be preserved unless a separate authorised process establishes a lawful basis for disclosure.

A dispute must change the system’s permissions, not merely add a comment. The adverse clock pauses. The item becomes ineligible for recurrence. Any automatic escalation describes it as contested, not overdue. The last verified registry state remains intact. The system assigns a human reviewer who did not own the original interpretive check, records conflicts and produces a reasoned disposition addressing the member’s material evidence. If the issue is outside technical registry competence, the disposition should say so rather than forcing the question into a policy field.

Correction needs two records: an immutable history and a clean present state. The history should show that a check occurred, why it was wrong, when it was corrected and which rule or data source needs improvement. The current adverse count should exclude it completely. This allows institutional learning without making the member carry a false violation. Superseded findings must be traceable so that staff do not unknowingly rely on an old export or cached status.

Confirmation should be narrow. A reviewer might confirm an objective registry defect—for example, that a specifically required contact field remains absent after verified notice and the member does not contest the fact. That does not automatically confirm broader contractual non-compliance, intent or eligibility for punishment. The disposition should say exactly what has been established and what has not. Its evidence standard should be published before the decision, not invented in response to a difficult case.

Recurrence requires its own eligibility rules. Only final, reasoned, non-overturned findings of the same relevant class should count. Multiple alerts generated by one defect should be consolidated. A later correction that reveals a false positive should recalculate the window automatically. The member should be able to reproduce the total from the visible decisions. The system should never infer “persistent” from volume without asking whether the volume reflects repeated member conduct, a repeated system error or one prolonged dispute.

The consequence firewall is the most important component. Dashboard software should not hold credentials or API permissions for public recovery pages, NS changes, service controls, resource recovery, revocation or closure. A timer expiry should never execute such an action. A threshold crossing should never queue it automatically. Even a final dashboard disposition should only form part of an evidentiary bundle sent to a separately governed process. That process must identify its contractual or legal authority, permit challenge before irreversible action, protect continuity and remain subject to competent independent review.

For disputes with potentially severe effects, the proper end state may be “external or independent process pending, continuity preserved.” The dashboard can show that the technical record is contested and route communications, but the last verified operational state should remain in place. This avoids asking the registry to decide questions beyond bookkeeping competence and avoids forcing a member to win an internal argument before its network position is kept stable.

Metrics should evaluate the dashboard itself, not rank members. Useful measures include how often flags are corrected, how often they are overturned, average time to staff disposition, proportion of notices proven delivered, recurring data-source errors and the number of interpretive checks removed from automation. A high false-positive rate is not evidence of widespread non-compliance; it is evidence that the check needs redesign. Making that institutional learning visible would improve both accuracy and trust.

Testing the benign case seriously

Supporters of a dashboard can make a persuasive practical argument. Members may miss policy changes. Contact chains fail. A private organisation managing many records needs consistent ways to surface issues. Manual review can be slow and uneven. A dashboard can reveal an exact problem earlier, send reminders, offer a cure opportunity and help staff focus on cases needing clarification. Without some structure, responsible members may spend too much time discovering what AFRINIC wants, while obvious defects remain unaddressed.

That case deserves acceptance, not caricature. The answer is to build the service it describes. Make the notice exact. Reveal the source and rule. Keep it private. Let the member correct data or explain context. Preserve a reviewable exchange. Distinguish facts the registry can verify from interpretations it cannot settle alone. Use automation to reduce repetitive work and improve the address book.

But nothing in the benign case requires a disputed flag to keep ageing toward an adverse state. Nothing requires an unresolved machine view to count as a violation. Nothing requires a recurrence total to include corrected or contested items. Nothing requires the dashboard to publish resources, remove NS records, withhold services, recover number resources, revoke registrations or close membership. Those additions do not make notice more accurate. They change its institutional character.

The best answer to concerns about member neglect is reliable proof of notice and a clear remediation state, not automatic punishment. If a member does not respond to a precise, delivered notice about an objective registry defect, AFRINIC can document that fact and continue the narrow administrative process authorised for the record. If the issue concerns a contested contract or alleged misconduct, the evidence can go to a competent forum. Separation does not excuse real defects. It prevents the registry from treating control of essential records as a shortcut around adjudication.

What the later record does—and does not—show

The official proposal page’s later procedural entries should be handled with discipline. Approximate consensus at AFRINIC-34, a last-call period, the announcement of consensus, transmission of a ratification report and the filing and withdrawal of an appeal show that Draft 2 moved through a disputed policy process. They do not answer the design question simply by existing. Consensus is not a substitute for the missing transition from observation to confirmed violation.

Nor do those entries establish Board ratification, effective force or implementation. The sealed public record used here contains no individual dashboard screen, member status, confirmed violation, recurrence count, public recovery notice, NS removal, service withholding, resource recovery, revocation or closure attributable to Draft 2. There is no basis to write as if the proposal was deployed or as if it punished someone. Prospective scrutiny is warranted because the proposed chain was serious, not because an unproved event should be implied.

The appeal record is relevant only to the limited fact that the later consensus determination was disputed and the appeal was eventually withdrawn. Its merits, standing and disposition are not needed to decide whether Draft 2’s state transitions were adequately specified. That question can be answered from the proposal’s own thresholds, consequence language, discussion example and missing definitions.

The existing BTW analysis of Draft 1 addressed the general case for a member-visible indicator and the general need to keep visibility non-punitive. Draft 2 presents a narrower and more definite problem. Its three-month unresolved escalation, its more-than-three-confirmed-violations threshold, its twelve-month reset and its proximity to a recovery sequence make confirmation architecture—not the catalogue of possible indicators—the centre of analysis. The information gain lies in the gate between a flag and a count.

The counterfactual Draft 2 needed

Imagine that Draft 2 had stopped after a member-only visibility layer. The unannounced IPv6 row would display the exact public source checked, the timestamp and the modest observation: no announcement was visible there. It would explain that internal use was a known alternative. It would link to the exact rule version thought relevant and invite the member to correct the record or provide context.

The member would respond that the assignment served an internal network. That response would put the item into a disputed, clock-paused state. A neutral reviewer would consider whether the invoked rule actually required public announcement, identify the evidence and issue reasons. If the member’s explanation resolved the matter, the row would close without any adverse recurrence entry. The history would remain available to improve the automated check, but the member would not carry a ghost violation.

If the answer instead revealed a precise, objective registry defect, the dashboard would open a remediation task. It would record what needed correction, confirm delivery, preserve the member’s operational state and close when the record was fixed. If a distinct contractual controversy remained, the dashboard would label it as such and route the evidence to the proper independent process. It would not decide the controversy by letting a timer expire.

In this version, three months could still be useful as a service standard. It might trigger a supervisory check that the notice was delivered, the member’s evidence was reviewed and staff had not allowed a case to stagnate. It would measure the process, not presume member guilt. A twelve-month view could identify repeated verified administrative defects for assistance or policy evaluation, while excluding disputes, reversals, duplicates and corrected false positives. It would never serve as an automatic warrant for consequences.

Most importantly, the dashboard would be physically and logically incapable of publishing a resource, deleting an NS record, withholding service, recovering an allocation, revoking a registration or closing membership. Those actions would live outside its permissions and outside its policy purpose. Any separately authorised decision would have to establish its own basis and could not cite a status colour, elapsed timer or recurrence total as a substitute for reasons.

This counterfactual retains nearly every persuasive benefit claimed for a dashboard: earlier notice, consistent presentation, reduced support friction, better evidence, easier correction and useful insight into recurring record problems. What it removes is the feature a private technical registry should not possess—the ability to make its own uncertain observation operationally coercive.

A ledger should tell the truth about uncertainty

At its best, a registry is trusted because its records are narrow, accurate and auditable. It knows the difference between what it observed and what it inferred. It corrects errors without preserving them as adverse history. It coordinates changes needed for continuity and does not exploit dependence on its database to settle unrelated disputes.

Draft 2 recognised a genuine information problem. Members benefit from knowing what AFRINIC’s records and checks see. The discussion’s IPv6 example also exposed the exact point at which that information ceases to be self-explanatory. The proposal’s thresholds made the unresolved point operationally important but left confirmation, challenge, pause, correction and independence underspecified.

The appropriate rule is therefore notice without punishment. An observation may create a private alert. A member response may create a dispute. A separate reviewer may produce a narrow, reasoned disposition. Only final eligible findings may enter any analytical count, and no dashboard count may itself authorise a consequence. Severe disputes belong before competent independent authority, with continuity preserved while they are resolved.

AFRINIC does not become less useful by respecting that line. It becomes a better bookkeeper: more precise about its evidence, more candid about uncertainty and more dependable in the one role that Internet coordination actually needs. A dashboard can illuminate the registry. It must never become a machine for promoting a private record into guilt.