# XIII. REGISTRY

## 13.1 Registry Doctrine

### 13.1.1 Registry as status-truth surface.

The **Nexus Registry** under the Distributed Digital Public Goods Framework shall function as the authoritative status-truth surface for recorded digital-public-good objects within the Nexus Ecosystem. It shall preserve the current recorded status of software objects, data objects, metadata objects, model objects, AI-agent objects, ontology objects, schema objects, API objects, dashboard objects, digital twin objects, simulation objects, notebook objects, report objects, learning objects, credential objects, Campaign objects, Marketplace objects, Studio workflow objects, Grid and TRL objects, proof receipt objects, National Portfolio objects, Nexus Universe objects, lawful handoff objects, correction records, withdrawal records, recall records, archive records, and non-continuation records.

Registry status shall answer the question: **what is this object, what is its current recorded state, who stewards it, what version is current, what review has occurred, what support applies, what restrictions apply, what correction path exists, and what boundary notices travel with it?** The Registry shall not answer, by implication, whether an object is certified, approved, procured, financed, insured, endorsed, legally adopted, community-consented, Indigenous-consented, deployment-authorized, or executable. Status truth shall be record truth, not authority truth.

### 13.1.2 Registry as lifecycle record.

The Nexus Registry shall preserve the lifecycle of DDPGF objects from concept, intake, classification, draft, build, review, public-safe transformation, Registry recording, Marketplace listing, publication, support, deprecation, suspension, correction, supersession, withdrawal, recall, archive, and non-continuation. The lifecycle record shall identify material changes, responsible stewards, review events, support changes, license changes, access changes, public-safe changes, sensitivity changes, dependency changes, and correction events.

Lifecycle recording shall prevent silent drift, stale reuse, unsupported adoption, untracked forks, unrecorded localization, uncontrolled derivative use, and ambiguous status. Every material object shall have a record sufficient to support traceability, correctionability, safe reuse, lawful handoff context, and institutional memory.

### 13.1.3 Registry as version-control surface.

The Nexus Registry shall provide version-control memory for DDPGF objects, including semantic versions, data versions, model versions, schema versions, API versions, report versions, dashboard versions, credential versions, translation versions, localization versions, and archive versions. The Registry may link to Git repositories, data repositories, model repositories, Zenodo deposits, national repositories, controlled repositories, secure repositories, Marketplace listings, Reports, Studio workflows, Grid inputs, TRL notes, proof receipts, and handoff packages, but it shall preserve its own status truth independent of any single repository surface.

Version control in the Registry shall distinguish current versions, prior versions, superseded versions, withdrawn versions, recalled versions, deprecated versions, archived versions, forked versions, localized versions, translated versions, and successor versions. A version record shall not create legal equivalence, standards equivalence, credential equivalence, national equivalence, model equivalence, data equivalence, or public authority equivalence by default.

### 13.1.4 Registry as support-status surface.

The Nexus Registry shall record support status for DDPGF objects, including supported, unsupported, experimental, reference-only, community-maintained, institutionally maintained, secure-room-supported, handoff-recipient-supported, deprecated, suspended, withdrawn, recalled, archived, or non-continuing. Support status shall identify maintainers, stewards, support channels, security channels, issue-reporting routes, correction routes, documentation status, maintenance frequency where applicable, and known limitations.

Support status shall not create warranty, service-level commitment, operational support obligation, professional reliance, procurement eligibility, deployment readiness, financeability, insurability, or execution authority unless separately and lawfully contracted or recorded outside default Registry status.

### 13.1.5 Registry as correction surface.

The Nexus Registry shall operate as a correction surface by recording corrections, addenda, errata, supersessions, withdrawals, retractions where necessary, recalls, public repair actions, dependency impacts, Marketplace delistings, repository updates, publication updates, Studio shutdowns, Grid or TRL downgrades, handoff recalls, archive changes, and non-continuation decisions. The Registry shall make correction status visible to users who discover, cite, download, use, localize, translate, fork, teach, review, support, route, publish, or hand off an object.

Correction status shall travel with the object. Where a corrected object has dependent objects, the Registry shall support correction propagation by identifying affected versions, linked packages, related identifiers, derivative objects, localized objects, translated objects, Marketplace listings, repository deposits, reports, dashboards, Studio workflows, Grid records, TRL notes, and handoff packages requiring review.

### 13.1.6 Registry as archive surface.

The Nexus Registry shall preserve archive memory for objects that are no longer active, supported, recommended for current use, public-safe for current release, technically current, legally current, licensed for continued use, or suitable for downstream routing. Archive status may apply to retired reports, obsolete software, superseded datasets, outdated model cards, withdrawn dashboards, deprecated APIs, closed Campaigns, completed Nexus Universe outputs, retired learning objects, expired credentials, non-continuing National Portfolio objects, and recalled handoff context notes.

Archive shall preserve institutional memory without creating current authority. Archived objects shall remain visible only to the extent appropriate for record integrity, citation, audit, correction, learning, and historical understanding. Archive labels shall prevent stale reliance and shall identify successor objects where applicable.

### 13.1.7 Registry without certification.

The Nexus Registry shall not be a certification body, conformity assessment body, public authority register, procurement register, investment platform, insurance register, professional licensing register, standards authority, community consent register, Indigenous consent register, deployment authorization register, or execution authorization register by default. Registry recording means that an object exists in a governed status record; it does not mean that the object is certified, approved, endorsed, validated, financeable, insurable, procurement-ready, deployment-ready, safe for all uses, or authorized for implementation.

Where an external competent authority, certification body, regulator, standards body, public authority, university, professional body, community authority, Indigenous institution, or other lawful actor issues a separate status, the Registry may record the existence of that external status as a provenance or related-status record, but shall not convert it into Nexus certification by implication.

### 13.1.8 Registry as boundary-preservation layer.

The Nexus Registry shall preserve the boundary conditions attached to each object, including no-certification, no-warranty, no-procurement, no-finance, no-insurance, no-public-authority, no-warning, no-consent, no-deployment, no-execution, no-endorsement, no-validation, no-ranking, no-data-right, no-AI-safety-approval, no-professional-license, and no-employment notices. Boundary preservation shall apply across Marketplace listing, repository deposit, report publication, learning use, Studio use, Grid or TRL routing, Nexus Universe presentation, National Portfolio use, and lawful handoff context.

The Registry shall be designed so that status, provenance, review, support, and visibility cannot be mistaken for authority, approval, certification, finance, procurement, consent, deployment, or execution. Where boundary overclaim occurs, the Registry shall trigger correction, suspension, delisting, withdrawal, recall, public repair, or archive action as appropriate.

## 13.2 Registry Record Classes

### 13.2.1 Object record.

An **Object Record** shall identify the object recorded in the Registry, including unique identifier, title, object family, object class, version, steward, source pathway, jurisdictional context, access class, lifecycle state, repository link where applicable, Marketplace link where applicable, Reports link where applicable, Studio link where applicable, Grid or TRL link where applicable, proof receipt link where applicable, and lawful handoff context where applicable. The Object Record shall be the primary Registry anchor for status truth.

An Object Record shall not by itself create approval, certification, procurement status, financeability, insurability, public authority status, consent, deployment authorization, or execution authority.

### 13.2.2 Status record.

A **Status Record** shall identify the current recorded state of an object, including draft, active, under review, public-safe, controlled, supported, unsupported, deprecated, suspended, withdrawn, recalled, superseded, archived, or non-continuing. The Status Record shall include status date, status steward, status reason where appropriate, related correction record where applicable, successor object where applicable, and boundary notices.

Status shall be displayed plainly and shall not be disguised by Marketplace presentation, repository visibility, publication availability, or historic citations.

### 13.2.3 Version record.

A **Version Record** shall identify a specific version of an object, including version number or label, release date, change summary, predecessor, successor, related identifiers, repository tag or release, DOI where applicable, compatibility notes, dependency notes, localization notes, translation notes, support status, and correction status. Version Records shall preserve object lineage and prevent ambiguity between versions.

A Version Record shall not imply that different versions are legally equivalent, technically equivalent, semantically equivalent, credential-equivalent, data-equivalent, model-equivalent, deployment-equivalent, or nationally equivalent unless separately recorded within scope.

### 13.2.4 Review record.

A **Review Record** shall document reviews performed on an object, including technical review, data review, AI-use review, cyber review, privacy review, public-safe review, safeguard review, accessibility review, license review, standards-interface review, finance-boundary review, procurement-boundary review, public authority boundary review, handoff review, and correction review. The Review Record shall identify review date, reviewer class, scope of review, limitations, outcome, required actions, and next review trigger.

Review shall be evidence of review only. It shall not constitute certification, approval, endorsement, public authority decision, procurement readiness, financeability, insurability, deployment authorization, or execution authority by default.

### 13.2.5 Data-use record.

A **Data-Use Record** shall identify data-use status for a data object or data-bearing object, including open data, public-safe data, controlled public data, restricted data, public authority-sensitive data, community-sensitive data, Indigenous protocol-sensitive data where applicable, protected knowledge, youth data, health-sensitive data, cyber-sensitive data, infrastructure-sensitive data, geospatial-sensitive data, handoff-recipient-only data, archive-only data, or metadata-only status. It shall include rights basis, access class, permitted uses, prohibited uses, AI-use restrictions where applicable, cross-border restrictions, retention rules, and correction pathway.

A Data-Use Record shall not grant data rights beyond the recorded permission and shall not create unrestricted reuse, AI training permission, protected knowledge permission, consent, public authority record status, or handoff permission by implication.

### 13.2.6 AI-use record.

An **AI-Use Record** shall identify how AI may be used with or within an object, including no-AI use, retrieval-only, summarization with review, classification with review, evaluation-only, fine-tuning permitted, training permitted, agentic use prohibited, secure-room AI only, or public-safe AI output only. It shall identify human review requirements, prohibited uses, tool permissions, logging requirements, output review requirements, model card links, system card links, benchmark card links, incident pathways, and withdrawal conditions.

An AI-Use Record shall not create AI safety certification, automated decision authority, general validation, deployment authorization, public authority approval, procurement readiness, financeability, insurability, or execution authority.

### 13.2.7 License record.

A **License Record** shall identify the license or rights status of an object, including software license, data license, content license, model license, API terms, credential terms, repository terms, controlled-use statement, all-rights-reserved status, public-domain-equivalent status where applicable, attribution requirements, derivative-use rules, commercial-use status, redistribution rules, AI-use limits, and third-party rights constraints.

A License Record shall not override privacy law, data protection, protected knowledge controls, Indigenous protocols where applicable, community safeguards, public authority restrictions, cyber-sensitive restrictions, export controls, contractual restrictions, repository terms, or applicable law.

### 13.2.8 Support record.

A **Support Record** shall identify support status, support steward, maintainer class, support channels, issue channels, security channels, documentation status, support scope, known limitations, maintenance cadence where applicable, end-of-support date where applicable, deprecation date where applicable, and correction channel. Support Records shall help users understand whether an object is maintained, experimental, unsupported, deprecated, archived, or non-continuing.

Support Records shall not create warranty, service-level commitment, professional duty, operational support obligation, production readiness, procurement status, deployment authorization, or reliance right by implication.

### 13.2.9 Provider contribution record.

A **Provider Contribution Record** shall identify contributions made by providers, vendors, platforms, infrastructure hosts, technical companies, operators, consultants, developers, or enterprise actors to an object. The record shall identify contribution type, scope, date, object affected, steward review, provider-neutrality conditions, conflict disclosures, support status, and boundary notices.

Provider contribution shall not create provider validation, preferred-provider status, procurement recommendation, certification, product approval, technical superiority claim, deployment authorization, financeability, or execution authority.

### 13.2.10 Sponsor support record.

A **Sponsor Support Record** shall identify sponsor, donor, funder, host, or supporter contributions to an object, including funding support, in-kind support, infrastructure support, event support, translation support, accessibility support, repository support, publication support, Campaign support, or Nexus Universe support. The record shall identify support scope, date, restrictions if any, support ledger linkage, conflict controls, sponsor-boundary notices, and no-control terms.

Sponsor support shall not create sponsor control, sponsor approval, sponsor ownership, sponsor endorsement, preferential Marketplace placement, Registry influence, review influence, procurement relevance, finance relevance, public authority relevance, or execution authority.

### 13.2.11 Public authority participation record.

A **Public Authority Participation Record** shall identify public authority participation in learning, observation, dialogue, review, consultation, National Portfolio formation, Nexus Universe rooms, Studio workflows, public authority learning rooms, Campaigns, Reports, or handoff-context discussions. The record shall identify the public authority participant class, participation scope, date, non-decision status, public-safe conditions, confidentiality conditions where applicable, and boundary notices.

Public authority participation shall not create public authority approval, official adoption, regulatory decision, public finance allocation, permit, license, emergency warning, procurement decision, policy commitment, or execution authorization by implication.

### 13.2.12 Correction record.

A **Correction Record** shall document an error, overclaim, outdated status, unsafe language, broken dependency, data issue, AI-use issue, cyber issue, privacy issue, protected knowledge issue, accessibility issue, license issue, public authority boundary issue, finance boundary issue, procurement boundary issue, consent boundary issue, deployment overclaim, or execution overclaim. It shall identify affected objects, correction type, correction date, steward, reason, action taken, affected versions, successor object where applicable, Marketplace action, repository action, Reports action, and propagation requirements.

Correction Records shall remain part of object memory and shall not be silently removed except where lawful deletion, privacy, security, or protected knowledge requirements require controlled handling.

### 13.2.13 Withdrawal record.

A **Withdrawal Record** shall document removal of an object from active use, publication, listing, support, distribution, or handoff context. Withdrawal may occur because of error, unsafe content, license issue, data rights issue, protected knowledge exposure, AI risk, cyber risk, privacy issue, public-safe failure, boundary overclaim, obsolete content, unsupported status, or institutional decision. The record shall include withdrawal date, reason, scope, affected versions, user notice, successor object where applicable, archive status, and correction pathway.

Withdrawal shall signal that the object should not be used within the withdrawn scope. Withdrawal shall not erase historical memory unless lawful deletion or sealing is required.

### 13.2.14 Recall record.

A **Recall Record** shall document urgent or material recall of an object, package, listing, report, dataset, model, software release, dashboard, Studio workflow, Grid input, TRL note, or handoff context due to serious safety, privacy, security, public-safe, protected knowledge, legal, boundary, or reliance concerns. Recall may trigger Marketplace delisting, repository notice, Registry status update, public-safe notice, Studio shutdown, handoff recall, downstream notice, and archive action.

Recall shall prioritize harm reduction, affected-party notification where appropriate, correction propagation, and prevention of continued reliance. Recall shall not substitute for public authority action, legal compliance, emergency response, or competent downstream remedial action where required.

### 13.2.15 Archive record.

An **Archive Record** shall document final or historical preservation of an object, including archive date, reason, lifecycle state, prior status, successor object where applicable, repository location, access class, sensitivity class, license status, correction status, support status, and permitted historical uses. Archive Records shall preserve institutional memory while preventing current-use confusion.

Archive shall not create current authority, current support, current approval, current certification, current procurement relevance, current finance relevance, current deployment authorization, or execution authority.

## 13.3 Status Truth Classes

### 13.3.1 Draft.

**Draft** status shall indicate that an object exists in preliminary form and has not completed required review, public-safe transformation, Registry recording, release approval within scope, or support classification. Draft objects may be incomplete, unreviewed, unstable, unsuitable for public release, unsuitable for reliance, and subject to major change.

Draft status shall not permit external reliance, publication overclaim, Marketplace promotion, handoff use, procurement use, finance use, public authority use, or deployment use unless separately and narrowly recorded.

### 13.3.2 Active.

**Active** status shall indicate that an object is current within its recorded scope and is available for the access, use, discovery, learning, contribution, support, routing, or publication class recorded in the Registry. Active status shall require steward identification, version identification, access class, support class, correction pathway, and boundary notices.

Active status shall not mean approved, certified, procurement-ready, financeable, insurable, endorsed, public-authority-adopted, deployment-ready, or execution-authorized.

### 13.3.3 Under review.

**Under Review** status shall indicate that an object is being assessed for technical, data, AI-use, cyber, privacy, public-safe, safeguard, accessibility, license, standards-interface, public authority boundary, finance boundary, procurement boundary, handoff, correction, or archive issues. During review, access, listing, distribution, support, publication, or handoff routing may be limited, flagged, suspended, or controlled.

Under Review status shall not be presented as positive validation or negative determination. It means review is pending or ongoing.

### 13.3.4 Public-safe.

**Public-Safe** status shall indicate that an object, summary, listing, report, dashboard, metadata record, or publication has been reviewed for public-safe release within recorded scope. Public-safe status may reflect removal, masking, aggregation, generalization, or transformation of sensitive content and inclusion of required boundary notices.

Public-safe status shall not mean unrestricted, complete, raw, approved, certified, public-authority-endorsed, warning-authorized, financeable, procurement-ready, or deployment-ready.

### 13.3.5 Controlled.

**Controlled** status shall indicate that an object may exist, be recorded, or be discoverable but is subject to access controls, purpose limits, secure rooms, data rooms, clean rooms, protected knowledge rooms, public authority learning rooms, readiness rooms, handoff-recipient-only access, or metadata-only exposure. Controlled status may apply to restricted data, models, dashboards, Studio workflows, handoff packages, protected knowledge, cyber-sensitive objects, infrastructure-sensitive objects, public authority-sensitive objects, or community-sensitive objects.

Controlled status shall not create access entitlement or reuse permission. Access remains conditional, revocable, purpose-limited, and governed.

### 13.3.6 Supported.

**Supported** status shall indicate that an object has an active support model within recorded scope, such as maintainer support, community support, institutional support, secure-room support, handoff-recipient support, documentation support, security channel support, or correction support. Supported status shall identify support scope and limitations.

Supported status shall not create warranty, service-level agreement, operational reliance right, procurement eligibility, deployment readiness, or professional duty unless separately recorded.

### 13.3.7 Unsupported.

**Unsupported** status shall indicate that an object is available only without active maintenance, response obligation, support channel, update commitment, or operational assurance, except for correction or archive duties where applicable. Unsupported objects may be used for learning, historical, reference, or limited reuse purposes subject to license, access class, and boundary notices.

Unsupported status shall require prominent caution where continued use could create risk, outdated reliance, security exposure, or dependency failures.

### 13.3.8 Deprecated.

**Deprecated** status shall indicate that an object remains accessible or recorded but is no longer recommended for new use within its prior scope. Deprecation may occur because a successor exists, technology changed, standards-interface mapping changed, data became stale, support ended, risks increased, public-safe concerns emerged, or a better object replaced it.

Deprecated status shall include successor references where applicable, end-of-support notes, migration guidance where appropriate, and boundary notices against stale reliance.

### 13.3.9 Suspended.

**Suspended** status shall indicate that an object’s use, listing, publication, routing, support, or handoff relevance has been temporarily paused due to review, incident, uncertainty, boundary concern, legal issue, data issue, AI issue, cyber issue, privacy issue, protected knowledge issue, or public-safe concern. Suspended status shall identify reason, date, steward, affected versions, and next review condition where possible.

Suspension shall be visible enough to prevent continued reliance and shall not be hidden by repository availability, cached copies, or Marketplace visibility.

### 13.3.10 Withdrawn.

**Withdrawn** status shall indicate that an object has been removed from active use, listing, publication, distribution, support, or handoff relevance within a recorded scope. Withdrawal may be permanent or may precede corrected reissue. Withdrawal shall identify reason, date, affected versions, successor object where applicable, archive status, and correction pathway.

Withdrawn status shall mean that users should not rely on the object within the withdrawn scope.

### 13.3.11 Recalled.

**Recalled** status shall indicate that an object has been urgently or materially recalled due to serious safety, security, privacy, public-safe, protected knowledge, legal, data, AI, boundary, reliance, or downstream-use concern. Recall shall require heightened notice, propagation to related objects, Marketplace action, repository action, Reports action, Studio action, Grid or TRL action, and handoff recall where applicable.

Recalled status shall be treated as a stop-the-line status for affected uses until correction, replacement, archive, or competent resolution occurs.

### 13.3.12 Superseded.

**Superseded** status shall indicate that a newer version, successor object, corrected object, localized object, translated object, replacement method, replacement dataset, replacement model, replacement software release, replacement report, replacement schema, replacement API, replacement dashboard, or replacement handoff context has replaced the prior object within recorded scope. Superseded objects may remain accessible for historical traceability.

Superseded status shall not erase prior records but shall prevent current-use confusion.

### 13.3.13 Archived.

**Archived** status shall indicate that an object is preserved for institutional memory, citation, audit, research history, correction traceability, or historical understanding, and is not current for active use unless expressly stated. Archive may be open, controlled, secure, sealed, metadata-only, or restricted.

Archived status shall not create current authority, support, certification, approval, procurement relevance, finance relevance, deployment authorization, or execution authority.

### 13.3.14 Non-continuing.

**Non-Continuing** status shall indicate that an object, project, pathway, Campaign, build, report series, dataset, model, software component, learning object, Studio workflow, or handoff context will not continue into a next cycle. Non-continuation may result from lack of evidence, lack of support, changed priorities, safety concerns, public-safe concerns, rights constraints, insufficient demand, corrected direction, or strategic retirement.

Non-continuation shall be recorded with reasons where appropriate, archive instructions, successor alternatives where applicable, and correction implications.

## 13.4 Provenance Records

### 13.4.1 Source pathway.

A **Source Pathway** record shall identify where an object came from, including Nexus Foundry, Nexus Labs, Nexus Academy, Risk Academy, Nexus Campaigns, Nexus Reports, Nexus Marketplace, Nexus Registry, Nexus Studio, Nexus Grid, Nexus Observatory, DICE, GRIx, DRI, National Nodes, National Working Groups, Competence Cells, Nexus Universe, public authority learning rooms, secure rooms, data rooms, repositories, external partners, community contributions, provider contributions, sponsor-supported work, or lawful handoff pathways.

Source pathway shall clarify origin without implying endorsement, approval, certification, public authority status, procurement status, finance status, consent, or execution authority.

### 13.4.2 Author record.

An **Author Record** shall identify authors or drafting stewards of reports, papers, technical notes, learning objects, documentation, schemas, methods, models, dashboards, or other written or constructed objects. Author Records shall include role, contribution scope, affiliation where appropriate, date, conflict disclosures where required, and correction contact where appropriate.

Author identity shall not imply institutional approval, personal liability, public authority status, certification authority, or professional reliance unless separately recorded.

### 13.4.3 Contributor record.

A **Contributor Record** shall identify contributors who provide code, data, documentation, review, translation, accessibility work, learning content, campaign support, public-safe reporting, issue reports, bug fixes, model work, schema work, ontology work, dashboard work, Studio work, or other public-good contributions. Contributor Records shall include contribution type, date, scope, license or contribution terms, iCRS linkage where applicable, privacy settings where applicable, and correction status.

Contribution shall not create employment, compensation right, equity, token right, procurement qualification, certification, endorsement, or execution authority by implication.

### 13.4.4 Maintainer record.

A **Maintainer Record** shall identify maintainers responsible for object stewardship, repository stewardship, release management, review coordination, support channels, documentation updates, issue triage, security reporting, correction management, deprecation, withdrawal, and archive. Maintainer Records shall include maintainer class, scope, standing, renewal status, conflicts, support duties, and removal or downgrade conditions.

Maintainer status shall not create professional license, deployment authority, public authority status, procurement authority, finance authority, or execution authority.

### 13.4.5 Reviewer record.

A **Reviewer Record** shall identify reviewers involved in technical, data, AI-use, cyber, privacy, public-safe, safeguard, accessibility, license, standards-interface, public authority boundary, finance boundary, procurement boundary, handoff, or correction review. Reviewer Records shall include review scope, date, limitations, outcome, conflict disclosures, and required follow-up.

Reviewer participation shall not create certification, endorsement, public authority approval, procurement status, financeability, insurability, or deployment authorization.

### 13.4.6 Data provenance.

A **Data Provenance Record** shall document the origin, collection method, generation method, transformation history, lineage, aggregation, synthetic generation, cleaning, labeling, public-safe transformation, rights basis, access class, sensitivity class, data-use label, AI-use label, and correction history of data objects. Data provenance shall support trust, traceability, reproducibility where safe, and responsible reuse.

Data provenance shall not create data ownership, reuse rights, training rights, cross-border transfer permission, protected knowledge permission, community consent, Indigenous consent, or public authority status by implication.

### 13.4.7 Model provenance.

A **Model Provenance Record** shall document the origin, purpose, training or configuration basis, data sources where disclosable, architecture class, evaluation history, benchmark history, tuning history, deployment constraints, intended uses, prohibited uses, human review requirements, AI-use label, incident history, correction history, and withdrawal status of model objects and AI system objects.

Model provenance shall not create AI safety certification, general validation, public authority approval, automated decision authority, procurement readiness, financeability, insurability, or deployment authorization.

### 13.4.8 Dependency provenance.

A **Dependency Provenance Record** shall identify dependencies required by or linked to an object, including software dependencies, data dependencies, model dependencies, schema dependencies, API dependencies, infrastructure dependencies, license dependencies, security dependencies, public authority dependencies, safeguard dependencies, finance or insurance question dependencies, procurement boundary dependencies, and handoff dependencies. Dependency provenance shall support correction propagation and safe reuse.

A Dependency Provenance Record shall not guarantee availability, compatibility, security, legality, financeability, insurability, public authority approval, or implementation readiness.

### 13.4.9 Support provenance.

A **Support Provenance Record** shall identify how support status emerged, including maintainer assignment, sponsor support, provider contribution, community maintenance, institutional support, repository support, security support, documentation support, secure-room support, handoff-recipient support, or support discontinuation. Support provenance shall make visible whether support is active, limited, conditional, expired, experimental, withdrawn, or archived.

Support provenance shall not create warranty, service-level agreement, procurement qualification, or operational reliance.

### 13.4.10 Correction provenance.

A **Correction Provenance Record** shall identify the history of errors, corrections, addenda, supersessions, withdrawals, recalls, public repairs, version changes, dependent-object updates, Marketplace delistings, repository notices, report corrections, Studio shutdowns, Grid or TRL downgrades, and handoff recalls. Correction provenance shall preserve trust by making correction history visible and traceable.

Correction provenance shall not be hidden to preserve reputation where users require it for safe reuse, unless privacy, security, legal, protected knowledge, or safety reasons require controlled disclosure.

## 13.5 Versioning

### 13.5.1 Semantic versioning.

Semantic versioning may be used for software objects, API objects, schema objects, public-good technical baselines, reference implementations, documentation packages, and other objects where major, minor, and patch distinctions help users understand compatibility, breaking changes, feature additions, and corrections. Semantic versioning shall be linked to release notes, changelogs, repository tags, support status, security status, correction records, and deprecation plans.

Semantic versioning shall not imply production readiness, security certification, procurement readiness, deployment authorization, or warranty.

### 13.5.2 Data versioning.

Data versioning shall be used for datasets, metadata records, public-safe datasets, aggregated datasets, synthetic datasets, feature sets, benchmark datasets, DRI datasets, Observatory datasets, National Portfolio datasets, and data dictionaries where changes in source, lineage, quality, rights status, sensitivity, access, public-safe transformation, or correction may affect reuse. Data versioning shall identify source changes, schema changes, quality changes, missingness changes, correction changes, aggregation changes, and access changes.

Data versioning shall not create unrestricted reuse rights, AI training rights, data transfer rights, or equivalence between datasets.

### 13.5.3 Model versioning.

Model versioning shall be used for model objects, AI systems, agentic workflows, classifiers, forecasting models, simulation models, digital twin models, risk models, optimization models, evaluation harnesses, model cards, system cards, and benchmark cards. Model versioning shall identify training or configuration changes, evaluation changes, data changes, intended-use changes, prohibited-use changes, safety changes, bias or harm review changes, human review changes, incident changes, withdrawal changes, and archive changes.

Model versioning shall not imply AI safety approval, general validation, deployment authorization, public authority approval, procurement readiness, financeability, or insurability.

### 13.5.4 Schema versioning.

Schema versioning shall be used for data schemas, metadata schemas, API schemas, evidence schemas, report schemas, Registry schemas, Marketplace schemas, Studio workflow schemas, Grid schemas, TRL evidence schemas, credential schemas, proof receipt schemas, correction schemas, and archive schemas. Schema versioning shall identify breaking changes, backward compatibility, mapping needs, localization impacts, translation impacts, and affected objects.

Schema versioning shall not create standards authority, conformance certification, legal equivalence, or public authority adoption.

### 13.5.5 API versioning.

API versioning shall be used for public APIs, controlled APIs, internal APIs, data APIs, model APIs, Registry APIs, Marketplace APIs, Studio APIs, Campaign APIs, Reports APIs, DRI APIs, Observatory APIs, credential APIs, proof receipt APIs, and handoff APIs. API versioning shall identify endpoint changes, authentication changes, authorization changes, rate limit changes, output changes, deprecation notices, data-use changes, AI-use changes, and compatibility impacts.

API versioning shall not create data rights, uptime warranty, provider validation, procurement status, or deployment authorization.

### 13.5.6 Report versioning.

Report versioning shall be used for reports, data papers, software release papers, technical notes, public-safe summaries, National Portfolio Reports, WFEH-B Reports, DRR Reports, DRF Reports, DRI Reports, DICE Reports, GRIx Reports, Observatory Reports, Foundry Reports, Campaign Reports, Academy Reports, Labs Reports, Risk Agency Reports, Nexus Universe Reports, Grid and TRL Reports, handoff context notes, correction reports, and archive reports. Report versioning shall identify content changes, evidence changes, public-safe changes, correction changes, license changes, DOI changes, repository changes, and boundary notice changes.

Report versioning shall not create approval, certification, public warning, financeability, procurement readiness, or execution authority.

### 13.5.7 Dashboard versioning.

Dashboard versioning shall be used for dashboard objects, visual atlases, DRI dashboards, Observatory dashboards, WFEH-B dashboards, Campaign dashboards, Foundry dashboards, Reports dashboards, Marketplace dashboards, Registry dashboards, Academy dashboards, Studio dashboards, Grid dashboards, National Portfolio dashboards, and handoff dependency dashboards. Dashboard versioning shall identify data changes, visual changes, indicator changes, methodology changes, confidence or uncertainty changes, sensitivity masking changes, update cadence changes, public-safe changes, and correction changes.

Dashboard versioning shall not create public authority decision, rating, ranking, warning, forecast certainty, finance signal, insurance signal, or deployment authorization.

### 13.5.8 Credential versioning.

Credential versioning shall be used for learning objects, micro-credentials, badges, competency records, WILP records, skill records, assessment records, instructor packs, Academy pathways, Risk Academy pathways, and ILA-linked objects. Credential versioning shall identify competency changes, evidence changes, assessment changes, expiry changes, renewal changes, suspension changes, withdrawal changes, display changes, and correction changes.

Credential versioning shall not create professional license, degree equivalence, employment eligibility, procurement qualification, immigration status, wage guarantee, or public authority credential by implication.

### 13.5.9 Translation versioning.

Translation versioning shall be used for translated reports, learning objects, guides, metadata, dashboards, public-safe summaries, Campaign materials, API documentation, software documentation, community guides, public authority learning guides, and handoff literacy objects. Translation versioning shall identify source version, target language, translator or steward, review status, localization changes, semantic differences, public-safe changes, and correction status.

Translation versioning shall not create legal equivalence, standards equivalence, credential equivalence, public authority adoption, national endorsement, or community consent by default.

### 13.5.10 Archive versioning.

Archive versioning shall preserve the final archived state of objects, including prior active version, archive date, reason for archive, support status, withdrawal or recall status, successor object where applicable, access class, sensitivity class, repository location, correction history, and permitted historical-use scope. Archive versioning shall ensure that historical records remain traceable without being confused for current active objects.

Archive versioning shall not create current authority, current support, current approval, current certification, current procurement status, current finance relevance, current deployment authorization, or execution authority.

## 13.6 Registry Boundary Rules

### 13.6.1 Registry status is not certification.

Registry status shall not constitute certification, conformity assessment, quality certification, AI safety certification, security certification, environmental certification, professional certification, maturity certification, standards certification, procurement certification, finance certification, insurance approval, or public authority approval. Registry status records lifecycle state only.

### 13.6.2 Active status is not approval.

Active status shall mean that an object is current within recorded scope and available under recorded access, support, and boundary conditions. Active status shall not mean that the object is approved, endorsed, adopted, certified, procurement-ready, financeable, insurable, deployment-ready, public-authority-approved, community-consented, Indigenous-consented, or executable.

### 13.6.3 Support status is not warranty.

Support status shall not create warranty, service-level agreement, professional reliance, fitness-for-purpose representation, uptime commitment, security guarantee, operational duty, procurement eligibility, deployment support obligation, or execution obligation unless separately and lawfully contracted or recorded outside default Registry status.

### 13.6.4 Version record is not legal equivalence.

A Version Record shall not create legal equivalence, standards equivalence, credential equivalence, national equivalence, translation equivalence, data equivalence, model equivalence, API compatibility, deployment equivalence, or public authority equivalence by implication. Equivalence requires separate review, mapping, approval, or competent authority where applicable.

### 13.6.5 Provenance record is not endorsement.

A Provenance Record identifying authors, contributors, maintainers, reviewers, providers, sponsors, public authority participants, repositories, institutions, communities, or downstream actors shall not imply endorsement, approval, certification, validation, provider preference, sponsor control, public authority adoption, finance interest, insurance interest, procurement intent, community consent, Indigenous consent, deployment authorization, or execution authority.

### 13.6.6 Archive record is not current authority.

An Archive Record shall preserve historical memory, citation traceability, correction history, and institutional learning. Archive status shall not create current authority, current approval, current certification, current support, current procurement relevance, current financeability, current insurability, current public authority status, current consent, deployment authorization, or execution authority.


---

# 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/operations/frameworks/distributed-digital-public-goods-framework-ddpgf/xiii.-registry.md?ask=<question>
```

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.