Summary
- Regional registries already use authenticated interfaces to automate record operations, but an API that validates fields is not the same as an engine entitled to decide policy eligibility.
- Encoding clear calculations and repeatable conditions can reduce clerical delay, expose contradictions and make scenario testing possible before a rule affects resource holders.
- Automation does not eliminate discretion; it can move judgment into data definitions, evidence ranking, defaults, exception queues, release timing and undisclosed vendor components.
- A status code is not an adequate reason for a consequential refusal. Each decision should identify the controlling rule, rule version, material facts, failed condition, available correction and route to human review.
- Human-readable policy must remain controlling unless the community expressly gives a machine-readable version equivalent authority, and differences between the two must be publicly resolvable.
- Every deployed rule set should be reproducibly linked to adopted policy, signed, time-bounded and retained so an applicant can prove which version governed a past decision.
- RIRs and other lawfully authorized registry-service operators should automate only deterministic administration while preserving public rules, bounded exceptions, independent appeal, aggregate outcome evidence and the ability to replace the decision service. NRS can advocate and publish evidence-led comparisons, not operate the service.
Automation is already part of registry government
The choice is not between a wholly manual registry and a computerized one. Contemporary registration depends on software. ARIN describes its Registration RESTful Service as a secure way to interact with its database and notes that it is especially useful for repetitive, high-volume tasks that need no human communication. Its documented methods retrieve, create, modify and delete records. XML payloads carry organization, contact and network details, while API keys connect a request to a person with authority over the relevant organization or resource. The Reg-RWS documentation is evidence of mature transactional automation, not a speculative proposal.
The RIPE Database provides another model. Its REST interface accepts authenticated creation and modification of database entities, returns structured results and documents expected update latency. Query responses can be requested as JSON, XML or plain text. Separate version endpoints can retrieve a particular historical version of an entity. These features make registration actions easier to test, repeat and audit than an exchange of unstructured correspondence.
RDAP adds a standardized retrieval layer. RFC 9083 defines JSON response entities, conformance identifiers, events, status values, notices and error bodies. RFC 9537 adds a structured way to identify fields redacted from a response. A client can therefore distinguish classes of registration data and interpret some limits without scraping a page designed only for a human reader.
None of these instruments proves that allocation, transfer or membership judgments should be delegated wholesale to software. They prove a narrower point: structured interfaces can carry facts, authority and results reliably. That is a necessary foundation for machine-readable policy, but it does not settle who defines the decisive facts, which exceptions deserve recognition, or how a mistaken refusal is corrected.
The boundary matters. A command that rejects an overlapping network range is enforcing a technical invariant. A decision that a corporate document is limited public evidence, a transfer is inconsistent with policy, or an applicant has not demonstrated the relevant operational condition contains more judgment. Both may produce an error response. Their institutional meaning is not the same.
A valid payload is not a legitimate decision
Software interfaces are good at enforcing form. ARIN's documented methods, for example, can reject a request because an organization lacks required points of contact, a range extends beyond its parent, an API key lacks authority, a record conflicts with an existing entity or a rate limit has been exceeded. The method and error documentation gives an operator a practical account of many such failures.
These checks reduce mistakes. They also illustrate three different kinds of rule that should not be collapsed. Syntactic rules ask whether a value is shaped correctly. Referential rules ask whether related records exist and are consistent. Substantive rules ask whether the applicant is entitled to the requested outcome. The first two often permit exact validation. The third may depend on contested evidence, policy purpose, temporal facts or an exception created to avoid an absurd result.
An engine can execute all three categories, but execution does not confer legitimacy. The substantive condition must come from an authorized rule. Its translation into an executable expression must preserve meaning. The data supplied to that expression must be appropriate. The result must remain open to correction. If any link is hidden, consistency can become a polished form of unaccountable power.
The same caution applies to machine-readable registration data. RDAP's rdapConformance field tells a client which technical specifications shaped a response. Event fields can show registration or last-change dates. Notices can describe a service-wide condition. Those are valuable conventions. They do not tell a rejected transfer applicant which policy clause controlled, which evidence was accepted, which fact failed, or why an exception did not apply. A standards-compliant response can still be institutionally opaque.
This is why the next phase of registry automation should begin with a classification exercise. Each current decision point should be labelled as deterministic, evidential, evaluative or exceptional. Deterministic checks can normally run automatically. Evidential checks can run automatically only when the source and confidence are defined. Evaluative checks may assist a person but should not silently become final. Exceptional cases need an explicit path rather than a false value inserted to make the code continue.
What encoding can genuinely improve
Scepticism about automated discretion should not obscure the gains from careful formalization. Number-resource rules contain calculations, dates, hierarchy, mutually exclusive conditions and repeated tests. These are exactly the features for which a machine-consumable expression can improve reliability.
New Zealand's Better Rules for Government discovery found value in developing human-readable text, pseudocode and software together. The exercise reported that a common decision model helped identify omissions, reduced translation gaps and allowed scenario testing. It also stressed that not every rule is suitable for machine consumption. The useful lesson for registries is methodological rather than governmental: formalization can expose disagreement before a rule is deployed.
The OECD's Rules as Code study describes the concept as an official machine-consumable version of rules that computers can apply consistently. For number resources, this could let operators test a proposed transfer or assignment against a published rules service before submitting it. Policy authors could run historical and synthetic cases against a draft. Reviewers could compare the outcomes of old and new text rather than arguing only from abstract wording.
Formal tests can also reveal impossible combinations. Suppose one clause requires a contact attribute that another privacy rule forbids retaining. Suppose a transfer condition depends on an event that the registry does not record in a stable field. Suppose a time limit is ambiguous about weekends or time zones. Human administration may conceal these contradictions through informal accommodation. An executable representation forces them into view.
Consistency is another legitimate benefit. A clear date calculation should not depend on which analyst receives a request. A hierarchy check should not change across offices. A rule that produces different results for identical inputs should be treated as defective. Automation can narrow this category of avoidable variation and free skilled staff to examine the cases that actually require judgment.
The strongest case is therefore not cheaper refusal. It is better rule quality. Encoding should create testable propositions, common definitions, reproducible examples and early evidence about distributional effects. Savings may follow, but they should not be the constitutional justification.
Discretion moves; it does not disappear
Every executable rule contains choices. Some are obvious, such as a numerical threshold. Others hide inside apparently neutral engineering. A field may accept only one corporate identifier even where a jurisdiction issues several. A date may be read in the registry's time zone rather than the applicant's. A missing value may default to false. A name comparison may treat punctuation, transliteration or a legal suffix as evidence of mismatch. A risk flag may send one class of applicant into manual delay while another receives an immediate answer.
These choices are discretion exercised in advance. Once embedded, they can affect thousands of cases without the visibility of a staff memorandum or a public meeting. Repetition makes the choice more consequential, not less. An erroneous clerk can be corrected case by case; an erroneous default can reproduce the same denial at scale.
There is also discretion in deciding what not to encode. A registry may automate the main rule while leaving an exception in a staff guide. Applicants who know the institution can ask for it. Those who interact only through an interface may never learn that it exists. The apparent neutrality of self-service then rewards institutional familiarity.
Release timing is another source of power. Policy communities can adopt a change, but the production service may continue to run the earlier interpretation until implementation is complete. The RIPE community's Policy Development Process expressly separates community policy from RIPE NCC business practices and calls for an impact analysis of implementation effects and work. That distinction protects the community's authority only if the deployed rule can be traced to the adopted text and its effective date.
Finally, metrics can create discretion. If staff are measured on rapid closure, the engine may prefer rejection over clarification. If the measure is fraud avoided, false positives may be tolerated without adequate study. If the measure is completion, difficult applicants can be redirected until they abandon the request. Code faithfully optimizes what an institution rewards. Accountability must therefore cover operational incentives as well as source code.
The politics of inputs
A rule engine does not observe the world directly. It receives representations: registry records, corporate documents, routing observations, account relationships, attestations, dates and declarations. The quality and authority of these inputs determine the outcome.
Consider organizational existence. One jurisdiction may provide a reliable public company register with an interface. Another may issue a paper certificate. A public institution may exist by statute rather than incorporation. A small network may be operated by a natural person where local law permits it. If the engine treats only an automated company-register response as authoritative, it has converted administrative convenience into a substantive eligibility rule.
Network evidence is similarly contextual. A route observation can show that a prefix was announced, but not by itself whether the announcement was authorized. An RPKI object can strengthen an origin claim, but absence may reflect non-adoption rather than fraud. An address-use report can describe configured infrastructure while missing shared systems or future deployment. Each source answers a different question.
Machine-readable policy should therefore include an evidence model, not merely a Boolean expression. For each material fact, the public documentation should state which source types are normally accepted, how conflicts are handled, how current the evidence must be, and when an alternative can be considered. The engine may rank evidence operationally, but the governing principles of that ranking cannot be proprietary.
Input provenance must also be intelligible to the applicant without exposing security-sensitive collection methods. A decision can say that the organization name did not match the current record of the identified public register. It need not disclose an anti-fraud detection threshold. A transfer can be paused because claimed authority conflicts with an existing verified contact. It need not reveal how suspicious account behavior is scored.
This distinction answers a common objection to transparency. Public rules do not require publication of every defensive signal. They require disclosure of the legal or policy condition, the ordinary evidence route, the fact relied upon in the applicant's case and the means of correction. Secret risk indicators may decide that more verification is needed; they should not become an unreviewable basis for permanent denial.
Ambiguity cannot be compiled away
Policy text often contains terms such as reasonable, current, operational, sufficient, demonstrated or exceptional. These words are not drafting failures in every case. They can preserve proportionality where circumstances vary. Encoding them requires a choice among narrowing the term, representing a range, or sending the case to a person.
The dangerous option is false precision. A developer may turn "recent evidence" into a fixed number of days because the software needs a value. The number then governs even though the community never adopted it. A request submitted one hour outside the window fails identically to a document years out of date. The hidden implementation choice has amended the policy in effect.
A better design marks the boundary. The public rule can state that a document within a defined safe period is automatically accepted, a document beyond a longer outer period is normally rejected, and the interval between them receives contextual review. This bounded discretion is visible and measurable. It avoids forcing every case through a person while preserving judgment where the adopted text actually requires it.
Ambiguity should also trigger feedback to rulemakers. If a large share of cases repeatedly requires interpretation of the same phrase, that is evidence that the rule is poorly specified or that reality has changed. The institution should publish the exception rate and ask whether the community wants a clearer standard.
The machine-readable representation can help here by recording which branch produced escalation. Aggregate reports can show that a particular evidence rule generated delay across several jurisdictions or that one exception was invoked frequently. These data allow reform based on observed administration rather than anecdote.
No engine should be permitted to invent a value merely to avoid an unresolved state. Unknown, conflicting and not applicable are distinct conditions. Treating all three as false is a common engineering shortcut with substantive consequences. A mature rules service must preserve uncertainty and route it deliberately.
Reasons must be more useful than status codes
Technical status codes are necessary for software clients. They are limited public evidence for institutional decisions. A 400 response may mean malformed syntax, invalid evidence or a failed substantive condition. A 403 may indicate lack of account authority, a legal restriction or a temporary security hold. The applicant needs to know which problem exists and what can be done.
Canada's Directive on Automated Decision-Making offers a relevant benchmark even though regional registries are not Canadian departments. It covers systems that assist as well as replace human decision makers. It requires an impact assessment before production and, at higher impact levels, meaningful explanations of principal factors and recourse options. The associated scope guidance makes clear that rules-based systems can fall within automated decision controls; advanced machine learning is not required.
For a registry, a useful decision receipt should include the request type and outcome; the stable citation for each controlling policy provision; the effective rule version; the material facts accepted; the condition that passed, failed or remained uncertain; any exception considered; the date of decision; and the available correction, review and appeal routes. A public decision reference should allow later retrieval without exposing unrelated account data.
Reasons should be layered. A software client can consume structured reason codes. A network operator should receive concise technical detail. A board, court or independent reviewer may need the full record. The same underlying decision should support all three views rather than generating unrelated explanations after a dispute begins.
Reasons must also survive staff involvement. "Manual review completed" is not an explanation. If a person overrides an automated result, the record should identify the policy basis and material evidence. If a person confirms it, the applicant should know what was considered. Human intervention without reasons merely moves opacity from code to correspondence.
The discipline benefits the registry too. Clear reasons reduce repetitive questions, reveal defective rule branches and make appeals more focused. They also distinguish a defensible refusal from a service failure. An institution confident in its rule should be able to explain it without disclosing defensive secrets.
One authoritative rule needs two readable forms
Machine-readable policy raises a question of authority. Is the executable version merely an aid, or does it have equal status with the human-readable text? The answer cannot be left to implication.
The safest initial model is asymmetric. The community-adopted human text remains controlling. The executable expression is an official implementation that must trace each condition to that text. If a conflict appears, the human text prevails and the executable version is corrected. This avoids an accidental transfer of authority to maintainers of the software.
Over time, communities may choose co-authorship, developing the text, decision model and executable expression together. New Zealand's Better Rules work suggests why parallel development can reduce translation error. Equivalent authority, however, requires a public procedure for resolving divergence. It must be clear whether a change to a data definition is editorial, operational or substantive. A supposedly minor technical edit can alter eligibility.
Stable identifiers are essential. Paragraph numbers that change whenever a document is reformatted are weak anchors. Each rule, definition, exception and evidence requirement should have a persistent reference that survives editorial movement. The executable branch should point to it. Test cases should point to it. Decision receipts should point to it.
ARIN's Number Resource Policy Manual already demonstrates the value of explicit versions and a change history. ARIN's public policy pages state that anyone may participate and that the manual is updated when new policy is implemented. RIPE documents similarly preserve named versions in a public store. Machine-readable policy should extend this documentary discipline rather than replace it.
No unpublished staff interpretation should silently alter an executable condition. Operational guidance can explain how evidence is assessed, but a recurring interpretation that changes outcomes should be surfaced for public review. Otherwise the official rule becomes ceremonial while the effective rule lives elsewhere.
Version proof is part of due process
Publishing the current code is not enough. An applicant challenging a decision made months earlier must be able to establish which rule set actually ran at that time. A repository history can show what was written, but not necessarily what was deployed.
Each release should therefore produce a signed manifest containing the rule-set version, stable policy references, effective interval, test-suite version, executable digest and service build. The decision receipt should include the relevant public release identifier. The registry should retain old releases and a reproducible method for running disclosed test cases against them.
Deployment should be atomic from the applicant's perspective. If different data centres or service channels run different policy versions, that state should be detectable and brief. A request should not succeed through one interface and fail through another because a gradual release is invisible. If staged deployment is necessary, consequential decisions made during the stage should be reviewable under the applicant-favouring valid interpretation where outcomes conflict.
Emergency changes need special treatment. A security defect may require rapid suspension of an interface or a narrow defensive check. The registry should record the authority, scope, start time and review deadline. Emergency power should not become a route for changing substantive eligibility without community authority.
Version proof also protects operators who automate their own interactions. If a registry publishes a future effective version and machine-readable test cases, a member can update systems before the change. A breaking change should have a declared transition period unless immediate protection is necessary. Compatibility is not merely a developer convenience; it affects equal practical access to registry services.
The standard should be verifiability, not trust in a status page. A third party should be able to compare a decision's release identifier with the public manifest and confirm that the cited policy version was in force. This is a modest cryptographic use with substantial institutional value.
Test cases should be public constitutional evidence
Software teams use tests to prevent regressions. Policy communities can use them to define expectations. A public suite of cases can state that a particular combination of facts should be accepted, refused, or sent for review. Boundary cases can show how dates, hierarchy, evidence conflicts and exceptions behave.
Tests should be proposed alongside policy changes, not written only after adoption. This forces authors, affected operators and implementers to confront concrete consequences. A sentence that attracts consensus in the abstract may produce disagreement when applied to a cross-border transfer, a public institution, a small operator or an inherited registration.
The tests must include more than ordinary success. They should cover malformed inputs, missing evidence, contradictory authoritative sources, partial outages, old versions, revoked authority, appeal corrections and cases where no automatic answer is permitted. They should also include examples from all service regions and legal forms represented in the registry's actual membership.
Synthetic cases protect privacy, but historical distribution should guide their design. If most real exceptions involve name changes, mergers or jurisdictions without accessible corporate interfaces, the suite should reflect those conditions. Publishing only clean examples creates a false impression of determinism.
Changes in outcomes should be summarized before deployment. If a proposed version turns a previously reviewable class into automatic refusal, the community should see how many recent cases would have been affected. This retrospective simulation is not a binding forecast, but it provides evidence about reach and risk.
Tests must not expose anti-fraud tactics in a way that enables evasion. Public cases can define legitimate routes and ordinary evidence while sensitive detection controls remain separately assessed. The final entitlement decision, however, must still rest on a public rule. A secret signal may require additional verification; it should not create a secret category of ineligible member.
Human review must be real, not ceremonial
Adding a person at the end does not automatically cure automated discretion. If the reviewer sees only the engine's score, lacks authority to change the result or is measured on agreement with it, the human is a confirmation device.
Meaningful review requires access to the applicant's evidence, the controlling policy, the machine-readable branch, the reason record and the power to seek clarification or decide differently. The reviewer should state an independent reason. Cases should be assigned with enough time to examine them, and applicants should be able to submit evidence in an accessible form rather than only through the failed automated channel.
Appeal should be institutionally separate from initial configuration. A rules engineer or operational manager may explain how a result was produced, but should not be the final judge of whether the interpretation was proper. Depending on impact, the second level could be a different registry team, an independent review panel or a community-defined appeal body.
The RIPE PDP's public appeal provisions concern policy development rather than individual service decisions, but they embody a useful principle: disputed exercises of authority need a documented route beyond the original decision maker. The same logic applies when software mediates access to number-resource services.
Time matters. A transfer, route-security change or account recovery can lose value during a long review. Service standards should distinguish ordinary clarification from urgent continuity cases. Temporary protective measures should preserve the registry state without prejudging ownership. Fast review should be available where delay itself creates operational harm.
Appeal results should feed back into rule maintenance. If reviewers repeatedly overturn one branch, the registry should suspend or amend it. Publishing aggregate reversal rates by rule version and reason category lets members distinguish isolated error from systematic defect.
Vendor engines cannot become a private constitution
A registry may buy a commercial decision engine, verification service or policy-management platform. Procurement does not transfer accountability. The registry remains responsible for the rule, evidence and outcome.
Proprietary systems create several risks. A supplier may encode conditions in an inaccessible language, change components without adequate notice, retain decision data, restrict independent testing or make migration expensive. A model may combine rules with statistical risk scores so that the public institution cannot fully reproduce a result. A service outage can halt decisions across the region.
Contracts should therefore require export of rules, tests, decision records and configuration in documented formats; advance notice of material changes; independent security and fairness testing; defined retention and deletion; continuity arrangements; and assistance with migration. The registry must be able to operate a reduced manual service if the supplier is unavailable.
No vendor confidence score should be a final policy ground. It can trigger additional evidence or review. The final decision must identify a condition that the community authorized and facts that can be contested. If the registry cannot explain the supplier's contribution, it should not use that contribution to deny a request.
The United Kingdom's Algorithmic Transparency Recording Standard provides a useful disclosure model. It asks public bodies to describe how and why an algorithmic tool supports decisions, and mandatory scope covers tools with significant influence on decisions with public effect. A registry transparency record should go further for entitlement decisions by linking the exact rule release and appeal evidence, but the principle of a public system-level account is sound.
Supplier diversity is not enough if every supplier relies on the same closed identity, data or hosting service. Concentration should be assessed by dependency, not contract count. The institution needs a tested exit, not merely a second logo on a procurement list.
Transparency and anti-gaming can coexist
Opponents of public executable rules may argue that applicants will optimize submissions to pass the tests. That concern is strongest where a registry detects fraud. It is weak where the rule defines legitimate eligibility. A person should be able to organize a transaction to comply with a public rule; that is what a rule is for.
The key distinction is between entitlement criteria and detection methods. The requirement that a requester possess authority, provide current evidence or meet a transfer condition should be public. The exact signal that identifies a stolen account need not be. A risk system can pause a request and ask for stronger proof without declaring the applicant substantively ineligible on a hidden basis.
There is also a danger in overstating secrecy. Inconsistent or unexplained administration creates its own attack surface. Operators develop informal knowledge, intermediaries sell access and well-connected members learn which wording succeeds. Public rules reduce the advantage of private familiarity.
Rate limits, authentication requirements and defensive responses can remain protected within reason. RDAP already demonstrates how structured notices and redaction markers can tell a client that data has been limited without exposing everything. Comparable discipline can indicate that a request requires enhanced review while preserving the defensive detail.
Transparency should be threat-modelled. Publish what an honest applicant needs to understand and challenge a decision. Withhold the narrow information whose release would materially enable abuse. Record every withholding category, authorize it explicitly and subject it to independent review. "Security" should never be a universal explanation.
Outcome data reveal the effective rule
Documentation shows intended operation. Aggregate decisions show actual operation. A registry committed to accountable automation should publish enough outcome data to test whether the effective rule matches the public one.
Useful measures include request volumes by type; automatic acceptance, clarification, review and refusal rates; median and upper-percentile decision times; the most common reason categories; exception frequency; human override rates; appeal volumes and outcomes; version-related incidents; service availability; and the distribution of cases across organization size and jurisdictional evidence types. Small cells should be suppressed or combined to protect confidentiality.
These measures need interpretation. A high acceptance rate can reflect clear rules or weak controls. A low appeal rate can reflect accuracy or inaccessible review. Faster decisions can result from better automation or premature refusal. The registry should publish definitions and invite independent analysis rather than selecting one flattering indicator.
Reason codes must remain stable enough for comparison. If categories change, a crosswalk should preserve the series. Version changes should be marked so observers can identify discontinuities. Data should distinguish a withdrawal by the applicant from a refusal by the registry.
Qualitative review still matters. A sample of decisions should be examined for explanation quality, appropriate evidence, proportionality and consistency with adopted policy. Independent reviewers should be able to reproduce a sample using the retained rule release.
The public record should include failures. If a release produced wrong results, the registry should state the affected interval, decision classes, correction and notification method. Quietly replacing code destroys the evidence needed to learn and contest.
Some boundaries should remain deliberately non-automatic
The pressure to automate tends to expand once the easy checks are complete. A service that calculates dates accurately is asked to evaluate evidence. An evidence classifier is asked to recommend refusal. The recommendation becomes the default, and the default gradually becomes final. Preventing that progression requires explicit boundaries adopted before convenience erodes them.
One boundary is a genuine conflict about holder authority. Where two plausible parties claim control of the same registration, the task is not merely to compare document scores. Corporate succession, contract history, previous contacts, court orders and possible fraud may need to be reconciled. Software can organize the record and identify inconsistencies. It should not select the legitimate holder without accountable human reasons and access to review.
A second boundary is adverse action based principally on protected or undisclosed intelligence. Security systems can identify suspicious behavior and impose a temporary hold. Permanent refusal, termination or reassignment should require evidence that can be disclosed at least in substance to the affected party and tested by an independent reviewer. Otherwise the right to appeal exists only on paper.
A third boundary is creation of a new substantive exception. An engine may encounter a case outside every branch. The correct result is unresolved and escalated, not whichever outcome appears safest to a developer. Staff may use an existing public discretion to decide the case, but a recurring class needs community clarification rather than accumulation of private precedent.
A fourth boundary is retrospective change. A new rule release should not silently alter the status of completed transactions or reinterpret historical compliance unless the controlling policy expressly provides for that effect. The engine can flag records for review. It cannot manufacture retroactive authority from a current version.
A fifth boundary is service termination where continuity is at risk. Ending access to registration or route-security functions can affect parties beyond the member. Automation may enforce notice periods and identify unpaid amounts, but final action should confirm authority, proportionality, pending disputes and the safe handling of dependent records.
These boundaries need not force slow administration. A registry can define urgent review rosters, standard evidence sets and maximum response times. It can use structured decision support and publish anonymized precedents. The point is that a person or panel accepts responsibility for the judgment rather than attributing it to the system.
The boundary list should be reviewed publicly each year. New technology may make one fact easier to establish reliably. New abuse may require additional temporary controls. But moving a decision from human responsibility to automatic finality should be treated as a governance change, supported by evidence and subject to member scrutiny.
There is a corresponding obligation not to use human review as a hiding place. Decisions reserved for people still need reason codes, policy citations, time limits and appeal. The distinction is not transparent machines versus unrecorded judgment. It is deterministic execution where the rule truly determines the answer, and accountable judgment where it does not.
Distributional testing belongs before release
Rule correctness is not established by passing ordinary examples. A condition can be logically faithful and still impose unequal practical burden because its inputs are easier for some members to produce. Before release, the registry should examine how the new version behaves across organization size, legal form, service region, language, resource type and interaction channel.
The test should ask more than who is accepted. It should measure who receives immediate completion, who is asked for clarification, who enters human review, how long each path takes and which evidence causes failure. A version that preserves final acceptance rates while doubling delay for small operators has changed access materially.
Historical replay can provide a baseline if privacy is protected. Recent cases can be reduced to relevant attributes and run against the proposed rule. Synthetic cases can then explore rare but important boundaries. The analysis should state its limits: past requests may not predict behavior after applicants adapt, and historical data may reflect old biases.
Members should see a concise release impact statement. It should identify changed branches, affected request classes, expected operational effects, unresolved uncertainties and monitoring commitments. The institution should name a review date and a threshold that would trigger rollback or correction.
This discipline protects innovation. A registry can deploy a useful rule with uncertainty if it limits exposure, observes results and retains a reliable reversal path. What it should not do is convert uncertainty into silent risk borne entirely by applicants.
What NRS can advocate, and what registry operators must execute
The institutional case NRS advances is a narrower, more accountable registry role. NRS can research how durable registry functions should be bounded, document member experience with automated decisions, convene affected operators and campaign for rules that make administration predictable and contestable. It does not record recognized authority, maintain the authoritative registration database, support routing attestations, execute transfers or preserve operational continuity. Those acts remain with the competent RIR, IANA where its defined coordination role applies, other lawfully authorized registry-service operators, courts and independent review bodies.
Each RIR or other authorized operator should publish a rule catalogue that maps every automated decision to community authority. The operator can offer a sandbox in which members evaluate hypothetical requests without creating legal or operational effects; the production operator, not NRS, must issue signed decision receipts, retain historical releases, run deterministic validations and reserve qualified staff for evidence conflicts and exceptions. NRS may evaluate those public materials, collect authorized member testimony and publish comparisons, but an NRS report is not a registry decision or a substitute for operator evidence.
It should not use automation to revive expansive needs assessment or industrial planning. Code does not make subjective forecasts objective. An executable demand model can still privilege incumbents with better documentation, penalize unfamiliar architectures and turn uncertain business plans into false numerical precision. The most automatable institution is often the one with the narrowest mandate.
Membership accountability remains necessary. Members should approve the budget and risk appetite for decision automation, receive independent assurance reports and be able to require review of a high-impact rule. Technical communities should participate in tests and definitions, while affected non-members should have a practical way to report defects.
Authorized operators should also preserve replaceable implementation. Open rule formats and public tests allow multiple clients and independent evaluators. A holder should not need proprietary software to understand eligibility. The decision service itself should be replaceable without changing policy, but replacement authority must come from the competent registry, lawful appointing instrument or court—not from NRS advocacy or member representation.
This is positive institutional design, not faith in technology. It uses software where repetition and exactness are virtues, and keeps public judgment where evidence and proportionality matter.
A credible path from 2024 to 2030
The period from 2024 to 2030 should be treated as a sequence of increasing assurance, not a race to remove staff. The first stage is inventory. Registries should list consequential automated checks, identify their authority, classify their degree of judgment and publish the interfaces that affect members.
The second stage is traceability. Every existing deterministic check should map to a stable policy or technical-integrity reference. Error responses should distinguish syntax, authority, evidence and substantive conditions. Current rule releases should receive public identifiers.
The third stage is co-development. New policies suitable for execution should include decision models, examples, boundary cases and implementation analysis during public discussion. Communities should review changes in outcomes before effective dates. Human text and executable expressions should be published together.
The fourth stage is contestability. Consequential decisions should carry structured receipts. Enhanced human review and independent appeal should be tested for time, accessibility and authority. Aggregate reversal and exception data should be published.
The fifth stage is verifiable operation. Signed release manifests, reproducible tests, historical retention and independent deployment checks should connect each decision to the rule that actually ran. Supplier exit and reduced manual continuity should be exercised, not merely documented.
By 2030, success should not be measured by the percentage of decisions made without a person. It should be measured by fewer inconsistent outcomes, shorter correction times, clearer reasons, lower avoidable appeal, demonstrable rule fidelity and resilience when a service or supplier fails.
The warning signs
Several signals would show that machine-readable policy is becoming automated discretion. The first is a growing gap between public text and operational reasons. If applicants receive generic refusals that cannot be traced to a stable clause, the effective rule is hidden.
The second is exception accumulation. A large private guide used to work around rigid code means the formal representation is incomplete. The remedy is not to conceal the guide but to review the rule and expose legitimate exception categories.
The third is provider dependence. If the registry cannot reproduce a decision without a supplier, cannot export history or cannot operate during an outage, public authority has become contingent on a private service.
The fourth is declining human independence. Very low override rates combined with repeated successful appeals may show that first-level reviewers are deferring to the engine. Review quality should be tested directly.
The fifth is unstable versions. If an applicant cannot establish the effective rule date, or if two channels produce different results, formal publication has lost contact with operation.
The sixth is uneven burden. Longer times, higher clarification rates or more failed verification for certain jurisdictions, organization sizes or technical models may indicate that input design privileges the easiest data environment. Such differences need investigation, not automatic accusations, but they cannot remain invisible.
Consistency is valuable only when the rule is accountable
Machine-readable policy can improve number-resource administration. It can remove repetitive clerical variation, identify contradictions, support pre-submission testing and make rule changes measurable. Existing RIR interfaces and standardized registration responses show that structured automation is technically ordinary.
The hard problem is institutional. Code can enforce a public rule consistently, or it can conceal how evidence, exceptions and release choices determine access. The difference lies in authority, traceability, reasons, review and version proof.
A responsible registry should never ask members to trust that the current service implements the current policy. It should let them verify the connection. It should never treat a machine result as self-explanatory. It should state the material facts and controlling condition. It should never advertise human oversight that lacks power to change an outcome. It should provide review with authority and appeal with independence.
NRS's contribution is compatible with disciplined automation precisely because its role is non-operational: it can campaign for public rules, collect member evidence, compare outcomes and represent members that have granted it authority in RIR governance. The RIRs and other authorized operators remain responsible for every routine execution, transfer recognition, authoritative record and routing-security action. That separation can reduce dependence on informal staff judgment without inventing a new NRS rules engine or service mandate.
The governing principle is simple: automate the application of rules, not the ownership of discretion. Where judgment remains, name it. Where code decides, publish and version it. Where a decision harms an applicant, explain it. Where the institution may be wrong, preserve a human route to correction. That is how machine-readable policy can reduce arbitrary government rather than hide it.