# IV. Registry #### Summary This page defines the Registry layer of Nexus Standardization. If **III. Status** explains how controlled meaning becomes earned, reviewed, scoped, comparable, interoperable, portable, and correctable institutional status, then **IV. Registry** explains where those statuses become records-valid, traceable, reviewable, current, historical, correctable, and operationally usable. Registry is the records-valid infrastructure through which Nexus knows what is current, what is recognized, what is listed, what is supported, what is active, what is mature, what is suspended, what is narrowed, what is superseded, what is historical, what is corrected, what is retired, and what may properly be claimed. The source page correctly frames Registry as the records-valid order through which Nexus makes institutional state legible, reviewable, and enforceable. It emphasizes that Nexus is built on validity by record rather than reputation, informal consensus, branding, or narrative momentum, and that Registry is the operating expression of that doctrine. Registry is not a directory. It is not a static list. It is not a public relations page. It is not a partner catalogue. It is not merely a database. It is not a badge display system. Registry is the institutional memory and status-control layer of Nexus. It records standing. It records recognition. It records membership states. It records council states. It records node and host states. It records Marketplace and provider states. It records conformance and comparability states. It records public-safe publication states. It records national and regional formation states. It records correction, suspension, narrowing, reinstatement, supersession, withdrawal, and retirement. Through Registry, Nexus prevents important institutional states from living only in prose, memory, slides, platforms, dashboards, event pages, public claims, or social reputation. In Nexus, standing is not assumed. Standing is recorded. *** ### 4.1 Why Registry Matters Registry matters because Nexus is a validity-by-record architecture. A system that governs recognition, standing, status, conformance, comparability, interoperability, public-safe publication, node maturity, host status, council composition, membership standing, provider qualification, Marketplace listings, Digital Public Goods, Foundry packages, Studio workflows, national pathways, regional pathways, and finance-readable readiness cannot leave institutional state to informal understanding. If state is not recorded, state becomes vulnerable to distortion. A former status may appear current. An announced council may appear fully seated. A proposed node may appear active. A supported pathway may appear mature. A Marketplace listing may appear recognized. A provider may appear qualified by visibility. A public authority learner may appear adopting. A sponsor may appear controlling. A forum recommendation may appear decided. A dashboard may appear authoritative. A finance-readable record may appear financed. Registry prevents these failures by making state legible, current, scoped, reviewable, and correctable. It gives the system a place to answer the most important operational question in a complex ecosystem: **What is the recorded state, and what may properly be inferred from it?** *** ### 4.2 What Registry Means in Nexus Within Nexus, Registry is the formal, records-valid infrastructure through which institutional states, status-bearing objects, recognition acts, conformance results, membership states, council roles, node and host classifications, governed relationships, public-safe publications, Marketplace objects, Digital Public Goods, pathway states, and bounded entitlements are recorded, maintained, displayed, corrected, superseded, suspended, narrowed, reinstated, retired, or archived. Registry performs several functions at once. It records status. It classifies standing. It distinguishes current state from historical state. It anchors recognition in reviewable records. It links public claims to recorded conditions. It supports correction, appeal, renewal, narrowing, suspension, and reinstatement. It supports platform display, protocol effect, and entitlement control. It preserves institutional memory. It makes ecosystem state portable across time, geographies, institutions, platforms, nodes, and pathways. Registry is therefore not only administrative. It is one of the ways Nexus becomes governable. *** ### 4.3 The Registry Thesis of Nexus The Registry thesis of Nexus is that **a public-good-rooted, standards-bearing, federated, and realization-capable architecture can remain trustworthy only if consequential institutional states are recorded, classed, scoped, current, reviewable, correction-capable, and tied to public claims discipline rather than inferred from visibility, reputation, partnership, participation, funding, technical sophistication, or narrative momentum**. This thesis has several implications. Recognition must be recorded. Standing must be recorded. Membership state must be recorded. Council state must be recorded. Node state must be recorded. Host state must be recorded. Provider state must be recorded. Marketplace status must be recorded. Conformance results must be recorded. Public authority capacity must be recorded. Finance-readable readiness must be recorded. Suspension and reinstatement must be recorded. Supersession and retirement must be recorded. Correction must be recorded. The record is not paperwork after the fact. In Nexus, record is part of institutional truth. *** ### 4.4 Registry as the Backbone of Validity by Record Validity by record is one of the defining doctrines of Nexus. It means that certain acts, recognitions, designations, standings, status changes, role states, and institutional consequences are valid within the Nexus architecture only when properly recorded within the relevant governance and Registry order. Registry is the operating backbone of that doctrine. It distinguishes discussion from effect. It distinguishes intention from act. It distinguishes proposal from adoption. It distinguishes participation from appointment. It distinguishes visibility from recognition. It distinguishes support from maturity. It distinguishes listing from qualification. It distinguishes public-safe publication from public authority action. It distinguishes readiness from execution. This is why Registry cannot be treated as a clerical afterthought. A records-valid architecture does not make decisions somewhere else and merely copy them into records later. The record is part of the architecture of validity. *** ### 4.5 Standing as a Recorded State Standing in Nexus is a recorded state. It is not inferred from prominence, participation, partnership, output volume, donor support, event centrality, reputation, technical sophistication, or public visibility. A person, institution, council, guild, provider, node, host, report, pathway, Marketplace object, Digital Public Good, Foundry package, Studio workflow, or national structure may be visible, active, respected, or useful without holding a particular standing. Standing must answer: * who or what holds the standing; * what class of standing is held; * who recorded it; * under what authority; * under what profile; * in what scope; * with what evidence or review; * for what duration; * with what public claims; * and subject to what correction or renewal. This rule protects Nexus from status by appearance. It also protects participants and external readers from misreading the ecosystem. *** ### 4.6 Why Status Must Be Architected Status is powerful because status changes how people behave. A status can affect trust, access, progression, comparison, public language, platform display, provider selection, council eligibility, public authority interpretation, finance-reader understanding, and downstream readiness. A weak architecture allows status to be borrowed from rhetoric, association, platform polish, sponsor support, event visibility, or future plans. Nexus rejects that. Status must be architected. A mature status architecture must be able to answer: * what type of status is being described; * who or what holds it; * whether it is proposed, active, conditional, mature, suspended, narrowed, expired, superseded, retired, or historical; * what scope it covers; * what evidence or review supports it; * what body or process recorded it; * what claims it permits; * what claims it prohibits; * and how it may be corrected. Registry is the place where this architecture becomes operational. *** ### 4.7 Registry Objects Registry must be able to hold many classes of object because Nexus state appears across many layers. At minimum, Registry may include: * institutions and legal entities; * The Global Centre for Risk and Innovation (GCRI), The Global Risks Forum (GRF), The Global Risks Alliance (GRA), and the Nexus Standards Foundation (NSF) or applicable protocol authority records where appropriate; * councils and council seats; * guilds and guild states; * members and membership classes; * contributors and contribution records; * working groups; * domains and domain families; * pathways; * public authority capacity records; * sponsors and strategic backers; * qualified or prospective enterprise providers; * Marketplace objects; * Digital Public Goods; * Foundry packages; * Studio workflows; * nodes; * hosts; * hubs; * observatories; * national pathways; * National Working Groups; * National Nexus Consortiums; * National Consortium Companies; * Project SPVs; * regional pathways; * conformance results; * recognition records; * maturity states; * public-safe publications; * reports; * media corrections; * governance products; * protocol entitlements; * correction records; * suspension records; * reinstatement records; * supersession records; * retirement records; * archival records. The purpose of this breadth is not bureaucracy. It is to ensure that meaningful state does not live only in narrative. *** ### 4.8 Registry Record Classes Not every Registry record means the same thing. Registry must distinguish record classes carefully. Possible record classes include: #### 4.8.1 Administrative Records Records that establish identity, relationship, internal state, role, or lifecycle. #### 4.8.2 Membership Records Records of membership class, good standing, entitlements, renewal, suspension, resignation, or termination. #### 4.8.3 Council Records Records of council mandate, composition, seat completion, appointment, term, advisory status, governing status, conflicts, recusal, or lifecycle state. #### 4.8.4 Recognition Records Records that grant or confirm defined standing under scope and claims limits. #### 4.8.5 Conformance Records Records of conformance level, profile, version, evidence basis, review method, duration, and limitations. #### 4.8.6 Public-Safe Publication Records Records that classify reports, media, summaries, dashboards, or other outputs as public-safe within defined limits. #### 4.8.7 Marketplace Records Records of object listing, support state, provider relation, conformance posture, certification where applicable, lifecycle, and claims scope. #### 4.8.8 Provider Records Records of provider applicant state, listed state, qualification state, suspension, scope, cybersecurity obligations, data duties, and claims limits. #### 4.8.9 Node and Host Records Records of proposed, candidate, pilot, active, hosted, supported, mature, corridor-integrated, suspended, retired, or backup host states. #### 4.8.10 Correction Records Records of corrections, narrowing, supersession, withdrawal, clarification, reinstatement, or recovery. Registry presence alone does not mean recognition. The record class determines meaning. *** ### 4.9 Registry and The Global Centre for Risk and Innovation (GCRI) The Global Centre for Risk and Innovation (GCRI) interacts with Registry where evidence, methods, observability, ontology, Digital Public Goods, public-good software, public-good technical baselines, Academy materials, public-safe technical outputs, and research-to-practice artifacts require records-valid state. GCRI may generate or steward materials that later become Registry-linked. Examples may include: * method records; * observability records; * ontology inputs; * data dictionary records; * public-good software records; * Digital Public Good records; * evidence-class records; * technical baseline records; * Academy material status; * Lab output status; * public-safe technical publication records. But a GCRI-originated artifact does not automatically become recognized, conformant, public-safe, or routeable merely because GCRI generated it. Registry records the relevant state. GRF, GRA, the Nexus Standards Foundation (NSF), or another competent pathway may be involved depending on the kind of status sought. GCRI contributes upstream truth. Registry records its institutional state where needed. *** ### 4.10 Registry and The Global Risks Forum (GRF) The Global Risks Forum (GRF) has a central relationship to Registry because GRF is the public-good steward of recognition, standing, maturity records, claims discipline, public-safe publication, Registry discipline, and public-facing legitimacy. GRF-related Registry functions may include: * recognition records; * standing records; * maturity records; * public-safe publication records; * conformance-result publication where relevant; * claims-scope records; * correction records; * public-facing status records; * Registry governance records; * records of suspension, narrowing, reinstatement, or retirement. GRF helps ensure that Registry does not become a mere catalogue. It helps preserve the difference between being recorded, being listed, being recognized, being mature, being public-safe, and being claimable. This distinction is essential because public-facing legitimacy is fragile. Once false status language enters the public environment, it becomes difficult to correct. GRF discipline makes Registry one of the main safeguards against public claims drift. *** ### 4.11 Registry and The Global Risks Alliance (GRA) The Global Risks Alliance (GRA) interacts with Registry where adoption, routeability, ecosystem translation, sponsor-capital mapping, finance-readable readiness, provider pathways, national pathways, and lawful realization handoffs require recorded state. GRA may rely on Registry to distinguish: * early interest from pathway state; * routeable idea from finance-readable record; * finance-readable record from financed project; * provider listing from provider qualification; * National Working Group from National Nexus Consortium; * National Consortium Company from Project SPV; * supported pathway from comparable pathway; * public-good readiness from execution readiness; * sponsor support from capital commitment. Registry gives GRA the status truth needed to translate ecosystem activity responsibly. Without Registry, adoption and routeability language would become vulnerable to overclaim. GRA uses Registry discipline to make pathways intelligible without turning readiness into execution. *** ### 4.12 Registry and the Nexus Standards Foundation or Protocol Authority The Nexus Standards Foundation (NSF), or applicable protocol authority, interacts with Registry where canonical semantics, standards profiles, conformance records, role keys, smart licenses, entitlements, no-bypass rules, protocol states, and technical effect depend on recorded status. Registry records institutional state. Protocol expresses selected recorded states in machine-operable form. A Registry record may support: * role-key issuance; * entitlement activation; * smart-license permission; * access control; * conformance badge display; * Marketplace object state; * node capability activation; * provider access; * Studio workflow permissions; * revocation; * suspension; * rollback; * audit trails. But protocol does not invent status. A role key is not appointment unless the appointment is recorded. A smart license is not recognition unless recognition exists by record. An entitlement is not lawful authority. Protocol should enforce Registry truth, not replace it. *** ### 4.13 Registry and Ontology Registry depends on ontology. A record is meaningful only if its object class, status class, lifecycle state, scope, and claims limits are defined. Ontology tells Registry what a thing is. Registry tells the system what state that thing holds. For example: Ontology defines a Nexus Node, a host, a provider, a Marketplace object, a public-safe report, a public authority learner, a finance-readable record, and a Project SPV. Registry records whether each is proposed, active, recognized, supported, mature, suspended, superseded, retired, or archived. Without ontology, Registry entries become labels. With ontology, Registry entries become governed institutional memory. Registry and ontology must therefore be designed together. *** ### 4.14 Registry and Status Registry is the records-valid home of status. A status that matters should not remain informal. Registry may record: * proposed status; * candidate status; * active status; * supported status; * hosted status; * comparable status; * corridor-integrated status; * strategic-project-enabled status; * mature status; * recognized status; * conformance-reviewed status; * public-safe status; * finance-readable status; * suspended status; * narrowed status; * reinstated status; * recovered status; * superseded status; * withdrawn status; * retired status; * archived status. Status without Registry is vulnerable to drift. Registry without status discipline is vulnerable to confusion. The two layers reinforce one another. *** ### 4.15 Registry and Recognition Recognition in Nexus must be Registry-bearing. A recognition act should be recorded with: * recognized subject; * recognition class; * issuing body or process; * recognition date; * scope; * evidence or review basis; * profile or standard where applicable; * duration or review cycle; * public claims permitted; * public claims prohibited; * limitations; * correction procedure; * renewal conditions; * suspension conditions; * supersession state; * and archival state. Recognition without Registry is too vulnerable to informal overclaim. Registry makes recognition durable, reviewable, and bounded. It also makes recognition narrow enough to trust. *** ### 4.16 Registry and Standing Standing is a recorded state that may carry public-facing legitimacy within a defined scope. Standing may apply to: * members; * contributors; * councils; * guilds; * institutions; * providers; * sponsors; * nodes; * hosts; * reports; * Marketplace objects; * Digital Public Goods; * national pathways; * regional pathways; * governance products; * public-safe outputs; * conformance results. Standing is not universal. Standing is always classed and bounded. A provider may have standing in one service class and not another. A node may have standing as active and not mature. A council may have standing as advisory and not governing. A public authority may have standing as learner and not adopter. A Marketplace object may have standing as listed and not recognized. Registry must preserve this granularity. *** ### 4.17 Registry and Public Claims Discipline Registry is one of the main tools through which Nexus governs public claims. Public language must remain tethered to recorded state. No participant, partner, provider, sponsor, host, node, council, guild, public authority, platform, report, Marketplace object, or pathway may claim a status stronger than the Registry supports. No one may borrow language from an aspirational future state. No one may use a narrow true state to imply broader maturity. No one may use Registry presence as universal approval. Claims discipline should flow from Registry: * listed may claim listing; * supported may claim support within scope; * conformant may claim conformance to the specific profile and version; * recognized may claim recognition only within the recognition record; * public-safe may claim public-safe publication only within defined limits; * finance-readable may claim finance-readable status only within non-execution limits; * qualified may claim qualification only within service scope. Registry keeps public language honest. *** ### 4.18 Registry and Membership States Membership is one of the clearest examples of Registry necessity. Membership in Nexus is class-based, good-standing dependent, entitlement-aware, renewable, correctable, and bounded by duties. Registry may record: * applicant; * member class; * individual member; * institutional member; * guild-linked member; * contributor member; * host-linked member; * sponsor-linked member; * provider-linked member; * public authority learner or participant; * leadership-pathway member; * good standing; * provisional status; * limited status; * suspension; * resignation; * termination; * expiry; * former status; * archived status. Membership without Registry becomes social affiliation. Registry makes membership institutionally reliable. It supports access control, contribution records, public claims, progression, renewal, and correction. *** ### 4.19 Registry and Councils Councils require Registry discipline because councils sit close to legitimacy and authority. Registry may record: * council mandate; * council type; * advisory or governance-bearing status; * interim or mature status; * composition; * seat matrix; * seat completion state; * appointment records; * term records; * conflicts; * recusal; * attendance where relevant; * resolutions; * recommendations; * reserved-matter referrals; * suspension; * dissolution; * correction; * archival state. This prevents governance theatre. A council is not mature because it is announced. A council member is not appointed because they attended a meeting. A consultative body is not a governing body unless recorded. An interim council is not permanent unless transitioned. Registry makes council state visible and reviewable. *** ### 4.20 Registry and Guilds, Domains, and Working Groups Guilds, domains, and working groups also need Registry where their state matters. Registry may record: * proposed guild; * active guild; * mature guild; * suspended guild; * retired guild; * domain family; * domain steward; * working group proposed; * working group active; * working group closed; * output status; * public-safe status; * standards question referral; * report contribution; * correction; * archive. A guild is not a standards authority because it exists. A domain is not mature because it is named. A working group is not a council. A working group output is not a final report unless recorded as such. Registry preserves the difference between cooperative activity and institutional effect. *** ### 4.21 Registry and Node Architecture Node architecture depends heavily on Registry. Nexus may include global nodes, regional nodes, national nodes, observatory nodes, learning nodes, Studio nodes, technical nodes, host nodes, supported pathways, hosted pathways, corridor-integrated nodes, mature nodes, and strategic-project-enabled nodes. Registry should record: * node identity; * node type; * host relation; * status; * maturity; * support state; * observability function; * interoperability profile; * public-safe posture; * data responsibilities; * geographic or jurisdictional scope; * lifecycle state; * suspension or downgrade; * reinstatement; * retirement; * public claims. Without Registry, node language becomes inconsistent and inflated. Registry gives nodes a common status grammar. It allows Nexus to say where a node stands and what the node may properly claim. *** ### 4.22 Registry and Hosts, Hubs, and Backup Hosts Hosts, hubs, and backup hosts require Registry because runtime support can easily be mistaken for authority. Registry may record: * host type; * host scope; * node relation; * Academy relation; * Studio relation; * observatory relation; * public authority learning relation; * backup host status; * anchor host status; * regional hub status; * national hub status; * host obligations; * data obligations; * continuity role; * public-safe limits; * lifecycle state; * suspension; * transition; * retirement. A host is not sovereign over Nexus. A hub is not regional supremacy. A backup host is not a competing constitutional center. A runtime support role does not create ownership of the common rail. Registry makes host and hub roles legible without inflating them. *** ### 4.23 Registry and Marketplace Objects Marketplace depends on Registry to prevent discovery from becoming implied endorsement. Registry may record: * object class; * provider; * steward; * listing state; * support state; * conformance posture; * certification where applicable; * version; * dependency state; * public-safe posture; * jurisdictional limits; * lifecycle state; * suspension; * deprecation; * retirement; * claims limits. A Marketplace listing is not recognition by default. A badge means only what its record says. A rating is not maturity. A featured object is not procurement preference. A provider profile is not endorsement. Registry allows Marketplace to grow without allowing visibility to become trust by implication. *** ### 4.24 Registry and Digital Public Goods Digital Public Goods require Registry where users need to know what is current, supported, secure, maintained, deprecated, or retired. Registry may record: * DPG class; * steward; * license; * version; * repository; * release state; * support state; * maintenance state; * security review state; * conformance posture; * dependency status; * authorized forks or variants; * public-safe posture; * deprecated state; * retired state; * archived state. Open does not mean maintained. Public does not mean public-safe everywhere. Reusable does not mean supported. A fork does not mean authorized architecture. Registry gives Digital Public Goods trustworthy lifecycle memory. *** ### 4.25 Registry and Foundry Packages Foundry outputs require Registry because build maturity can easily be overclaimed. Registry may record: * idea; * requirement; * scoped concept; * prototype; * experiment; * package candidate; * release candidate; * maintained package; * supported package; * deprecated package; * retired package; * test state; * documentation state; * security posture; * dependency state; * public-safe limits; * handoff state. A prototype is not a release. A release candidate is not deployment authorization. A supported package is not universal conformance. A Foundry object is not public authority adoption. Registry allows build artifacts to mature through truthful stages. *** ### 4.26 Registry and Studio Workflows Studio workflows require Registry because dashboards, simulations, maps, AI interfaces, and controlled rooms can appear authoritative. Registry may record: * Studio object class; * workflow status; * data source state; * update frequency; * user role; * access level; * public-safe state; * reliance boundary; * authority boundary; * public authority capacity where relevant; * correction history; * retirement state. A dashboard is not public warning by default. A simulation is not forecast certainty. A decision-support workflow is not lawful decision-making. A controlled room is not a regulator. A public authority learning environment is not adoption. Registry gives Studio outputs status clarity. *** ### 4.27 Registry and Reports, Media, and Forum Outputs Reports, Media, and Forum outputs need Registry where public status, correction, or reliance matters. Registry may record: * report draft; * working report; * public-safe report; * published report; * corrected report; * superseded report; * withdrawn report; * archived report; * media announcement; * media correction; * forum agenda; * forum transcript; * forum summary; * recommendation; * issue log; * standards question; * learning record; * governance referral; * report candidate. A forum summary is not a decision. A media recap is not recognition. A report draft is not published. A public-safe summary is not full evidence. A recommendation is not adoption. Registry helps public outputs remain legible over time. *** ### 4.28 Registry and Recognition Products and Governance Products Recognition products, governance products, conformance reports, comparability records, interoperability profiles, maturity records, public-safe publication records, claims guidance, and routeability notes should live in Registry discipline where they carry institutional consequence. A governance product should state: * product class; * issuer or steward; * subject; * status; * scope; * evidence basis; * review basis; * profile; * effective date; * expiry or review date; * permitted claims; * prohibited claims; * correction pathway; * supersession state; * archival state. Registry prevents recognition-bearing products from being trapped in prose. It makes them operationally visible as part of the living system. *** ### 4.29 Registry and Public Authority Capacity Public authority capacity must be recorded carefully. Registry may distinguish: * learner; * observer; * consultee; * host; * sponsor; * competent authority; * adopting authority; * procurement authority; * regulator; * emergency authority; * public-warning authority; * implementation partner. These are not interchangeable. A learner is not adopting. An observer is not approving. A consultee is not endorsing. A host is not adopting all outputs. A public-warning authority acts only through its own lawful process. Registry protects public authorities from being overclaimed and protects Nexus from sovereignty-risk. *** ### 4.30 Registry and Finance-Readable Readiness Finance-readable readiness requires Registry discipline because finance-facing language is high-risk. Registry may record: * concept; * routeable idea; * readiness artifact; * finance-readable record; * diligence-ready package; * sponsor-supported pathway; * capital discussion; * Project SPV concept; * Project SPV formed; * capital commitment; * financial close; * executed project. These states must not collapse. Finance-readable is not financed. Diligence-ready is not investment advice. Capital discussion is not capital commitment. Project SPV concept is not securities offering. Financial close is separate from formation. Registry allows finance readers to understand status without converting readiness into regulated execution. *** ### 4.31 Registry and National Formation National formation must be stage-truthful. Registry may record: * country interest; * national observer cluster; * national members; * national domain activity; * National Working Group proposed; * National Working Group active; * National Nexus Consortium under formation; * National Nexus Consortium formed; * National Consortium Company under preparation; * National Consortium Company formed; * Project SPV concept; * Project SPV formed. A national conversation is not a National Working Group. A National Working Group is not a National Nexus Consortium. A National Nexus Consortium is not a National Consortium Company. A National Consortium Company is not a Project SPV. A Project SPV is not the public-good architecture. Registry prevents national pathway enthusiasm from becoming false formation. *** ### 4.32 Registry and Regional Formation Regional formation also requires Registry. Registry may record: * regional interest; * regional working group; * regional council proposed; * regional council active; * regional consortium under formation; * regional consortium formed; * corridor pathway; * basin pathway; * support-versus-comparable classification; * regional node; * regional hub; * regional coordination record; * regional-to-national handoff; * regional-to-global handoff. Regional state must preserve national primacy. A regional pathway is not regional supremacy. A corridor interface is not supranational authority. A regional hub is not universal governance. A support classification is not comparability unless recorded as such. Registry gives federation stage truth. *** ### 4.33 Registry and Current, Historical, Corrected, and Superseded State A Registry that cannot distinguish current from historical state becomes dangerous. Nexus requires clear handling of: * current records; * historical records; * corrected records; * superseded records; * withdrawn records; * suspended records; * narrowed records; * reinstated records; * retired records; * archived records. A state may once have been valid and no longer be current. An object may remain part of institutional memory while no longer being usable. A designation may be superseded without being erased. A correction may narrow prior claims without deleting history. Registry should preserve temporal truth. This is essential to trust. Quiet overwriting weakens institutional memory. Clear status history strengthens it. *** ### 4.34 Suspension, Narrowing, Downgrade, Reinstatement, and Recovery A serious Registry must be able to narrow, suspend, downgrade, reinstate, and recover status. Registry should be able to record: * suspension; * downgrade; * narrowing of scope; * temporary limitation; * corrective state; * probationary state; * reinstatement; * recovery; * restored status; * retired status; * final withdrawal. This applies to members, providers, councils, nodes, hosts, Marketplace objects, Digital Public Goods, Foundry packages, Studio workflows, public-safe publications, national pathways, regional pathways, and recognition states. A system that can only add status becomes weak when tested. Registry must be able to remove, limit, and correct status under proper rules. This is not punitive bureaucracy. It is institutional truth maintenance. *** ### 4.35 Registry and Correctionability Correctionability is one of the deepest Nexus doctrines, and Registry is where correctionability becomes operational. Registry correction may address: * wrong class; * wrong status; * incorrect public claims; * outdated state; * mistaken public authority capacity; * provider overclaim; * sponsor misdescription; * erroneous node maturity; * wrong host relation; * report correction; * Marketplace correction; * Digital Public Good support change; * Foundry package deprecation; * Studio workflow withdrawal; * national pathway misclassification; * regional pathway misclassification. Correction should be visible where public meaning, reliance, or institutional memory is affected. A correction may include: * record amendment; * correction note; * public clarification; * scope narrowing; * status change; * supersession; * withdrawal; * suspension; * reinstatement; * archival note; * protocol revocation; * platform update. Registry preserves both current truth and correction history. *** ### 4.36 Registry and No-Silent-Edit Discipline No-silent-edit discipline applies strongly to Registry. Material changes to status, recognition, conformance, comparability, public-safe state, public authority capacity, finance-readable readiness, node maturity, provider qualification, Marketplace listing, or protocol entitlement should not disappear without trace. No-silent-edit discipline may require: * version number; * effective date; * change log; * reason for change; * responsible steward; * prior state; * new state; * correction notice; * supersession note; * public notice where appropriate; * platform update; * protocol update; * archive copy. Not every clerical correction requires major notice. But any change affecting reliance, claims, public interpretation, or authority boundaries must be traceable. Registry is the memory layer. It must not rewrite memory silently. *** ### 4.37 Registry and Entitlements Registry may support entitlements. An entitlement is a defined permission, access, role, capability, or use right granted under a recorded state. Entitlements may include: * member access; * guild access; * council room access; * public-safe review access; * report drafting access; * Marketplace contributor access; * Foundry workspace access; * Studio workflow access; * node environment access; * host role access; * provider portal access; * Academy credential access; * public authority learning room access; * protocol role key; * smart-license permission; * API access; * data access. Entitlement must be tied to recorded state. Access is not authority. A platform role is not office. A role key is not appointment unless appointment is recorded. A smart license is not recognition unless recognition exists. Registry provides the source of truth for entitlement where applicable. *** ### 4.38 Registry and Protocol Effect Registry and protocol are adjacent but distinct. Registry provides governance-valid state. Protocol may express parts of that state through machine-operable mechanisms such as: * role keys; * smart licenses; * entitlements; * access controls; * no-bypass rules; * audit logs; * revocation; * rollback; * synchronization; * proof anchoring; * interface permissions; * capability activation; * API scope. Protocol follows Registry. It does not invent Registry truth. A protocol state should be traceable to a record. If the record changes, the protocol effect should be updated, revoked, narrowed, or superseded. This relationship is essential to prevent technical systems from becoming hidden governors. *** ### 4.39 Registry and Platform Display Platforms must reflect Registry state accurately. Platform display may include: * member directories; * council pages; * guild pages; * node maps; * host pages; * Marketplace listings; * provider profiles; * DPG catalogues; * Foundry package pages; * Studio workflow libraries; * report libraries; * public authority learning pages; * national pathway dashboards; * regional pathway dashboards; * badges; * certificates; * status cards; * APIs. Every public or controlled platform display should distinguish current, historical, draft, proposed, active, recognized, supported, suspended, superseded, and retired state as relevant. A platform should not make draft work look final. A map should not make proposed nodes look active. A badge should not imply broader status than its record. A provider page should not imply procurement preference. Platform display is public meaning infrastructure. It must obey Registry. *** ### 4.40 Registry and Search, Discovery, and User Navigation Registry is also a discovery layer, but discovery must be status-aware. Users should be able to find: * current records; * historical records; * recognized objects; * listed but not recognized objects; * suspended records; * superseded records; * public-safe outputs; * archived materials; * correction notices; * provider statuses; * node statuses; * pathway statuses. Search and navigation should not flatten record classes. Search results should not display retired objects as current. Marketplace search should not mix listed and certified objects without labels. Report search should show supersession. Node search should show maturity state. Provider search should show scope. Discovery without status discipline creates confusion. Registry must make search truthful. *** ### 4.41 Registry and Public-Safe Publication Registry supports public-safe publication. A public-safe publication record should indicate: * publication class; * steward; * review state; * public-safe status; * scope; * evidence level where relevant; * restrictions; * sensitive material excluded; * correction pathway; * supersession state; * withdrawal state; * archive state; * public claims limits. Public-safe publication is not public authority action. It is not recognition unless recorded as recognition. It is not a public warning unless issued by a lawful public-warning authority. Registry helps readers understand what kind of publication they are reading. It also ensures public-safe outputs remain correctable. *** ### 4.42 Registry and Safeguards Registry must integrate safeguards. Some records should carry handling restrictions or safeguard indicators. These may include: * confidential; * controlled; * restricted; * public-safe; * protected knowledge; * community-reviewed; * Indigenous knowledge-sensitive; * sensitive geography; * security-sensitive; * health-sensitive; * biosecurity-sensitive; * procurement-sensitive; * market-sensitive; * public authority-sensitive; * child or youth participation-sensitive; * personal-data restricted; * cybersecurity restricted. Safeguard states must be designed carefully. They should protect people, communities, institutions, infrastructure, and public trust without unnecessarily blocking legitimate learning or accountability. Registry is one of the mechanisms through which sensitive status is handled responsibly. *** ### 4.43 Registry and Data Governance Registry itself contains data and therefore requires governance. Registry data may include personal data, institutional data, member records, council records, provider records, public authority records, sponsor records, contributor records, node and host records, Marketplace records, public-safe publication records, finance-readable records, and correction histories. Registry governance should address: * lawful basis; * data minimization; * access control; * privacy; * cybersecurity; * retention; * deletion; * correction; * portability; * public visibility; * controlled visibility; * audit logs; * sensitive geography; * protected knowledge; * public authority sensitivity; * market sensitivity; * and archival obligations. Registry should not become surveillance infrastructure. It should not become a commercial lead database. It should not become reputational scoring without governance. Its purpose is institutional truth, not extraction. *** ### 4.44 Registry and Access Classes Not all Registry records should be public. Registry should support access classes such as: * public; * public-safe; * controlled public; * member-visible; * role-visible; * steward-visible; * confidential; * restricted; * sensitive; * archived; * sealed where lawful and appropriate. Some records need public visibility to govern claims. Some records need controlled visibility to protect privacy, security, public authority sensitivity, community knowledge, or market sensitivity. Some records should disclose status without exposing underlying sensitive details. Registry design must balance transparency and protection. The goal is not maximum disclosure. The goal is trustworthy disclosure. *** ### 4.45 Registry and Auditability Registry should be auditable. Auditability means that authorized reviewers can determine: * who created a record; * when it was created; * under what authority; * what status was assigned; * what evidence or process supported it; * what changes occurred; * who changed it; * why it changed; * what prior state existed; * what public claims were permitted; * what entitlements were linked; * and what correction history exists. Auditability is essential where Registry records support conformance, recognition, public claims, entitlements, public authority interfaces, provider status, finance-readable readiness, or protocol effect. Auditability does not mean every record is public. It means records are reviewable by appropriate bodies. *** ### 4.46 Registry and Appeals, Review, and Reconsideration A serious Registry should include pathways for review, appeal, or reconsideration where status has material consequence. This may apply to: * membership suspension; * provider qualification denial; * Marketplace delisting; * recognition denial; * conformance result; * public-safe publication classification; * node downgrade; * host suspension; * council role correction; * public authority capacity correction; * finance-readable status change; * Digital Public Good retirement; * Foundry package withdrawal. Appeal or review rights should be proportionate. Not every administrative record requires formal appeal. But where status affects public claims, access, standing, or trust, there should be a fair and recorded mechanism for correction or review. This supports legitimacy. *** ### 4.47 Registry and Lifecycle Discipline Registry must preserve lifecycle truth. Every status-bearing object should have a lifecycle model appropriate to its type. Possible lifecycle states include: * proposed; * under review; * candidate; * pilot; * active; * supported; * recognized; * mature; * corrective; * suspended; * narrowed; * downgraded; * reinstated; * recovered; * deprecated; * superseded; * withdrawn; * retired; * archived. Lifecycle discipline prevents stale states from appearing current. A former member should not appear active. A retired DPG should not appear supported. A superseded report should not appear current. A suspended provider should not appear qualified. A proposed node should not appear operational. Lifecycle is not bureaucracy. It is temporal truth. *** ### 4.48 Registry and Federation Federation depends on Registry. Global, regional, national, host, and local layers require shared status grammar to avoid fragmentation. Registry supports federation by recording: * global records; * regional records; * national records; * host records; * corridor records; * basin records; * shared-ecology records; * support-versus-comparable classifications; * regional node states; * national node states; * national formation stages; * regional formation stages; * handoff records; * crosswalks; * public authority capacity; * local adaptation status; * anti-fork status. Registry allows local truth to remain visible without becoming incompatible. It allows regional comparability to be declared without overstating national adoption. It allows global coherence to exist without erasing domestic lawful basis. *** ### 4.49 Registry and the Swiss Global Backbone Within the GRF architecture, Switzerland may function as a global reference node for continuity, records, register, secretariat, governance memory, and global-layer institutional stability. This should be understood as a structural backbone role, not branding. The importance of a global records backbone is that Registry is not placeless abstraction. It must be carried by durable institutional arrangements, host logic, continuity practices, and governance memory. A global Registry backbone may support: * continuity; * institutional memory; * records discipline; * public-facing status; * global recognition records; * correction records; * archive; * governance secretariat functions; * cross-regional comparability; * protocol-related reference states. This does not make a host or reference jurisdiction the whole architecture. It gives Registry gravity, continuity, and institutional seriousness. *** ### 4.50 Registry and Institutional Memory Registry is institutional memory. It preserves: * what was formed; * what was recognized; * what was listed; * what was conformed; * what was public-safe; * what was corrected; * what was suspended; * what was reinstated; * what was superseded; * what was retired; * what was archived; * who held roles; * who contributed; * what state changed; * and what claims were permitted. This memory matters because Nexus is long-horizon. Without institutional memory, the system would repeat errors, lose contribution history, confuse current and former states, and weaken public trust. Registry allows Nexus to remember without freezing itself. It preserves history while making current state clear. *** ### 4.51 Registry and Operational Control Registry is also operational control. It can determine: * who has access; * what entitlement is active; * which provider is visible; * which Marketplace object is listed; * which node appears active; * which report is current; * which Studio workflow is available; * which public authority capacity is displayed; * which conformance badge may be shown; * which smart license is active; * which role key remains valid; * which status is suspended. Registry therefore does not only describe the system. It helps operate it. This is why Registry must be governed with care. Errors in Registry can become errors in access, public claims, platform display, or protocol effect. *** ### 4.52 Registry Stewardship Registry requires stewardship. Registry stewardship should define: * who may create records; * who may approve records; * who may modify records; * who may correct records; * who may suspend records; * who may retire records; * who may publish records; * who may access controlled records; * who may link records to protocol entitlements; * who may approve public claims derived from records; * and who audits Registry integrity. Stewardship must be role-separated. A provider should not control its own qualification record. A sponsor should not control its own influence record. A host should not unilaterally define node maturity. A public authority capacity should not be assigned casually. A Marketplace listing should not become certification by platform design. Registry stewardship protects records from capture. *** ### 4.53 Registry Governance Process Registry governance should include procedures for: * intake; * classification; * review; * evidence attachment; * profile linkage; * approval; * recording; * publication; * access classification; * public claims guidance; * entitlement linkage; * renewal; * monitoring; * correction; * suspension; * reinstatement; * supersession; * withdrawal; * retirement; * archival; * appeal or review where applicable. The process should be proportionate to the consequence of the record. A public directory entry requires less review than a recognition record. A membership state requires different review than a conformance result. A provider qualification requires stronger controls than an observer record. A public authority capacity record requires special care. Registry governance must match risk. *** ### 4.54 Registry and External Organizations Registry is a practical resource for external organizations. A public authority can use Registry to distinguish public-safe publications, learning status, adoption status, node status, provider status, and public claims limits. A company can use Registry to understand membership, provider status, Marketplace status, conformance, qualification, and claims. A university can use Registry to understand Academy participation, report contribution, competence-cell status, DPG contribution, and node or host role. A sponsor can use Registry to understand support-without-control and public acknowledgment limits. A community organization can use Registry to confirm protected participation, public-safe publication, consent-sensitive records, and correction. A provider can use Registry to understand listing, qualification, scope, support state, and suspension. A national group can use Registry to understand its pathway stage. A finance reader can use Registry to distinguish finance-readable readiness, diligence preparation, SPV formation, capital commitment, and execution. Registry makes Nexus legible to organizations that need reliable status truth. *** ### 4.55 Registry Failure Modes Nexus should be explicit about Registry failure modes. **Directory reduction** occurs when Registry is treated as a list rather than a status-control system. **Record ambiguity** occurs when a record exists but its class and implications are unclear. **Current-history confusion** occurs when historical records appear current. **Recognition drift** occurs when listed objects are mistaken for recognized objects. **Standing inflation** occurs when narrow standing is publicly read as broad authority. **Membership misclassification** occurs when inactive, suspended, or former members appear current. **Council theatre** occurs when announced councils appear fully seated or mature without recorded composition. **Node overclaim** occurs when proposed or pilot nodes appear active or mature. **Host authority drift** occurs when host status appears to create sovereignty. **Marketplace overclaim** occurs when listings, badges, or ratings imply endorsement or maturity beyond record. **Provider capture** occurs when providers influence their own status or use Registry visibility as procurement advantage. **Sponsor capture** occurs when support is converted into standing or control. **Public authority overclaim** occurs when learning or observation is recorded or displayed as adoption. **Finance-readiness overclaim** occurs when Registry states imply investment, underwriting, rating, insurance, or capital commitment. **Silent edit failure** occurs when changes affecting reliance occur without trace. **Correction failure** occurs when wrong records cannot be corrected or publicly narrowed. **Protocol mismatch** occurs when technical entitlements do not match Registry state. Registry governance exists to prevent these failures. *** ### 4.56 Strategic Value of Registry The strategic value of Registry is that it gives Nexus durable institutional truth. Registry lets Nexus scale without losing memory. It lets participation become records-valid. It lets recognition become bounded. It lets status become current. It lets public claims become verifiable. It lets councils become reviewable. It lets members remain good-standing dependent. It lets nodes and hosts become legible. It lets Marketplace become useful without implying endorsement. It lets Digital Public Goods become reusable without hiding lifecycle state. It lets Foundry packages mature stage by stage. It lets Studio workflows become powerful without becoming hidden authority. It lets public authorities engage without being misrepresented. It lets finance readers understand readiness without confusing it with execution. It lets protocol enforce recorded state. It lets correction become visible. In strategic terms, Registry is the memory and control spine of Nexus. It is how the system knows what it has said, what it has recognized, what it has corrected, and what it may claim. *** ### 4.57 Final Statement on Registry Registry is the records-valid architecture of standing, status, recognition, correction, entitlement, and institutional memory in the Nexus Ecosystem. It is one of the load-bearing structures of the entire Nexus architecture because it makes institutional state legible, reviewable, current, scoped, enforceable where appropriate, and correctable over time. Through Registry, Nexus ensures that recognition is not courtesy, membership is not nominal, councils are not theatre, nodes are not misdescribed, hosts are not overread, Marketplace listings are not endorsements by default, public authority learning is not adoption, finance-readable readiness is not finance execution, and public language does not outrun recorded truth. Registry is not a directory. It is not a catalogue. It is not a public relations surface. It is the living institutional memory of Nexus. It records what is true. It shows what is current. It preserves what is historical. It narrows what is overclaimed. It corrects what is wrong. It retires what is no longer active. It supports protocol effect without surrendering to technical overreach. It gives public-good architecture the discipline to remember, govern, and correct itself. In Nexus, standing is not assumed. Standing is recorded. Through Registry, Nexus becomes capable of durable trust. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.therisk.global/organization/introduction/standardization/iv.-registry.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.