{
  "vercy": "1.0-draft",
  "publication": {
    "status": "research-draft",
    "adjudicationStatus": "unreviewed",
    "publishableCanonical": false,
    "generatedAt": "2026-09-07T10:12:45Z",
    "providers": [
      "Codex",
      "Grok"
    ],
    "missingProviders": [],
    "pass": 2,
    "cost": {
      "grok": {
        "usd": 0.01256538,
        "turns": 1,
        "seconds": 147.9,
        "error": null
      },
      "codex": {
        "seconds": 83.8,
        "error": "Reading additional input from stdin...\nOpenAI Codex v0.153.3\n--------\nworkdir: R:\\02_PROJECTS\\02_Meta_Models_Platforms\\Ver.cy\\current\\thing-registry-backlog\nmodel: gpt-6-astra\nprovider: openai\napproval: never\nsandbox: read-only\nreasoning effort: none\nreasoning summaries: none\nsession id: 01a07b58-9c30-79f1-befa-e03866f22bd6\n--------\nuser\nYou are drafting a Vercy meta-model for one registered thing. Answer as JSON only, no prose around it.\n\nThing: .us\nRegistry id: vr.tr.us\nPlane / domain: INF / INF.MED\nRegistry definition: (none recorded)\nNames folded into this entry: (none)\n\nA Vercy model says"
      }
    },
    "enrichment": {
      "pass": 3,
      "engine": "claude",
      "producedAt": "2026-10-06T12:00:00Z",
      "ingestedAt": "2026-10-06T08:11:55+00:00",
      "fields": [
        "agent_conduct",
        "ethics",
        "failure_modes_and_hazards",
        "owners",
        "standards_and_regulation",
        "visual_identification"
      ]
    },
    "gate": {
      "passed": true,
      "version": "1.0",
      "at": "2026-10-07T10:10:30+00:00",
      "evidence": [
        "completeness 1.00",
        "sense: Wikidata description",
        "5 live sources",
        "review by codex: pass"
      ]
    }
  },
  "metaModel": {
    "id": "THING-Q37861",
    "registryId": "vr.tr.us",
    "name": ".us",
    "version": "0.1.0-research.1",
    "entryKind": "thing",
    "family": "Thing Registry",
    "domain": [
      "INF.MED"
    ],
    "status": "research-draft"
  },
  "canonicalUrl": "https://ver.cy/models/thing/q37861/",
  "model": {
    "registry_id": "vr.tr.us",
    "name": ".us",
    "purpose": "Enable an AI agent to recognise .us as a governed DNS namespace, assess its operational and administrative state, and determine which registration, delegation or remediation actions are permitted.",
    "definition": "The Internet country-code top-level domain delegated in the DNS root for the United States (ISO 3166-1 alpha-2 US), operated as a restricted ccTLD whose registrants must satisfy a documented United States nexus, and which still exposes the RFC 1480 locality-and-function hierarchy under two-letter state labels in parallel with second-level names.",
    "scope_statement": "This model owns vr.tr.us interpreted as the United States country-code top-level domain: its identity, namespace branches, governing authority, registration constraints and namespace-level operational state; individual domains, registrants and services are linked entities.",
    "in_scope": [
      "The .us root delegation and the authorities responsible for its administration",
      "Direct registrations, locality-based branches and specially governed portions of .us",
      "Applicable nexus, naming, reservation and registration-data requirements",
      "Namespace-level DNS operation and delegation integrity",
      "Policy applicability, enforcement routes and conditions for authorised actions"
    ],
    "out_of_scope": [
      "The United States as a country, jurisdiction or political institution",
      "Individual .us domain registrations and their complete ownership or renewal histories",
      "Websites, email services and content hosted under .us",
      "Registrar businesses and their commercial account-management systems",
      "DNS protocols and resolver implementations as general technologies",
      "Trademark rights and legal proceedings beyond their recorded effects on .us decisions"
    ],
    "distinguishing_features": [
      "Confirm that the referent is the root-level DNS label us, classified by IANA as a country-code top-level domain, rather than the country code in another identification system. [IANA delegation record](https://www.iana.org/domains/root/db/us.html)",
      "Distinguish the namespace .us from a particular registered name ending in .us; a registrant's control of one name does not confer authority over the namespace.",
      "Determine whether a name falls under direct registration or a locality-based hierarchy; historical .us arrangements explicitly used geographic structure. [RFC 1386](https://datatracker.ietf.org/doc/rfc1386/)",
      "Check the .us-specific nexus and reserved-name policies before treating a syntactically valid name as registrable. [Registry policies](https://www.about.us/policies)",
      "Do not infer government ownership, official endorsement or hosting location merely from the .us suffix; establish those properties through linked evidence."
    ],
    "characteristics": [
      {
        "name": "Canonical namespace identity",
        "kind": "category",
        "unit_or_values": "DNS label us; presentation .us; country-code top-level domain",
        "why_it_matters": "Fixes the referent and prevents confusion with a country, website or individual registration."
      },
      {
        "name": "Delegated administrative authority",
        "kind": "relation",
        "unit_or_values": "Dated links to the registry manager, oversight authority and delegation evidence",
        "why_it_matters": "Identifies who can authorise namespace-level changes."
      },
      {
        "name": "Namespace branch",
        "kind": "category",
        "unit_or_values": "Direct-registration branch; locality-based branch; specially governed branch; unresolved",
        "why_it_matters": "Selects the relevant registration route and policy context."
      },
      {
        "name": "Branch registration availability",
        "kind": "state",
        "unit_or_values": "Open; restricted; closed to new registrations; suspended; unknown, with effective date",
        "why_it_matters": "Separates continued existence of names from permission to create new ones."
      },
      {
        "name": "Applicable nexus requirement",
        "kind": "relation",
        "unit_or_values": "Versioned policy and recognised eligibility categories, linked to the applicable branch",
        "why_it_matters": "Allows an agent to assess eligibility without assuming that all applicants qualify."
      },
      {
        "name": "Name reservation classification",
        "kind": "category",
        "unit_or_values": "Unreserved; government-reserved; other reserved; prohibited; unresolved",
        "why_it_matters": "Prevents an availability result from being mistaken for permission to register."
      },
      {
        "name": "Authoritative DNS response success",
        "kind": "measurement",
        "unit_or_values": "Percentage of successful queries, with query type, vantage points and observation interval",
        "why_it_matters": "Supports a bounded assessment of .us DNS availability."
      },
      {
        "name": "DNSSEC validation condition",
        "kind": "state",
        "unit_or_values": "Secure; insecure; bogus; indeterminate, with validation evidence and observation time",
        "why_it_matters": "Distinguishes authenticated resolution from reachability alone."
      },
      {
        "name": "Applicable remedy",
        "kind": "relation",
        "unit_or_values": "Issue type linked to policy, authorised recipient, evidence requirements and permitted outcome",
        "why_it_matters": "Routes disputes or operational faults to an authority able to act."
      }
    ],
    "affordances": [
      "Recognise .us names and classify their namespace branch before selecting a registration route",
      "Assess a proposed registration against applicable nexus, reservation and branch-access requirements",
      "Identify the authority and evidence needed for a .us delegation or policy change",
      "Compare dated DNS observations with the published .us delegation to investigate namespace-level faults",
      "Prepare an authorised registration, transfer or remediation request with unresolved prerequisites made explicit",
      "Route nexus complaints, rights disputes and abuse reports through the applicable .us process"
    ],
    "agent_conduct": {
      "may": [
        "Look up registration data for a .us domain through the official registry services.",
        "Explain the nexus requirements and structure of the domain from official policy.",
        "Register or renew a .us name for a user who meets the nexus rules and has authorized it."
      ],
      "must_not": [
        "Register a .us name with false nexus or registrant information.",
        "Register names that impersonate government bodies, people or brands to deceive.",
        "Harvest registrant contact details for spam or harassment.",
        "Transfer or change the records of a domain without the registrant's authority."
      ],
      "requires_human": [
        "Transferring or letting lapse a domain that a person or organization relies on.",
        "Reporting a .us name for abuse or takedown."
      ]
    },
    "ethics": {
      "considerations": [
        "Domain names under a national label can lend false official weight to scams.",
        "Registration data reveals personal details of individuals."
      ],
      "affected_parties": [
        "Registrants",
        "Internet users who rely on the names",
        "Public bodies whose names can be imitated"
      ]
    },
    "owners": {
      "steward": "The registry operator designated by the United States government; each name belongs to its registrant.",
      "master_systems": [
        "IANA root zone database",
        "The .us registry's registration database"
      ]
    },
    "visual_identification": [
      "Web and email addresses ending in .us.",
      "Locality names in the form name.city.state.us under state labels."
    ],
    "failure_modes_and_hazards": [
      "Lookalike names can be used for phishing and impersonation.",
      "Exposed registrant data can be harvested for spam or stalking."
    ],
    "standards_and_regulation": [
      "RFC 1480, The US Domain, Internet Engineering Task Force.",
      "ISO 3166-1, Codes for the representation of names of countries, International Organization for Standardization."
    ],
    "what_it_is_for": [
      "The .us domain is encountered in web addresses, email addresses and other DNS names associated with the United States.",
      "It provides a country-code namespace for eligible registrants and for delegated locality and institutional naming structures.",
      "Agents use its registration and delegation context when interpreting names, managing domains or investigating resolution problems."
    ]
  },
  "sources": [
    {
      "id": "iana-us",
      "title": "Root Zone Database: .us",
      "url": "https://www.iana.org/domains/root/db/us.html",
      "what_it_supports": "Confirms .us as the IANA-listed ccTLD for the United States and the current sponsoring/registry record in the root.",
      "url_status": "live"
    },
    {
      "id": "rfc1480",
      "title": "RFC 1480: The US Domain",
      "url": "https://www.rfc-editor.org/rfc/rfc1480",
      "what_it_supports": "Specifies the original geographically structured .us namespace, state labels, locality names, and functional branches (k12, ci, co, lib, cc, tec, and related).",
      "url_status": "live"
    },
    {
      "id": "rfc1591",
      "title": "RFC 1591: Domain Name System Structure and Delegation",
      "url": "https://www.rfc-editor.org/rfc/rfc1591",
      "what_it_supports": "Gives the ccTLD delegation model that .us sits in: ISO 3166-derived country codes in the DNS root and the duties of a delegated manager.",
      "url_status": "live"
    },
    {
      "id": "ustld-nexus",
      "title": "usTLD Nexus Requirements Policy",
      "url": "",
      "what_it_supports": "Defines the United States presence test (nexus categories) that restricts who may hold a .us name and is the live eligibility rule for second-level registrations."
    },
    {
      "id": "wikidata",
      "title": "Wikidata item Q37861: .us",
      "url": "https://www.wikidata.org/wiki/Q37861",
      "url_status": "live",
      "what_it_supports": "identity and sense of the item",
      "checked_by": "wikidata-api"
    },
    {
      "id": "wikipedia-en",
      "title": "Wikipedia: .us",
      "url": "https://en.wikipedia.org/wiki/.us",
      "url_status": "live",
      "what_it_supports": "general description of the item",
      "checked_by": "wikidata-api sitelink"
    }
  ],
  "structure": {
    "bundles": [
      {
        "id": "us-identity-and-authority",
        "name": ".us identity and authority",
        "description": "Establishes which namespace is being modelled and who holds authority over it.",
        "rationale": "An agent must distinguish control of .us from control of a name within it.",
        "layers": [
          {
            "id": "root-namespace-identity",
            "name": "Root namespace identity",
            "description": "Anchors the registry thing to the DNS root.",
            "findings": [
              {
                "id": "canonical-us-referent",
                "name": "Canonical .us referent",
                "description": "Record the canonical label, classification and evidence connecting vr.tr.us to the root delegation.",
                "questions": [
                  {
                    "text": "What registry or delegation evidence establishes that vr.tr.us denotes the .us country-code top-level domain?",
                    "kind": "definition",
                    "id": "canonical-us-referent-q01"
                  },
                  {
                    "text": "Does the observed identifier denote .us itself, a descendant name or a non-DNS use of US?",
                    "kind": "boundary",
                    "id": "canonical-us-referent-q02"
                  }
                ]
              }
            ]
          },
          {
            "id": "us-authority-chain",
            "name": ".us authority chain",
            "description": "Separates registry operation, oversight and root-delegation authority.",
            "findings": [
              {
                "id": "dated-authority-mandates",
                "name": "Dated authority mandates",
                "description": "Record responsible organisations, the evidence for their roles and the dates over which those roles apply.",
                "questions": [
                  {
                    "text": "Which current delegation record and governing instruments establish the operator and oversight roles for .us?",
                    "kind": "provenance",
                    "id": "dated-authority-mandates-q01"
                  },
                  {
                    "text": "Whose authorisation is required for the proposed registry-policy or root-delegation change?",
                    "kind": "action",
                    "id": "dated-authority-mandates-q02"
                  }
                ]
              }
            ]
          }
        ]
      },
      {
        "id": "us-namespace-branches",
        "name": ".us namespace branches",
        "description": "Distinguishes direct registrations from locality-based and specially governed branches.",
        "rationale": "Label depth alone cannot establish the registration boundary or applicable manager within .us.",
        "layers": [
          {
            "id": "registration-boundaries",
            "name": "Registration boundaries",
            "description": "Locates the administrative boundary relevant to a candidate name.",
            "findings": [
              {
                "id": "branch-and-manager-resolution",
                "name": "Branch and manager resolution",
                "description": "Record branch classification and the responsible manager without treating every descendant as independently registrable.",
                "questions": [
                  {
                    "text": "Is the candidate in the direct-registration namespace, a state or locality hierarchy, or another specially governed branch?",
                    "kind": "boundary",
                    "id": "branch-and-manager-resolution-q01"
                  },
                  {
                    "text": "Which current source identifies the registration boundary and manager for that branch?",
                    "kind": "provenance",
                    "id": "branch-and-manager-resolution-q02"
                  }
                ]
              }
            ]
          },
          {
            "id": "branch-access-and-legacy",
            "name": "Branch access and legacy",
            "description": "Separates historical branch structure from present admission rules.",
            "findings": [
              {
                "id": "branch-lifecycle-status",
                "name": "Branch lifecycle status",
                "description": "Record whether a branch accepts new names and what operations remain available for existing names, including the status of kids.us.",
                "questions": [
                  {
                    "text": "What dated evidence establishes the present status of this locality-based or specially governed branch?",
                    "kind": "provenance",
                    "id": "branch-lifecycle-status-q01"
                  },
                  {
                    "text": "Which creation, renewal, transfer or delegation operations remain permitted for this branch?",
                    "kind": "action",
                    "id": "branch-lifecycle-status-q02"
                  }
                ]
              }
            ]
          }
        ]
      },
      {
        "id": "us-registration-admissibility",
        "name": ".us registration admissibility",
        "description": "Captures the conditions under which an applicant and proposed name qualify.",
        "rationale": "A free label is insufficient when .us nexus, reservation or branch-specific requirements apply.",
        "layers": [
          {
            "id": "us-nexus-qualification",
            "name": "US nexus qualification",
            "description": "Connects eligibility categories to evidence and verification requirements.",
            "findings": [
              {
                "id": "nexus-evidence-and-review",
                "name": "Nexus evidence and review",
                "description": "Record the applicable nexus policy, claimed eligibility category and evidence needed to resolve uncertainty.",
                "questions": [
                  {
                    "text": "Which nexus category under the applicable policy could qualify this applicant?",
                    "kind": "definition",
                    "id": "nexus-evidence-and-review-q01"
                  },
                  {
                    "text": "What evidence and verification steps are required before the agent can treat that qualification as established?",
                    "kind": "action",
                    "id": "nexus-evidence-and-review-q02"
                  }
                ]
              }
            ]
          },
          {
            "id": "us-label-and-data-constraints",
            "name": "Label and registration-data constraints",
            "description": "Combines name-level admission checks with applicable registration-data obligations.",
            "findings": [
              {
                "id": "registration-preconditions",
                "name": "Registration preconditions",
                "description": "Record syntax, reservation, applicant restrictions and data-policy prerequisites for the selected registration route.",
                "questions": [
                  {
                    "text": "Does the proposed label meet current syntax rules and avoid applicable reserved or restricted categories?",
                    "kind": "boundary",
                    "id": "registration-preconditions-q01"
                  },
                  {
                    "text": "What registration-data, disclosure and privacy or proxy conditions must the applicant satisfy?",
                    "kind": "action",
                    "id": "registration-preconditions-q02"
                  }
                ]
              }
            ]
          }
        ]
      },
      {
        "id": "us-dns-operational-state",
        "name": ".us DNS operational state",
        "description": "Assesses the root-to-.us delegation and authoritative service.",
        "rationale": "An agent must distinguish a .us infrastructure fault from a failure confined to a descendant domain.",
        "layers": [
          {
            "id": "root-to-us-integrity",
            "name": "Root-to-.us integrity",
            "description": "Examines delegation consistency and authentication evidence.",
            "findings": [
              {
                "id": "delegation-and-validation-observations",
                "name": "Delegation and validation observations",
                "description": "Record observed root delegation, authoritative responses and DNSSEC validation results with timestamps.",
                "questions": [
                  {
                    "text": "Do observed root delegation records and .us authoritative responses agree on the relevant service configuration?",
                    "kind": "measurement",
                    "id": "delegation-and-validation-observations-q01"
                  },
                  {
                    "text": "What result does root-to-.us DNSSEC validation produce, and which observations support it?",
                    "kind": "measurement",
                    "id": "delegation-and-validation-observations-q02"
                  }
                ]
              }
            ]
          },
          {
            "id": "us-failure-localisation",
            "name": ".us failure localisation",
            "description": "Bounds operational incidents using multiple observation points.",
            "findings": [
              {
                "id": "namespace-versus-child-fault",
                "name": "Namespace versus child fault",
                "description": "Record whether failures affect .us authoritative service, a delegated branch, an individual domain or only a resolver path.",
                "questions": [
                  {
                    "text": "What query success rates and response times are observed across .us authoritative servers and independent vantage points?",
                    "kind": "measurement",
                    "id": "namespace-versus-child-fault-q01"
                  },
                  {
                    "text": "Does the evidence locate the failure at .us, below a child delegation or within the observing network?",
                    "kind": "boundary",
                    "id": "namespace-versus-child-fault-q02"
                  }
                ]
              }
            ]
          }
        ]
      },
      {
        "id": "us-policy-actions-and-remedies",
        "name": ".us policy actions and remedies",
        "description": "Links proposed operations and reported violations to the applicable process.",
        "rationale": ".us nexus issues, rights disputes and technical changes require different evidence and authorities.",
        "layers": [
          {
            "id": "us-operation-authorisation",
            "name": ".us operation authorisation",
            "description": "Determines whether an actor may request a specific change within the applicable branch.",
            "findings": [
              {
                "id": "permitted-operation-and-prerequisites",
                "name": "Permitted operation and prerequisites",
                "description": "Record the requested operation, actor mandate, responsible service and blocking conditions.",
                "questions": [
                  {
                    "text": "Is the request a registration-level operation, branch-delegation change or change to .us itself?",
                    "kind": "boundary",
                    "id": "permitted-operation-and-prerequisites-q01"
                  },
                  {
                    "text": "Which authority, credentials and policy prerequisites must be established before submitting it?",
                    "kind": "action",
                    "id": "permitted-operation-and-prerequisites-q02"
                  }
                ]
              }
            ]
          },
          {
            "id": "us-complaint-routing",
            "name": ".us complaint routing",
            "description": "Selects a remedy based on the actual issue and applicable policy version.",
            "findings": [
              {
                "id": "issue-specific-remedy",
                "name": "Issue-specific remedy",
                "description": "Record whether a case concerns nexus, registration data, naming rights, abuse or DNS operation, and link it to the appropriate process.",
                "questions": [
                  {
                    "text": "Which .us policy and evidence establish the appropriate process for this reported issue?",
                    "kind": "provenance",
                    "id": "issue-specific-remedy-q01"
                  },
                  {
                    "text": "Who may submit the request, what outcomes can the recipient authorise, and what review route applies?",
                    "kind": "action",
                    "id": "issue-specific-remedy-q02"
                  }
                ]
              }
            ]
          }
        ]
      },
      {
        "id": "evidence-and-external-alignment",
        "name": "Evidence and external alignment",
        "description": "What the world already says about this thing, gathered so the model can be checked against it.",
        "rationale": "A model that cannot be lined up against existing standards, identifiers and practice cannot be adopted by anyone who already uses them.",
        "layers": [
          {
            "id": "reported-evidence",
            "name": "Reported evidence",
            "description": "Findings from the breadth pass, kept separate from the structural claims.",
            "findings": [
              {
                "id": "evidence-kinds",
                "name": "Kinds and varieties",
                "description": "Reported by the breadth pass; each item needs checking against its source before it becomes normative.",
                "evidence": [
                  "Second-level registrations (name.us) sold through accredited registrars",
                  "Locality-based hierarchical names (locality.st.us)",
                  "Local-government names under ci. and co. labels",
                  "K-12 school names under k12.<state>.us",
                  "Other functional locality branches (lib, cc, tec, state, gen, cog, mus, dst)",
                  "kids.us (historical child-content space; discontinued)",
                  "Names still run by delegated locality managers versus names in the central registry"
                ],
                "questions": [
                  {
                    "id": "evidence-kinds-q01",
                    "text": "Which of these kinds and varieties hold for the sense of .us this model covers, and on what evidence?",
                    "kind": "provenance"
                  }
                ]
              },
              {
                "id": "evidence-identifiers",
                "name": "Identifiers and schemes",
                "description": "Reported by the breadth pass; each item needs checking against its source before it becomes normative.",
                "evidence": [
                  {
                    "scheme": "IANA TLD",
                    "value_or_pattern": "us",
                    "note": "Root-zone label; conventionally written with a leading dot as .us."
                  },
                  {
                    "scheme": "ISO 3166-1 alpha-2",
                    "value_or_pattern": "US",
                    "note": "Country code of which .us is the DNS delegation; the TLD label is the lower-case form used in the root."
                  }
                ],
                "questions": [
                  {
                    "id": "evidence-identifiers-q01",
                    "text": "Which of these identifiers and schemes hold for the sense of .us this model covers, and on what evidence?",
                    "kind": "provenance"
                  }
                ]
              },
              {
                "id": "evidence-standards-and-regulation",
                "name": "Standards and regulation",
                "description": "Reported by the breadth pass; each item needs checking against its source before it becomes normative.",
                "evidence": [
                  "RFC 1480 The US Domain (IETF / RFC Editor)",
                  "RFC 1591 Domain Name System Structure and Delegation (IETF / RFC Editor)",
                  "ISO 3166-1 country codes (International Organization for Standardization)",
                  "usTLD Nexus Requirements Policy (.us registry operator, under U.S. Department of Commerce / NTIA stewardship)",
                  "IANA Root Zone Management procedures (IANA)",
                  "Dot Kids Implementation and Efficiency Act of 2002 (United States Congress), which created the later-discontinued kids.us space"
                ],
                "questions": [
                  {
                    "id": "evidence-standards-and-regulation-q01",
                    "text": "Which of these standards and regulation hold for the sense of .us this model covers, and on what evidence?",
                    "kind": "provenance"
                  }
                ]
              },
              {
                "id": "evidence-real-world-use",
                "name": "Real-world use",
                "description": "Reported by the breadth pass; each item needs checking against its source before it becomes normative.",
                "evidence": [
                  "Organizations register example.us as a public signal of United States nexus, distinct from unrestricted gTLDs.",
                  "Many U.S. public schools still publish on hostnames under k12.<state>.us.",
                  "Some cities and counties still operate sites on ci.<locality>.<st>.us or co.<locality>.<st>.us rather than, or in addition to, .gov.",
                  "Libraries, community colleges, and technical schools appear under lib/cc/tec.<state>.us.",
                  "Registrars collect a nexus attestation at purchase; the registry can challenge or delete names that fail the test.",
                  "Search and advertising systems treat .us as a United States geo-target, similar to other ccTLDs."
                ],
                "questions": [
                  {
                    "id": "evidence-real-world-use-q01",
                    "text": "Which of these real-world use hold for the sense of .us this model covers, and on what evidence?",
                    "kind": "provenance"
                  }
                ]
              },
              {
                "id": "evidence-measurements",
                "name": "Typical measurements",
                "description": "Reported by the breadth pass; each item needs checking against its source before it becomes normative.",
                "evidence": [
                  {
                    "quantity": "Registration term",
                    "typical_range": "1-10",
                    "unit": "year"
                  },
                  {
                    "quantity": "DNS label length",
                    "typical_range": "1-63",
                    "unit": "octet"
                  },
                  {
                    "quantity": "Nexus category (eligibility class, not a physical quantity)",
                    "typical_range": "1-3",
                    "unit": "category"
                  }
                ],
                "questions": [
                  {
                    "id": "evidence-measurements-q01",
                    "text": "Which of these typical measurements hold for the sense of .us this model covers, and on what evidence?",
                    "kind": "provenance"
                  }
                ]
              },
              {
                "id": "evidence-failure-modes-and-hazards",
                "name": "Failure modes and hazards",
                "description": "Reported by the breadth pass; each item needs checking against its source before it becomes normative.",
                "evidence": [
                  "Nexus non-compliance: names can be suspended or deleted if the registrant cannot show a bona fide U.S. presence.",
                  "Abandoned locality delegations leave stale school, city, and county hostnames that still resolve or that fail unpredictably.",
                  "kids.us failed commercially and was shut down, stranding any remaining child-oriented names in that space.",
                  "WHOIS/RDAP accuracy required for nexus checks conflicts with registrant privacy expectations.",
                  "Cybersquatting of city, state, and civic strings in both second-level and locality trees.",
                  "Users treat .us as interchangeable with .com or with privately sold strings such as us.com.",
                  "U.S. territories are often assumed to fall under .us when they have their own ccTLDs."
                ],
                "questions": [
                  {
                    "id": "evidence-failure-modes-and-hazards-q01",
                    "text": "Which of these failure modes and hazards hold for the sense of .us this model covers, and on what evidence?",
                    "kind": "provenance"
                  }
                ]
              },
              {
                "id": "evidence-regional-variation",
                "name": "Regional variation",
                "description": "Reported by the breadth pass; each item needs checking against its source before it becomes normative.",
                "evidence": [
                  "Use of k12.<state>.us remains common in some states and is nearly unused in others that moved schools onto .org, .net, or district-owned gTLDs.",
                  "The District of Columbia is treated as dc.us in the locality tree, not as a separate ccTLD.",
                  "Inhabited U.S. territories are not under .us: Puerto Rico (.pr), Guam (.gu), U.S. Virgin Islands (.vi), American Samoa (.as), and Northern Mariana Islands (.mp) are separate ccTLDs.",
                  "Second-level opening in 2002 shifted national practice toward name.us, while remaining civic and school use is still state- and locality-shaped.",
                  "Military and federal civilian agencies are not the .us constituency; they use .mil and .gov."
                ],
                "questions": [
                  {
                    "id": "evidence-regional-variation-q01",
                    "text": "Which of these regional variation hold for the sense of .us this model covers, and on what evidence?",
                    "kind": "provenance"
                  }
                ]
              },
              {
                "id": "evidence-neighbours",
                "name": "Neighbouring kinds and how to tell them apart",
                "description": "Reported by the breadth pass; each item needs checking against its source before it becomes normative.",
                "evidence": [
                  {
                    "name": ".com",
                    "difference": ".com is an unrestricted generic TLD with no nationality test; .us is a ccTLD whose registrant must meet U.S. nexus."
                  },
                  {
                    "name": ".gov",
                    "difference": ".gov is limited to U.S. government organizations under the federal .gov program; a civic .us name (for example ci.*.us) is not a .gov authorization."
                  },
                  {
                    "name": ".edu",
                    "difference": ".edu is restricted to accredited U.S. postsecondary institutions (Educause); K-12 and many colleges on .us sit in k12/cc/tec locality branches instead."
                  },
                  {
                    "name": ".mil",
                    "difference": ".mil is the U.S. Department of Defense namespace; it is not a .us subdomain and is not available to civilian registrants."
                  },
                  {
                    "name": "ISO 3166-1 code US",
                    "difference": "US is a country-code identifier in catalogues and addresses; .us is the DNS name delegated from that code."
                  },
                  {
                    "name": "us.com (and similar private SLDs)",
                    "difference": "us.com is a privately operated second-level domain under .com, not the United States ccTLD and not subject to usTLD nexus."
                  },
                  {
                    "name": "en-US / en_US language-region tags",
                    "difference": "BCP 47 and POSIX locale identifiers name a language-region pair; they are not DNS labels and do not register a domain."
                  },
                  {
                    "name": "Territorial ccTLDs (.pr, .gu, .vi, .as, .mp)",
                    "difference": "Those codes are separate ISO 3166 / IANA delegations for U.S. territories, not subdomains of .us."
                  }
                ],
                "questions": [
                  {
                    "id": "evidence-neighbours-q01",
                    "text": "Which of these neighbouring kinds and how to tell them apart hold for the sense of .us this model covers, and on what evidence?",
                    "kind": "provenance"
                  }
                ]
              }
            ]
          }
        ]
      }
    ]
  },
  "openQuestions": [
    "Does the originating registry evidence confirm that vr.tr.us denotes the DNS top-level domain, given that no definition was recorded?",
    "Which current instruments establish the complete division of responsibility among .us oversight, registry operation and locality-based branch managers?",
    "Which locality-based and specially governed branches currently accept new registrations or transfers, and what is the current disposition of kids.us?",
    "What exact nexus evidence, registration-data disclosure, privacy or proxy rules and reserved-name exceptions apply to each registration route?",
    "What current delegation, DNSSEC and multi-vantage operational measurements establish a defensible baseline for judging .us health?"
  ],
  "statistics": {
    "bundles": 6,
    "layers": 11,
    "findings": 18,
    "questions": 28
  }
}
