Summary

  • .NGO and .ONG were not made “verified” by branding alone. The operative authority came from two Registry Agreements, Specification 12, ICANN’s Registry Services Evaluation Policy process, Board approval, contractual amendments and the Registry-Registrar Agreement that placed evidence collection and lifecycle execution into registrar processes.
  • The original system deliberately separated creation from final documentary validation. A registrant could pass an initial certification and obtain a name, yet failure to complete the additional step could produce deletion and release. From late 2014 until the later unbundling, the matching label in .NGO and .ONG was also designed as one technical bundle, so specified commands and registry decisions were correlated across both namespaces.
  • The 2022 contractual change removed the coupling clause from each TLD agreement, allowing separate registration and lifecycle control. It did not remove Specification 12 or transfer final eligibility authority to registrars. The 2014 text separately named a use-focused RDRP with a stated appeal, while section 2.19 incorporated the RRDRP for operator-level non-compliance; neither source establishes a published individual eligibility-audit merits appeal, automatic stay or restoration route after release.

Three texts, one enforcement problem

The most revealing account of .NGO/.ONG does not begin with a launch event or a claim that a trusted online home was created for civil society. It begins with three operative texts that allocated risk differently over time.

The first is Specification 12 to the 6 March 2014 .NGO Registry Agreement. Its original validation design allowed a domain to be created once the applicant’s initial certification was confirmed. Documentary validation continued afterwards. If the registrant did not provide the additional information required in the second step, the specification directed that the domain be deleted and released. Verification was therefore not merely an admission test before use. It was a continuing condition attached to an identifier that could already have entered service.

The second is former Exhibit A, section 5, added through the 2014 contractual amendment. The clause, reproduced in the later .NGO Amendment No. 2, treated the corresponding labels in .NGO and .ONG as a bundle. It required the operation of the two TLDs to be identical for the bundled name and stated, in broad terms, that services, actions, changes, decisions and requirements affecting one were to apply to the other. A transformation command sent for one label was to be applied across the bundle and succeed only if it succeeded for all relevant objects. The matching names were distinct registrations in separately delegated TLDs, but the contract made their ordinary lifecycle interdependent.

The third text is Amendment No. 2 itself. The .NGO instrument and its separate .ONG counterpart deleted section 5 in its entirety while leaving the rest of each Registry Agreement in force. The coupling was removed; the community registration restrictions were not.

That distinction is the case. Before unbundling, eligibility enforcement and technical lifecycle control were layered. Specification 12 supplied the community rules and sanctions. The bundle made specified consequences capable of propagating across the matching label in both namespaces. After unbundling, the second layer was removed, but Public Interest Registry retained the contractual role of defining operational validation requirements and deciding whether a registration satisfied them. The reform changed the radius of a lifecycle action, not the underlying allocation of eligibility power.

A fourth document explains why deleting one clause required more than a pricing-page change. In its 2021 request to unbundle the TLDs, Public Interest Registry said that both DNS zones were then produced from a single .NGO registry. Separation required an independent .ONG registry, the seeding of data into it, new testing and a transition in which future commands could return different results for the two strings. Contract, evidence and infrastructure had been deliberately coupled. Undoing the arrangement therefore required a contractual change-control process and an operational migration.

The status ladder: application, contract, service approval and delegation

The institutional history matters because each stage did something different. An application could describe a proposed service, but it did not itself authorise operation. A signed Registry Agreement created enforceable obligations between ICANN and the operator, but it did not by itself place the TLD in the root. Approval of an additional registry service authorised the bundle, but the approval had to be translated into contract text and downstream registrar duties. Delegation then made each TLD technically present in the DNS root.

Public Interest Registry’s .NGO application attachment is useful as proposal-stage evidence. It records what the applicant said it intended to build and how it expected registry and registrar systems to operate. It cannot prove that ICANN accepted every proposal, that the service was contractually binding, that registrars implemented it, or that a particular enforcement action occurred. Those conclusions require later instruments.

The legal operating base arrived through two agreements dated 6 March 2014. ICANN’s official .NGO agreement record identifies Public Interest Registry as the operator and classifies the TLD as a community registry subject to Specification 12. The parallel .ONG agreement record confirms a separate contract for the other string. The paired marketing concept did not collapse the TLDs into one legal object.

The executed agreement also reserved a gate for services not already approved. Section 2.1 required the operator to use the Registry Services Evaluation Policy, or RSEP, before offering an additional registry service outside the approved description. ICANN could approve the service in writing and could require an amendment. Section 2.9 required registrations to be made through ICANN-accredited registrars under a uniform Registry-Registrar Agreement. Section 2.19 made the community registration policies enforceable and subjected the operator to the restrictions-dispute process.

Together, those provisions established a chain: operator proposal, ICANN change review, contract amendment where required, registrar implementation and continuing compliance.

Delegation was separate again. IANA’s root-zone records show that both TLDs were entered in the root on 10 July 2014, but they have separate delegation records: the .NGO record links a delegation report dated 16 July, while the .ONG record links one dated 23 July. Public Interest Registry is listed as sponsoring organisation for each. These records establish technical delegation; they do not decide whether an individual organisation qualifies as an NGO, nor do they prove that the later bundle had been approved. The bundle followed its own RSEP and Board path.

This status ladder prevents a common institutional shortcut. The application was not the contract. The contract was not delegation. Delegation was not approval of every later service. Approval of the bundle was not implementation until the agreement and registrar terms were changed. Nor did public consultation become decision power merely because comments were invited. At each stage, a different actor held a different key.

Specification 12 as an executable eligibility constitution

Specification 12 converted the idea of an NGO community into contractual conditions for registration, naming, use and enforcement. It did more than state an aspiration. It identified who had to qualify, constrained the relationship between a name and the registrant, authorised audits and attached sanctions to non-compliance.

Under the executed .NGO agreement, every registrant had to demonstrate an affiliation with or status as a non-governmental organisation. Public Interest Registry was to work with relevant membership organisations, an advisory council and the broader NGO community. That language supplied channels for expertise and participation. It did not give those participants a vote over an individual validation result, a veto over registry policy or authority to direct ICANN’s contractual response. The operator remained responsible for applying the restrictions; ICANN remained the counterparty able to enforce the agreement.

The specification also constrained the label selected. A registrant could use its legal name, a name under which it did business, an acronym, a term closely connected with the organisation or a term reasonably related to its mission. Use had to be bona fide, consistent with the NGO purpose and not solely commercial, illegal or fraudulent. The rules therefore addressed both identity and conduct. An organisation could present documents suggesting NGO status yet still face a use-related question if the name or its operation fell outside the contractual restrictions.

The original two-step process is especially important. Step one was an initial certification sufficient for creation. Step two required additional information. Failure to complete it resulted in deletion and release. That design placed speed before final documentary closure. It reduced the delay between application and creation, but it shifted some verification risk into the period after the identifier could be configured, promoted or relied upon.

The enforcement provisions reinforced that temporal choice. Public Interest Registry was to conduct proactive checks at registration and reactive enforcement through audits and disputes. The specification authorised random audits concerning membership, name selection and use. When the operator concluded that a registration did not comply, it was to notify the registrant and place the name under registry lock. If the problem was not cured, the registration could be terminated.

The contract therefore distributed enforcement across a sequence rather than a single admission event: certification, creation, evidence review, notice, lock, opportunity to cure and termination.

That sequence did not make every stage equally contestable. A registrant could participate by submitting information and attempting a cure. A registrar could transmit evidence and execute lifecycle commands. Community organisations could contribute knowledge about eligibility standards. None of those functions necessarily carried final decision authority. The operative specification placed enforcement responsibility with the registry operator, subject to ICANN’s contract and the dispute mechanisms designed for registry restrictions.

The current policy should not be projected backwards without qualification. Public Interest Registry’s present .NGO/.ONG registration and validation policy lists seven criteria, including public-interest orientation, a non-profit focus, limited government influence, independence, active operation, organisational structure and lawful conduct. It also contains jurisdictional and sanctions-related restrictions. The located primary record does not provide a complete dated version history showing when every criterion, complaint trigger, active-DNS expectation or sanction entered the policy. The safe conclusion is narrower: the 2014 contract established enforceable NGO eligibility and continuing validation; the current policy shows how Public Interest Registry now states and administers that authority. The precise continuity of each operational detail remains to be documented.

Bundling turned two names into one lifecycle machine

The additional registry service proposed in 2014 was not a loose sales package. The RSEP request for the mandatory technical bundle described linked registry behaviour for identical second-level labels across .NGO and .ONG. A registrant acquiring one would receive the matching name in the other. The same registrar would sponsor both. Core contact data, registration and expiry dates, status information and grace-period behaviour would be synchronised, subject to limited technical exceptions.

The proposal specified command-level effects. A domain availability check on one string was to reflect the status of the pair. A create command was to create both objects. Updates to contacts, name servers, status and authorisation information were generally to apply to both. Renew, delete, restore and transfer operations were likewise coupled. DNSSEC data could remain distinct, and later contract text also allowed nameserver information to differ, but the ordinary lifecycle was designed to move together.

That architecture mattered because registrars are not passive storefronts. They translate customer instructions into Extensible Provisioning Protocol, or EPP, commands sent to a registry. A conventional registrar system expects each TLD object to have its own availability, dates, contacts and state transitions. The bundle inserted a rule that a command addressed to one namespace had to create or transform the paired object as well. It also had to handle failure atomically: the contractual clause later required success across the relevant objects rather than a half-completed bundle.

Public Interest Registry offered a policy justification. Its request said NGOs had expressed concern about the cost and confusion of defensive registrations, and that bundling would allow an organisation to secure both linguistic forms through one transaction. It also said registrars had been consulted and that no objections were expected. Those statements show the operator’s case for the service. They are not independent evidence of the breadth of NGO demand, the representativeness of consultation or the absence of implementation costs. The later unbundling request would report precisely such costs.

The broadest legal expression of the bundle appeared in former Exhibit A, section 5. As reproduced in the .NGO unbundling amendment, the clause applied whether a name was withheld, allocated, activated or in another status. It required consistent treatment across the two TLDs and made Public Interest Registry solely responsible for maintaining that consistency. It extended more than customer-facing registration. The provision linked services, registration policies, transaction accounting, data escrow, registrar authorisation, emergency-transition obligations, remedies and Specification 12. A failure to maintain consistency could be treated as a compliance issue affecting both agreements.

This is why the bundle increased correlated exposure. Under the original Specification 12, failure to complete the second verification step expressly led to deletion and release, while a later audit finding followed a different path of notice, registry lock, an opportunity to cure and possible termination. Former section 5 required relevant actions, decisions, remedies and Specification 12 policies to operate across the TLD bundle. During the bundled period, the contract therefore created a path by which an eligibility-enforcement event affecting one matching label could affect both identifiers.

The available primary materials establish that legal and technical possibility. They do not identify a named registrant whose two domains were in fact locked, terminated, deleted or released together. Contractual exposure must not be presented as a documented incident.

Who actually approved the service

The 2014 RSEP process shows how participation, technical advice and decision power were segmented. According to ICANN’s 9 September 2014 Board resolutions, Public Interest Registry submitted the request in March and ICANN posted it publicly in May. Staff’s preliminary review found no significant competition issue but identified a possible security or stability question, causing referral to the Registry Services Technical Evaluation Panel, or RSTEP.

RSTEP’s role was limited. It examined whether the proposed bundle created a reasonable risk of a meaningful adverse effect on DNS security or stability. Its report did not confer contractual authority by itself. It found no such risk, while identifying implementation questions: the possibility of future unbundling, potential confusion because web and email applications would not automatically treat the two domains as equivalent, and the danger that the service could be misconstrued as a precedent for treating non-identical strings like formally managed IDN variants.

The public could comment on the proposal and on the technical report. ICANN recorded no comments. That absence is relevant to the procedural record, but it is not a vote, a waiver by every affected organisation or proof that the service was operationally sound. Consultation widened participation. It did not displace the Board’s authority.

The Board exercised that authority through two linked resolutions. Resolution 2014.09.09.05 approved the proposed registry service. Resolution 2014.09.09.06 authorised the President and CEO, or designee, to develop and execute amendments addressing implementation questions. The Board also made clear that its approval did not establish a precedent for IDN variants. Technical advice narrowed the risk question; staff administered the process; public commenters had an opportunity to supply information; the Board made the operative approval decision.

The contrast with the operator’s initial expectation is instructive. The RSEP request indicated that no Registry Agreement amendment was anticipated. The Board nevertheless authorised one, and .NGO Amendment No. 1, together with the parallel .ONG instrument, memorialised the bundle in December 2014. An applicant or operator can propose how a change should be classified. ICANN controls whether the service requires contractual text and the conditions on which it can proceed.

The registrar contract made the design executable

Board approval and an amendment would still have been incomplete without registrar obligations. Registrars held the customer relationship, took the registration request, obtained assent to policies, collected evidence and sent the commands that created or transformed the name. Public Interest Registry’s 2014 .NGO/.ONG Registry-Registrar Agreement converted the registry-level design into those downstream duties.

The agreement defined a “Registered Name Bundle” and required the identical label to be allocated simultaneously in the other TLD. It required the registrar to display or link the applicable policies and obtain the registrant’s affirmative acceptance. It prevented a registrar from carrying out a procedure on one registration unless the corresponding procedure was performed on its counterpart. It also recognised validation requirements established by Public Interest Registry and allocated first-line customer support to the registrar while the registry supported the registrar.

This division of labour is easy to misstate. The registrar was an implementation and evidence channel, not the source of NGO status. It could ask the customer for documents, verify that fields were supplied, explain the policy and transmit commands. Public Interest Registry reserved authority under the agreement and incorporated policies to deny, cancel, transfer, lock or place a hold on names in specified circumstances, including validation. The registrant supplied facts and accepted the contractual rules. The registry made the substantive eligibility determination.

The 2014 agreement also aligned commercial and technical incentives by charging one fee for the bundle. That reduced the customer-facing cost of securing both labels, but it required registrars to support a non-standard paired process. The later evidence about low uptake and misconfiguration came from Public Interest Registry, not from an independent audit, yet it is plausible that a special command path imposed costs on registrars whose systems were designed around one registration object at a time. The important governance point is not whether the burden was inevitable.

It is that the contract placed it on registrars as the price of making the policy executable.

The post-unbundling Version 2022 Registry-Registrar Agreement retains the policy-enforcement allocation while removing the paired lifecycle rule. Registrars still must present relevant policies and obtain assent. They remain responsible for customer-facing support. Public Interest Registry retains broad rights to deny, suspend, cancel, transfer, lock or hold registrations under the agreement and its policies. The specific bundle is gone; the registry’s enforcement position is not.

The evidence chain changed, but final authority did not

The original contract and the current public policy describe different operational forms of validation. They should be compared without assuming that one replaced the other on a known date or that every intermediate version was identical.

Under the 2014 Specification 12 design, the applicant first completed an initial certification. Creation followed once that certification was confirmed. The applicant then had to provide additional information. Non-completion led to deletion and release. That model embedded post-creation verification into every registration and made final documentation a condition of continued control.

The current Public Interest Registry policy describes a complaint-triggered audit process. The registrar is notified and asked to collect the organisation’s formal name, country and documentary evidence. The examples include entries in government or other recognised lists, incorporation records and tax-related material. Public Interest Registry also states that it may contact audited registrants through the registration email address. It examines the evidence and may ask the registrar for more. The registrar has 30 days to respond on the registrant’s behalf, although the registry may decide earlier if it considers the available record sufficient. If Public Interest Registry concludes that the registrant is ineligible, the policy says the domain will be deleted and released, without a refund. If the registrant does not respond within the stated period, the name is placed on ServerHold.

The allocation of evidentiary power is therefore layered. Licensing offices, corporate registers, tax authorities or other recognised sources may create the underlying documents. The registrant chooses what to submit. The registrar gathers and transmits the material. Public Interest Registry decides whether it satisfies the policy. A public authority’s document can be decisive evidence without making that authority the decision-maker for the domain. A registrar can control the speed and quality of communications without acquiring the power to redefine NGO eligibility.

The current page does not state that a complainant receives standing to direct the outcome. A complaint appears to trigger the registry’s audit process; it does not convert the complainant into an adjudicator. Nor does the policy page identify an independent merits panel for the registrant. Public Interest Registry verifies, requests more information and makes the eligibility decision. That concentration may produce consistency, but it also means the institution defining operational standards is the institution applying them to individual records.

Several facts needed to evaluate fairness in practice are not public in the located record. There is no complete version history showing when complaint-triggered audits replaced or supplemented the original step-two process. No sample audit notices, evidence requests or reasoned adverse decisions were located. Aggregate figures for audit volume, response time, ServerHold, lock, deletion, release, later re-registration and restoration have not been published in the reviewed sources. Without those records, one can reconstruct formal authority but not measure error rates, cure practice, country effects or the actual frequency of continuity loss.

Hold, deletion and release are different continuity events

The enforcement vocabulary in Specification 12 and the current validation policy describes distinct consequences, not synonyms or a mandatory sequence. A registry lock constrains changes while the registration remains under registry control. ServerHold interrupts the name’s ordinary publication in the DNS while the registration record remains. Deletion ends the registration. Release returns the label to the available pool, exposing it to possible registration by another eligible party. The documents do not establish that every enforcement case passes through every state, and the current policy distinguishes non-response from a finding of ineligibility.

That sequencing matters because the original model allowed creation before final documentary validation. A newly registered identifier could be placed on a website, printed in fundraising material, used for email or given to partners before the evidence question closed. The contract then permitted a later adverse event to affect that identifier. The risk was not simply losing a fee. It was losing continuity after dependencies had begun to form.

Before unbundling, the same risk was correlated across two namespaces. Former section 5 required linked actions and decisions, and the 2014 registrar agreement required paired procedures. A lock, termination or deletion that fell within those linked rules was designed to affect the matching bundle. The arrangement reduced defensive-registration cost at entry, but it also reduced the ability to isolate failure. One special process created both names and could move both through the same adverse lifecycle.

After unbundling, the matching labels can have separate sponsors, data, dates and command results. That makes it structurally possible for one registration to remain while the other is held, transferred or deleted. Public Interest Registry’s current FAQ tells customers that .NGO and .ONG are no longer included in one registration and must be secured separately. The change reduces correlated exposure. It does not guarantee continuity for either individual name because each remains subject to Specification 12 and the registry’s validation policy.

The most serious point is release. A hold can be reversed within the same registration. A deleted and released label may be acquired by someone else, subject to the registry’s eligibility rules. Once third-party rights and use intervene, a simple administrative restoration becomes harder. That is a bounded inference from the published lifecycle rule, not evidence that a particular .NGO or .ONG name was taken by a new registrant after an erroneous deletion. The case-level record needed to test that risk has not been located.

Two review routes, neither a documented audit-restoration appeal

The 2014 agreement identifies two different restrictions procedures, and their names are close enough to invite a consequential mistake. Specification 12 says that an allegation that a domain is not used primarily for NGO purposes is to be enforced under a Restrictions Dispute Resolution Policy, or RDRP. The same sentence says the RDRP would be included as an appendix to the Registry Agreement and that the RDRP contains an appeal. Section 2.19 of the Registry Agreement separately binds the operator to the Registry Restrictions Dispute Resolution Procedure, or RRDRP, which is an ICANN post-delegation mechanism directed at registry-operator compliance. The RDRP and RRDRP should not be collapsed into one route.

The RDRP reference is use-focused. It concerns an allegation about whether a registered name is being used primarily for NGO purposes. The documentary audit described in Public Interest Registry’s current policy asks a different question: whether the registrant satisfies the operator’s eligibility requirements and can support that status with the requested evidence. The contract’s statement that an appeal exists within the RDRP therefore does not, by itself, establish an appeal from Public Interest Registry’s administrative eligibility determination.

An appeal from a use-dispute decision and a merits review of an audit are different institutional objects, even where the underlying facts overlap.

The located agreement text also leaves an implementation gap. It states that the RDRP would be appended, but the public materials reviewed for this article did not reveal a .NGO/.ONG-specific published decision series showing who invoked that route, what evidentiary burden a provider applied, whether filing stayed a registry command or what remedy followed in an actual case. The contract supports the narrower proposition that a use-focused procedure with a stated appeal was contemplated and made part of the enforcement design.

It does not support treating that appeal as a demonstrated route for pausing deletion or restoring a name released after an eligibility audit.

The RRDRP has a more fully specified but different purpose. Its parties are a harmed established institution associated with the defined community and the registry operator; ICANN is not a party. The complainant must establish standing, identify the community restriction allegedly breached, prove that the operator violated the Registry Agreement and show measurable harm. The burden rests on the complainant, under the procedure’s stated evidentiary standard. A registrant disputing its own audit result does not become an RRDRP party merely because its name supplied part of the factual background.

The RRDRP panel’s decision power is correspondingly operator-focused. It may determine whether the complaint is founded and recommend graduated remedies aimed at bringing the registry into compliance, suspending new registrations or, in extraordinary circumstances involving malicious conduct, terminating the Registry Agreement. Because ordinary registrants are not parties, the procedure generally bars a recommended remedy that deletes, transfers or suspends their individual registrations, subject to a narrow operator-affiliation exception.

Either RRDRP party may seek the procedure’s de novo appeal on the existing record, with limited scope for older material. That appeal reviews the RRDRP expert determination; it is not an appellate hearing on an individual registrant’s evidence file.

ICANN retains the final contractual lever. The expert determination and any appeal can inform the response, but ICANN decides what remedy to impose against the registry and ordinarily proceeds through notice and an opportunity to cure. This preserves ICANN’s control over its agreement. It also means that a successful RRDRP complaint can alter registry practice without necessarily restoring a released identifier, while an unsuccessful complaint does not validate every individual eligibility decision the operator has made.

The current Public Interest Registry policy page does not identify a named independent merits reviewer for eligibility audits, an automatic stay pending challenge or a restoration process following deletion and release. The Registry-Registrar Agreement gives the registrar a customer-facing support and evidence-transmission role, but it does not convert the registrar into an appellate body. A registrant may communicate with the registrar, supply additional material, contest the operator’s interpretation, seek a qualifying use-dispute route where its terms apply or pursue contractual and legal remedies outside the registry.

The RRDRP itself does not exclude court proceedings. None of those possibilities should be described as an automatic internal remedy unless a source shows who must hear the challenge, what standard applies, whether the lifecycle action pauses and what order can restore the name.

The formal distinction is therefore exact. The RDRP named in Specification 12 addresses use-focused allegations and states that an appeal exists within that procedure. The RRDRP tests systemic or material non-compliance by the registry operator and gives its parties an appeal from the expert determination, while leaving ICANN with ultimate contractual enforcement authority. The located record establishes neither route as an individual eligibility-audit merits appeal carrying an automatic stay and restoration power before or after release.

No .NGO/.ONG-specific published eligibility-audit challenge or enforcement decision was identified in the official materials reviewed. That is a research boundary, not proof that no dispute has occurred. Private registrar correspondence, confidential settlements, unindexed litigation or unpublished operator review could change the practical picture. The absence of a located case record means the article can identify the formal remedy gap but cannot calculate how often it has mattered.

Unbundling required a new registry, not merely a new offer

Public Interest Registry’s 2021 RSEP request framed unbundling as both a commercial correction and a technical migration. The operator said the experiment had produced low uptake, few organisations actively used both names, registrars faced a specialised implementation burden and a 2019 deployment study found that many bundles were not configured correctly. These are material claims because they supplied the case for change. They remain operator-submitted evidence. The underlying study, methodology, raw results and a complete pre- and post-unbundling dataset were not included in the located record.

The architecture described in the request was concrete. At the time of filing, both .NGO and .ONG zones were produced from a single .NGO registry. To separate them, Public Interest Registry proposed creating an independent .ONG registry and seeding it with relevant metadata from .NGO. Most paired fields would initially be copied; unique DNSSEC material would be preserved. After migration, there would be no shared metadata requirement. Registrars could receive different EPP results and manage different contacts, dates, statuses, transfers, renewals and deletions for the matching labels.

The request also contemplated operational testing and notice. An Operational Test and Evaluation environment was to allow registrars to test the separate service. Public Interest Registry proposed at least 90 days’ notice to registrars and communication to affected registrants. At the time of the filing, it acknowledged that it had not yet undertaken specific communications about the proposed change. The process therefore separated approval from implementation planning, just as the 2014 process had.

ICANN’s RSEP status index records both the 2014 technical bundle and the 2021 technical unbundling as approved registry services. The later approval led to separate Amendment No. 2 instruments for .NGO and .ONG. Each deleted former Exhibit A, section 5 and preserved the remainder of the agreement. The post-unbundling registrar agreement no longer contains the mandatory paired-transaction provisions, and current customer guidance treats the names as separate purchases.

The posted amendment copies present a documentary limit. Their effective-date and execution fields appear blank in the versions reviewed. The filenames and posting context place the instruments in 2022, but the available copies do not safely establish the exact date on which both parties executed them or the exact production cutover. Nor were a migration runbook, completed testing record, registrar notices, registrant notices or a formal completion report located. The contract change is documented. The detailed operational history is not.

Unbundling solved a defined problem: one registration no longer had to carry a matching label through the other TLD’s lifecycle. It also removed the contractual rule that decisions and remedies affecting one automatically applied to the other. It did not rewrite Specification 12. It did not make registrars the final eligibility authority. It did not eliminate Public Interest Registry’s power to set validation requirements through operational standards and policies. It did not add a published individual eligibility-audit merits appeal.

The reform should therefore be described as risk separation, not deregulation. A registrant can now choose one string, maintain different data or use the names differently within applicable policies, and avoid an automatic paired command. Each name remains conditional. The operator’s power moved from a coupled object to two independently managed objects.

The holding at 31 July 2026

The enforceable .NGO/.ONG system has passed through three institutional forms. First came the community restrictions and two-step validation contained in the March 2014 agreements. Then came the mandatory technical bundle, approved through RSEP and Board action and converted into contract and registrar duties in late 2014. Finally came the approved unbundling and 2022 amendments, which removed the coupling clause while preserving the underlying agreements.

The durable allocation of power is clear. Public authorities and recognised sources can produce evidence of organisational status. Registrants submit it. Registrars collect it, obtain policy assent, support customers and execute commands. Public Interest Registry defines operational validation requirements and makes the registry eligibility decision. Community bodies can advise, qualifying parties can use the use-focused RDRP where its terms apply, and established institutions meeting the standing test can invoke the operator-level RRDRP. ICANN controls contractual change and ultimate enforcement against the registry.

IANA’s root-zone function records delegation; it does not adjudicate NGO status.

What remains unproven is equally important. The public record reviewed does not show how many names have been audited, held, locked, deleted, released or later restored. It does not expose the reasoning in individual adverse decisions. It does not fix the exact completed migration date or quantify the improvement after unbundling. It does not establish a named individual eligibility-audit appeal with an automatic stay before release, despite the distinct appeals stated within the use-focused RDRP and the operator-level RRDRP.

The strongest conclusion is consequently bounded. .NGO/.ONG became an enforceable registry service because legal agreements assigned evidence and command authority, not because the word “verified” carried self-executing trust. The original bundle amplified that authority across a pair of identifiers. Unbundling reduced the correlation but preserved the validation constitution. The unresolved governance question is no longer whether the two strings must move together.

It is whether a system capable of releasing an organisation’s identifier supplies a sufficiently visible, reasoned and reversible path when the eligibility decision itself is contested.