# XV. READINESS

## 15.1 Digital Object Readiness Doctrine

### 15.1.1 Readiness as bounded evidence.

**Digital Object Readiness** under the Distributed Digital Public Goods Framework shall mean the recorded, bounded, evidence-based condition of a digital public-good object at a specific point in its lifecycle, within a defined scope, for defined uses, under recorded assumptions, limitations, dependencies, controls, support conditions, and boundary notices. Readiness may apply to software objects, data 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, Registry records, Studio workflows, Grid inputs, TRL notes, proof receipt objects, National Portfolio objects, Nexus Universe objects, and lawful handoff objects.

Readiness shall be evidence-bearing, not reputational. It shall be based on recorded review, testing, documentation, provenance, access class, support status, public-safe status, data-use status, AI-use status, cyber status, privacy status, safeguard status, interoperability status, correction history, and archive status. Readiness shall be bounded by scope: an object may be ready for learning but not for handoff; ready for Studio demonstration but not deployment; ready for public-safe summary but not raw-data release; ready for controlled review but not open publication; ready for Registry recording but not Marketplace listing; ready for handoff-context discussion but not enterprise execution.

### 15.1.2 Readiness as review-routing surface.

Digital Object Readiness shall function as a **review-routing surface** that determines which reviews, gates, rooms, workflows, stewards, records, and boundary controls must apply before an object may move to another lifecycle state. Readiness shall route objects to technical review, data review, AI-use review, cyber review, privacy review, public-safe review, safeguard review, accessibility review, license review, standards-interface review, Marketplace review, Registry review, Studio review, Grid review, TRL review, handoff review, archive review, or correction review as appropriate.

Readiness shall not be a single approval mark. It shall operate as a structured routing logic that identifies what has been reviewed, what remains unresolved, what risks require control, what dependencies must be transferred, what assumptions must be recorded, what limitations must be disclosed, and what lifecycle movement is permitted. An object shall not be advanced by enthusiasm, visibility, sponsor support, provider contribution, public authority attendance, capital-reader interest, Marketplace demand, or Nexus Universe presentation where required readiness evidence is absent.

### 15.1.3 Readiness as support-status surface.

Digital Object Readiness shall include support status. An object may be technically complete but unsupported; publicly released but experimental; Registry-recorded but not maintained; listed in Marketplace but community-maintained only; available for learning but not for operational use; archived but still citable; or handoff-relevant but requiring recipient responsibility. Support status shall be recorded plainly and shall travel with the object across Registry, Marketplace, Reports, Studio, Grid, TRL, Academy, Foundry, Campaign, Nexus Universe, National Portfolio, and lawful handoff contexts.

Support status may include supported, unsupported, experimental, reference-only, community-maintained, institutionally maintained, secure-room-supported, data-room-supported, handoff-recipient-supported, deprecated, suspended, withdrawn, recalled, archived, or non-continuing. 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 DDPGF default status.

### 15.1.4 Readiness as lifecycle state.

Readiness shall be treated as a lifecycle state, not a permanent attribute. A digital public-good object may move from concept to intake, classified, draft, in build, in review, public-safe transformed, Registry-recorded, Marketplace-listed, published, supported, unsupported, deprecated, suspended, corrected, superseded, withdrawn, recalled, archived, or non-continuing. Readiness may increase, decrease, pause, expire, or be removed as evidence changes, dependencies change, data changes, models change, code changes, security status changes, public-safe conditions change, support changes, licensing changes, public authority dependencies change, safeguard conditions change, or downstream use risks emerge.

Lifecycle movement shall be recorded. No object shall silently drift into a stronger readiness state by being reused, cited, downloaded, showcased, copied, translated, localized, forked, demonstrated, or discussed. Where an object’s evidence or support weakens, the readiness state shall be downgraded, suspended, withdrawn, recalled, corrected, archived, or marked non-continuing as appropriate.

### 15.1.5 Readiness as correctionable record.

Readiness shall be correctionable. Any readiness claim, Grid input, TRL note, support status, review status, release class, Marketplace status, Registry status, Studio status, public-safe status, handoff status, or publication status may be corrected where evidence is incomplete, outdated, erroneous, unsafe, misleading, overclaimed, unsupported, improperly reviewed, affected by incident, affected by dependency change, or affected by boundary violation.

Correction may include addendum, downgrade, suspension, withdrawal, recall, supersession, public repair, Marketplace delisting, Registry update, repository notice, report correction, Studio shutdown, Grid update, TRL update, handoff recall, archive action, or non-continuation. The correction record shall identify what changed, why it changed, which objects are affected, what prior versions remain accessible, what successor objects exist, what users or recipients require notice, and what reuse must stop.

### 15.1.6 Readiness without certification.

Digital Object Readiness shall not constitute certification. A readiness record, Grid input, TRL note, review gate completion, technical review, data review, AI-use review, cyber review, privacy review, public-safe review, safeguard review, accessibility review, support status, Marketplace listing, Registry record, Report publication, Studio demonstration, Nexus Universe presentation, or handoff context shall not be described or interpreted as certification, conformity assessment, official approval, maturity certification, AI safety certification, cybersecurity certification, environmental certification, professional certification, standards certification, public authority approval, procurement certification, or deployment approval by default.

The DDPGF readiness doctrine shall preserve **assurance without certification**: it may record evidence sufficiency, review status, support status, limitations, gaps, dependencies, and correction pathways, but it shall not claim certification unless a separate competent certifying authority expressly issues such certification through its own lawful process and such external status is recorded only as an external provenance record.

### 15.1.7 Readiness without procurement status.

Digital Object Readiness shall not create procurement status. A digital public-good object may be useful, reusable, documented, secure-reviewed, public-safe, supported, Marketplace-listed, Registry-recorded, Studio-demonstrated, Grid-reviewed, TRL-noted, or handoff-relevant, but none of those states shall mean that the object is approved for procurement, preferred for procurement, qualified as a supplier offering, validated as a vendor solution, compliant with a tender, or recommended for purchase.

Procurement decisions shall remain outside DDPGF default posture and shall require competent procurement processes, independent diligence, lawful authority, conflict controls, provider-neutrality controls, and applicable rules. The Marketplace, Registry, Grid, Studio, Reports, Nexus Universe, and National Portfolio layers shall preserve procurement neutrality.

### 15.1.8 Readiness without financeability.

Digital Object Readiness shall not create financeability, insurability, investment suitability, donor suitability, public finance eligibility, underwriting approval, bankability, creditworthiness, guarantee eligibility, or transaction readiness. Readiness may identify finance-readiness questions, insurance-readiness questions, donor-readiness questions, public finance relevance questions, assumptions, dependencies, diligence gaps, support conditions, and lawful handoff context, but it shall not convert any object into a financial product, investment opportunity, insurance-approved object, or financeable asset by default.

Finance-readiness shall remain literacy, context, dependency mapping, and no-reliance readiness. Any financing, underwriting, grant allocation, public finance allocation, investment decision, or transaction shall require separate competent actors, lawful processes, regulated-perimeter controls, and recipient responsibility outside the DDPGF readiness record.

## 15.2 TRL 1–10 for Digital Public Goods

### 15.2.1 TRL 1 — basic principles observed.

**TRL 1** shall indicate that basic principles, concepts, needs, risks, methods, data possibilities, software possibilities, model possibilities, ontology needs, API needs, dashboard needs, learning needs, public-good use cases, or digital object opportunities have been observed or identified. At this level, the object may exist only as an idea, signal, problem statement, research question, Docket item, concept note, method hypothesis, National Portfolio need, Campaign signal, Observatory signal, DRI signal, Academy need, Foundry opportunity, or public authority learning question.

TRL 1 shall require a recorded purpose, source pathway, scope boundary, object class, initial steward or candidate steward, and no-conversion notice. It shall not imply feasibility, validation, technical design, public-safe readiness, support, publication readiness, handoff readiness, procurement readiness, financeability, or deployment authorization.

### 15.2.2 TRL 2 — concept formulated.

**TRL 2** shall indicate that a digital public-good concept has been formulated with preliminary purpose, intended audience, object class, expected output, initial architecture, initial data needs, initial software needs, initial model needs, initial governance needs, initial public-safe considerations, initial interoperability needs, and initial boundary conditions. At this level, the object may be represented by a concept paper, design note, draft schema, initial repository plan, model concept, dashboard mockup, API concept, learning pathway outline, Studio workflow outline, or handoff context concept.

TRL 2 shall require recorded assumptions, expected dependencies, initial risk notes, initial review needs, and preliminary lifecycle plan. It shall not imply prototype readiness, evidence sufficiency, user readiness, public release, support readiness, or handoff suitability.

### 15.2.3 TRL 3 — experimental proof of concept.

**TRL 3** shall indicate that an experimental proof of concept has been produced within a limited, controlled, non-operational, non-reliance context. This may include a prototype script, draft dataset, limited model experiment, notebook, demonstration dashboard, draft ontology, draft API, experimental Studio workflow, proof-of-concept digital twin, early simulation, pilot learning object, draft report structure, or initial public-safe summary.

TRL 3 shall require documentation of experiment scope, method, inputs, limitations, known risks, test context, review needs, and correction pathway. The object remains experimental. It shall not be represented as production-ready, public-safe unless reviewed, support-ready, deployment-ready, procurement-ready, finance-ready, or handoff-ready.

### 15.2.4 TRL 4 — component validation in lab context.

**TRL 4** shall indicate that one or more components of the digital public-good object have been tested or validated within a lab, sandbox, Foundry, Studio, secure-room, data-room, or controlled review context. Components may include code modules, data pipelines, model components, API components, schema components, dashboard components, ontology components, documentation components, learning units, report components, or public-safe transformation components.

TRL 4 shall require component-level evidence, test records, review notes, limitation notes, dependency records, support status, and correction pathway. Validation remains component-specific and lab-context-specific. It shall not be generalized to full system readiness, real-world use, public authority approval, procurement readiness, financeability, or deployment authorization.

### 15.2.5 TRL 5 — component validation in relevant environment.

**TRL 5** shall indicate that one or more components have been tested in a relevant environment that resembles intended use conditions without constituting operational deployment. Relevant environments may include a National Node sandbox, controlled data room, secure room, Nexus Studio workflow, public authority learning room, readiness room, Foundry build stream, Academy pilot, Campaign pilot, Observatory test context, DRI workflow, or controlled partner environment.

TRL 5 shall require evidence of relevant-environment testing, access controls, data-use status, AI-use status where applicable, cyber and privacy considerations, public-safe review needs, support notes, and correction records. It shall not imply full integration, production use, certification, procurement status, financeability, or lawful handoff readiness.

### 15.2.6 TRL 6 — system demonstration in relevant environment.

**TRL 6** shall indicate that a system or integrated object has been demonstrated in a relevant environment within a controlled, non-execution, non-reliance posture. This may include a working dashboard, functional software package, integrated dataset and metadata package, model workflow, AI-agent workflow under controls, Studio workflow, digital twin demonstration, simulation package, report-generation workflow, learning pathway, Marketplace listing candidate, Registry package, Grid input package, or handoff-context demonstration.

TRL 6 shall require system demonstration records, integration notes, user or reviewer feedback where applicable, known limitations, dependency mapping, public-safe status, support status, access class, and correction pathway. Demonstration shall remain demonstration. It shall not create deployment authorization, operational command, procurement readiness, financeability, insurability, or public authority approval.

### 15.2.7 TRL 7 — prototype demonstration in operationally relevant environment.

**TRL 7** shall indicate that a prototype has been demonstrated in an operationally relevant environment by or with competent actors under recorded controls, without converting the prototype into full operational deployment by default. Operationally relevant environments may include a National Portfolio context, Nexus Universe arena, public authority learning environment, controlled enterprise test environment, Project SPV evaluation context, National Consortium Company evaluation context, field-informed but non-operational testbed, secure data environment, or regulated-perimeter-aware readiness room.

TRL 7 shall require prototype scope, actor roles, controls, test conditions, evidence outputs, incident monitoring, public-safe review, support status, limitations, assumptions, recipient responsibilities where applicable, and correction pathway. TRL 7 shall not imply that the object is approved for procurement, production, finance, insurance, public authority action, or deployment.

### 15.2.8 TRL 8 — system complete and qualified within scope.

**TRL 8** shall indicate that the digital public-good object is system-complete within a recorded scope and has passed the applicable review gates required for that scope. Completion may include documentation, repository package, license review, data-use records, AI-use records, security review, privacy review, public-safe review, accessibility review, support classification, Registry status, Marketplace readiness where applicable, Reports readiness where applicable, Studio readiness where applicable, Grid input readiness, and handoff context readiness where applicable.

“Qualified within scope” shall mean that evidence and review are sufficient for the recorded use class only. TRL 8 shall not mean certified, procurement-ready, financeable, insurable, public-authority-approved, production-ready for all uses, or deployment-authorized. Any operational use must be separately authorized by competent actors.

### 15.2.9 TRL 9 — actual system proven in operational context by competent actor.

**TRL 9** shall indicate that an actual system, object, or capability has been used or proven in an operational context by a competent actor outside the default DDPGF non-execution posture, and that DDPGF records capture evidence, limitations, dependencies, support status, correction pathways, and boundary conditions relating to that use. The competent actor may be a public authority, enterprise operator, National Consortium Company, Project SPV, university, lab, provider, operator, contractor, or other lawful actor with authority to implement or operate.

TRL 9 shall not mean that DDPGF itself executed, operated, authorized, procured, financed, insured, or approved the system. It shall record that operational proof occurred by a competent actor within a separate lawful context. TRL 9 remains bounded by object scope, evidence scope, jurisdiction, use conditions, support status, and correction history.

### 15.2.10 TRL 10 — sustained, governed, corrected, supported, and handoff-traceable digital public-good capability.

**TRL 10** shall indicate a Nexus-specific extended readiness record for a digital public-good capability that has moved beyond one-time proof and is sustained through governance, support, correctionability, versioning, Registry memory, Marketplace discipline, repository maintenance, public-safe release, data and AI controls, security and privacy controls, accessibility controls, interoperability discipline, archive rules, and handoff traceability. TRL 10 may apply where an object or capability has demonstrated durable public-good usefulness, maintainability, correction maturity, support clarity, and lawful handoff traceability across cycles.

TRL 10 shall not be a certification. It shall not create procurement readiness, financeability, insurability, public authority approval, deployment authorization, provider validation, sponsor endorsement, community consent, Indigenous consent, or execution authority. It means only that the object has a sustained and governed digital-public-good readiness record within DDPGF.

### 15.2.11 TRL scope notes.

Every TRL record shall include scope notes identifying what the TRL applies to, what it does not apply to, the object class, version, environment, jurisdictional context, data basis, model basis where applicable, software basis where applicable, test basis, review basis, support status, access class, public-safe status, sensitivity class, dependencies, assumptions, limitations, reviewer scope, steward, correction pathway, and next review trigger. Scope notes shall prevent TRL overclaim and shall distinguish component readiness, system readiness, public-safe readiness, support readiness, Studio readiness, Marketplace readiness, Registry readiness, handoff-context readiness, and operational proof by competent actor.

A TRL note without scope notes shall be incomplete and shall not be used for Marketplace listing, Registry promotion, Reports claim, Nexus Universe presentation, handoff context, or public-safe release.

### 15.2.12 TRL no-certification rule.

The TRL 1–10 scale under DDPGF shall be a readiness classification and evidence-memory system only. It shall not be certification, conformity assessment, procurement approval, finance approval, insurance approval, public authority approval, safety approval, security certification, AI safety certification, maturity certification, standards certification, deployment authorization, or execution authorization. TRL records may inform learning, review, support, correction, reuse, discovery, and handoff context, but they shall not substitute for competent legal, technical, public authority, procurement, finance, insurance, professional, community, Indigenous, operational, or enterprise decisions.

## 15.3 Digital Quality Classes

### 15.3.1 Evidence quality.

**Evidence Quality** shall describe the sufficiency, traceability, reliability, relevance, completeness, transparency, reproducibility where safe, and limitation-awareness of evidence supporting a digital public-good object. Evidence quality shall consider source quality, method quality, review history, provenance, uncertainty, confidence, assumptions, dependencies, correction history, and public-safe transformation.

Evidence quality shall not be equated with certification or universal truth. It is a bounded assessment of the evidence available for the recorded object and use class.

### 15.3.2 Code quality.

**Code Quality** shall describe the maintainability, readability, test coverage, dependency discipline, secure defaults, modularity, documentation, reproducibility, accessibility where applicable, release discipline, security posture, and correctionability of software objects. Code quality may include review records, test records, dependency scan records, secret scan records, SBOM records, vulnerability records, release notes, and maintainer status.

Code quality shall not create warranty, security certification, production approval, provider validation, deployment authorization, or procurement recommendation.

### 15.3.3 Data quality.

**Data Quality** shall describe the fitness of a data object within recorded scope, including provenance, completeness, accuracy, timeliness, consistency, lineage, metadata sufficiency, rights status, sensitivity classification, missingness, bias, uncertainty, transformation history, public-safe status, and correction pathway. Data quality shall be contextual: data may be sufficient for learning but not for modeling; sufficient for public-safe summary but not for operational decision; sufficient for aggregate reporting but not for individual-level analysis.

Data quality shall not create unrestricted data rights, AI training permission, public authority record status, community consent, Indigenous consent, handoff permission, or operational reliance.

### 15.3.4 Model quality.

**Model Quality** shall describe the bounded evidence supporting a model object, AI system, simulation model, digital twin model, classifier, forecasting model, optimization model, risk model, or agentic workflow. It may include intended use, prohibited use, data provenance, evaluation records, benchmark records, bias and harm review, human review, robustness notes, drift monitoring, incident records, model card quality, system card quality, and withdrawal conditions.

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

### 15.3.5 Documentation quality.

**Documentation Quality** shall describe the clarity, completeness, accuracy, accessibility, version alignment, source traceability, public-safe language, license clarity, installation guidance, use guidance, limitations, support statement, correction pathway, and boundary notices associated with an object. Documentation may include README files, technical notes, user guides, developer guides, maintainer guides, data papers, model cards, system cards, benchmark cards, public-safe summaries, learning guides, and handoff literacy guides.

Documentation quality shall not create approval, warranty, operational readiness, procurement status, or reliance right.

### 15.3.6 Accessibility quality.

**Accessibility Quality** shall describe whether an object can be accessed, understood, navigated, reused, learned from, or reviewed by people with diverse abilities, devices, bandwidth conditions, languages, literacies, and contexts. Accessibility quality may consider screen-reader compatibility, alt text, captions, transcripts, keyboard navigation, plain-language alternatives, color contrast, low-bandwidth formats, mobile access, translation readiness, cognitive accessibility, and accommodation pathways.

Accessibility quality shall be recorded as an inclusion and usability condition, not as certification unless separately assessed by a competent accessibility authority.

### 15.3.7 Security quality.

**Security Quality** shall describe the security posture of software, data, models, APIs, infrastructure, repositories, Studio workflows, dashboards, digital twins, and controlled rooms. It may include threat modeling, secure defaults, dependency scanning, secret scanning, vulnerability disclosure, access controls, logging, encryption where appropriate, secure repositories, incident pathways, patch history, and secure-room controls.

Security quality shall not mean vulnerability-free status, cybersecurity certification, public authority approval, procurement readiness, production readiness, or deployment authorization.

### 15.3.8 Privacy quality.

**Privacy Quality** shall describe whether an object respects privacy, data minimization, purpose limitation, consent and permission records, sensitive data controls, youth data controls, health data controls, community data controls, cross-border controls, retention, deletion, sealing, access controls, AI-use restrictions, and incident response. Privacy quality may apply to data objects, learning objects, AI workflows, Studio workflows, Campaign objects, Marketplace analytics, Registry records, and user records.

Privacy quality shall not create unrestricted use permission, consent, legal compliance determination, public authority approval, or data transfer authorization by default.

### 15.3.9 Interoperability quality.

**Interoperability Quality** shall describe whether an object can interact with related objects, systems, schemas, APIs, repositories, Marketplace listings, Registry records, Studio workflows, Grid records, TRL notes, proof receipts, Academy records, DICE, GRIx, DRI, Observatory records, National Portfolio objects, and lawful handoff packages. Interoperability quality may include schema quality, API quality, metadata quality, standards-interface mapping, version compatibility, connector reliability, adapter maturity, localization support, and semantic clarity.

Interoperability quality shall not create standards certification, conformance approval, legal equivalence, provider validation, public authority adoption, or deployment authorization.

### 15.3.10 Public-safe quality.

**Public-Safe Quality** shall describe whether an object’s public or semi-public expression avoids unsafe disclosure, overclaim, misleading authority, protected knowledge exposure, sensitive geospatial exposure, privacy exposure, cyber exposure, public authority overclaim, finance overclaim, procurement overclaim, certification overclaim, consent overclaim, deployment overclaim, or execution overclaim. Public-safe quality may require masking, aggregation, generalization, plain-language transformation, sensitive detail exclusion, boundary notices, and correction pathways.

Public-safe quality shall not mean that the underlying object is open, complete, unrestricted, certified, approved, or operationally usable.

### 15.3.11 Support quality.

**Support Quality** shall describe whether an object has clear maintainer status, issue channels, security channels, documentation support, update cadence where applicable, support scope, known limitations, user guidance, correction handling, deprecation plan, withdrawal path, archive rule, and continuity expectations. Support quality may be high even where support is limited, if the limits are transparent and well-recorded.

Support quality shall not create warranty, service-level agreement, operational reliance, procurement eligibility, deployment readiness, or execution obligation.

### 15.3.12 Correction quality.

**Correction Quality** shall describe whether an object has a visible, usable, timely, accountable, traceable, and propagating correction pathway. It shall consider issue intake, error classification, severity classification, affected-object identification, correction records, version updates, Marketplace updates, Registry updates, repository notices, Reports updates, Studio updates, Grid or TRL updates, handoff recall, public repair, archive, and non-continuation.

Correction quality shall be central to trust. An object that cannot be corrected, withdrawn, recalled, superseded, or archived responsibly shall not be treated as mature within DDPGF.

## 15.4 Review Gates

### 15.4.1 Intake Gate.

The **Intake Gate** shall confirm that a digital public-good object has a recorded purpose, object class, source pathway, steward or candidate steward, intended audience, scope, expected lifecycle, initial access class, initial sensitivity class, initial public-safe considerations, initial data-use considerations, initial AI-use considerations where applicable, initial support class, and correction pathway. The Intake Gate shall determine whether the object may enter DDPGF workflow, requires restriction, requires secure handling, should be rejected, should be routed to another Nexus pillar, or should be archived as non-continuing.

Passing the Intake Gate shall not mean that the object is reviewed, approved, supported, public-safe, Marketplace-ready, Registry-ready, handoff-ready, or deployable.

### 15.4.2 Evidence Gate.

The **Evidence Gate** shall determine whether the evidence supporting an object is sufficient for the next recorded lifecycle movement. Evidence review may consider source records, method notes, test results, data provenance, model provenance, software review, documentation, user feedback, public-safe transformation, assumptions, dependencies, limitations, and correction history.

Passing the Evidence Gate shall mean only that evidence is sufficient for the next bounded step. It shall not create certification, approval, financeability, procurement status, public authority status, or deployment authorization.

### 15.4.3 Technical Gate.

The **Technical Gate** shall assess technical adequacy for the object’s class and intended lifecycle movement. It may apply to software, APIs, dashboards, digital twins, simulations, models, repositories, infrastructure-as-code, notebooks, schemas, ontologies, Studio workflows, and handoff packages. It may review architecture, functionality, maintainability, dependencies, interoperability, documentation, test records, support status, and known limitations.

Passing the Technical Gate shall not create production approval, security certification, provider validation, procurement readiness, deployment authorization, or execution authority.

### 15.4.4 Data Gate.

The **Data Gate** shall assess data status for objects containing, using, referencing, describing, deriving from, or producing data. It shall review data provenance, rights basis, data-use label, AI-use label, access class, sensitivity class, lineage, quality, missingness, bias, public-safe transformation, metadata, retention, deletion, sealing, cross-border issues, and correction pathway.

Passing the Data Gate shall not create data access rights, reuse rights, AI training permission, public authority record status, community consent, Indigenous consent, handoff permission, or data transfer authorization.

### 15.4.5 AI Gate.

The **AI Gate** shall assess AI-use status, model status, agentic workflow status, human review requirements, data provenance, training constraints, evaluation records, benchmark records, model card quality, system card quality, benchmark card quality, prompt-injection risks, tool-permission risks, bias and harm review, drift monitoring, incident response, and withdrawal conditions.

Passing the AI Gate shall not create AI safety certification, general validation, automated decision authority, public authority approval, procurement readiness, financeability, insurability, deployment authorization, or execution authority.

### 15.4.6 Cyber Gate.

The **Cyber Gate** shall assess cybersecurity status, including secure defaults, access control, dependency scanning, secret scanning, SBOM records, vulnerability disclosure, threat modeling, network exposure, API security, repository security, infrastructure security, secure-room needs, incident response, and public-safe technical disclosure.

Passing the Cyber Gate shall not mean vulnerability-free, security-certified, production-approved, procurement-ready, public-authority-approved, deployment-authorized, or operationally safe for all uses.

### 15.4.7 Privacy Gate.

The **Privacy Gate** shall assess privacy, data protection, purpose limitation, consent or permission basis, data minimization, sensitive data handling, learner or user privacy, youth data controls, health data controls, community data controls, cross-border controls, AI-use restrictions, retention, deletion, sealing, and incident response. It shall apply to data objects, learning objects, Campaign objects, Marketplace analytics, Registry records, Studio workflows, model objects, and handoff packages where applicable.

Passing the Privacy Gate shall not create legal compliance determination, unrestricted data use permission, consent, public authority approval, or transfer authorization by default.

### 15.4.8 Public-Safe Gate.

The **Public-Safe Gate** shall determine whether an object or public-facing summary can be released, listed, cited, displayed, taught, demonstrated, or published without unsafe disclosure, overclaim, protected knowledge exposure, sensitive geospatial exposure, cyber exposure, privacy exposure, public authority overclaim, finance overclaim, procurement overclaim, certification overclaim, consent overclaim, deployment overclaim, or execution overclaim.

Passing the Public-Safe Gate shall not mean that the underlying object is open, unrestricted, complete, raw, certified, approved, deployable, financeable, or executable.

### 15.4.9 Safeguard Gate.

The **Safeguard Gate** shall assess community safeguards, Indigenous protocols where applicable, protected knowledge controls, youth safeguards, disability inclusion, accessibility, humanitarian sensitivity, public-interest participation, non-extractive engagement, community-facing correction, and affected-party considerations. It shall apply where objects involve communities, protected knowledge, place-based data, public health, ecological sensitivity, field contexts, Campaigns, Observatory outputs, National Portfolios, or handoff context.

Passing the Safeguard Gate shall not create community consent, Indigenous consent, social license, public authority approval, implementation permission, or deployment authorization.

### 15.4.10 Marketplace Gate.

The **Marketplace Gate** shall determine whether an object may be listed, discoverable, featured, categorized, routed, or displayed through Nexus Marketplace. It shall review metadata, title, description, object class, version, steward, license, access class, support class, review status, Registry status, correction pathway, public-safe language, provider-neutrality, sponsor-boundary, procurement-neutrality, finance-boundary, and boundary notices.

Passing the Marketplace Gate shall not create procurement status, endorsement, validation, financeability, insurability, public authority approval, deployment authorization, or execution authority.

### 15.4.11 Registry Gate.

The **Registry Gate** shall determine whether an object has sufficient identity, metadata, provenance, versioning, status, review records, data-use records, AI-use records, license records, support records, correction pathways, withdrawal pathways, recall pathways, archive rules, and boundary notices to be recorded in Nexus Registry. It shall ensure status truth and lifecycle memory.

Passing the Registry Gate shall not create certification, approval, public authority status, procurement status, financeability, insurability, provider validation, or execution authority.

### 15.4.12 Handoff Gate.

The **Handoff Gate** shall determine whether an object may be included in a lawful handoff context package. It shall review evidence context, data context, method context, Studio context, Grid context, TRL context, public-safe status, safeguard status, public authority dependencies, legal dependencies, finance and insurance questions, procurement boundaries, provider-neutrality notes, sponsor-boundary notes, recipient responsibilities, correction pathways, recall pathways, and archive rules.

Passing the Handoff Gate shall not authorize implementation, deployment, procurement, finance, insurance, public authority action, provider selection, community consent, Indigenous consent, operational command, or execution. Handoff transfers dependencies and context only.

## 15.5 Release Classes

### 15.5.1 Draft.

**Draft** release class shall apply to objects that are incomplete, preliminary, unreviewed, unstable, under development, or not ready for broader release. Draft objects may be used for internal creation, limited review, early feedback, or Docket development. Draft objects shall include clear draft labels and boundary notices.

Draft release shall not permit public reliance, public-safe publication, Marketplace promotion, handoff use, procurement use, finance use, public authority use, or deployment use by default.

### 15.5.2 Internal review.

**Internal Review** release class shall apply to objects circulated to approved internal reviewers, stewards, maintainers, reviewers, working groups, Competence Cells, or institutional review teams for assessment. Internal review may include technical, data, AI, cyber, privacy, public-safe, safeguard, accessibility, license, Registry, Marketplace, Studio, Grid, TRL, or handoff review.

Internal review release shall not imply approval, public release, certification, procurement readiness, financeability, or deployment authorization.

### 15.5.3 Sandbox.

**Sandbox** release class shall apply to objects tested in limited, controlled, non-operational environments for experimentation, learning, prototyping, integration testing, or technical exploration. Sandbox objects may use synthetic data, public-safe data, restricted test data, mock services, simulated APIs, limited models, or controlled Studio workflows.

Sandbox release shall not authorize production deployment, operational use, public authority decisions, procurement, finance, insurance, or execution.

### 15.5.4 Studio-only.

**Studio-Only** release class shall apply to objects available only through Nexus Studio or a Studio-equivalent controlled workflow environment. Studio-only objects may be dashboards, digital twins, simulations, AI workflows, data workflows, public authority learning workflows, readiness workflows, public-safe output workflows, or handoff demonstrations.

Studio-only release shall not authorize download, public publication, deployment, operational command, public authority action, finance, procurement, insurance, or execution.

### 15.5.5 Secure-room-only.

**Secure-Room-Only** release class shall apply to objects requiring heightened access control, logging, audit, no-download rules, output review, confidentiality, incident response, and archive controls. It may apply to cyber-sensitive materials, infrastructure-sensitive materials, protected knowledge, restricted models, security-sensitive code, public authority-sensitive records, legal-sensitive materials, or handoff-recipient-only packages.

Secure-room-only release shall not create approval, certification, data rights, public authority status, handoff permission, deployment authorization, procurement status, financeability, insurability, or execution authority.

### 15.5.6 Data-room-only.

**Data-Room-Only** release class shall apply to data objects, metadata objects, data papers, data workflows, benchmark datasets, DRI datasets, Observatory datasets, National Portfolio datasets, and handoff data context that may be viewed, queried, or reviewed only through approved data-room conditions. Data-room-only objects may be no-download, compute-to-data-enabled, or output-review-controlled.

Data-room-only release shall not create data rights, reuse permission, AI training permission, cross-border transfer permission, protected knowledge permission, public authority approval, handoff permission, or deployment authority.

### 15.5.7 Controlled public.

**Controlled Public** release class shall apply to objects that may be shared beyond internal rooms but only with access, use, license, sensitivity, or public-safe restrictions. Controlled public release may apply to public-safe summaries, controlled reports, restricted documentation, limited dashboards, learning objects with safeguards, API documentation, metadata-only records, or controlled repository packages.

Controlled public release shall not mean unrestricted public release. It shall preserve access limits, use limits, license terms, data-use labels, AI-use labels, sensitivity controls, and boundary notices.

### 15.5.8 Open public.

**Open Public** release class shall apply to objects approved for open public access within recorded license, public-safe, support, and boundary conditions. Open public objects may include reports, software, OER, public-safe data, metadata, dashboards, guides, schemas, API documentation, public-safe summaries, or repository packages.

Open public release shall not create unrestricted use, warranty, certification, public authority approval, procurement status, financeability, insurability, deployment authorization, or execution authority. Open means accessible within terms; it does not mean authority or unrestricted reuse.

### 15.5.9 Marketplace candidate.

**Marketplace Candidate** release class shall apply to objects prepared for Marketplace listing but not yet fully listed or not yet cleared for all Marketplace display conditions. Candidate status may require metadata review, public-safe review, license review, support class review, provider-neutrality review, sponsor-boundary review, procurement-neutrality review, finance-boundary review, Registry linkage, and correction pathway completion.

Marketplace candidate status shall not create discovery endorsement, listing approval, procurement relevance, financeability, validation, or handoff authority.

### 15.5.10 Registry-recorded.

**Registry-Recorded** release class shall apply to objects that have been entered into Nexus Registry with identity, status, version, provenance, support class, review status, access class, correction pathway, archive rule, and boundary notices. Registry-recorded objects may or may not be public, supported, Marketplace-listed, published, or handoff-relevant.

Registry-recorded status shall not be certification, approval, procurement status, financeability, insurability, public authority status, deployment authorization, or execution authority.

### 15.5.11 Handoff-recipient-only.

**Handoff-Recipient-Only** release class shall apply to objects, notes, data contexts, method contexts, Studio contexts, Grid contexts, TRL contexts, dependency packages, or correction records made available only to identified lawful handoff recipients under recorded conditions. Recipients may include National Consortium Companies, Project SPVs, public authorities, providers, operators, contractors, universities, labs, donors, insurers, capital readers, communities where appropriate, or other competent lawful actors.

Handoff-recipient-only release shall not create implementation authority, procurement approval, finance approval, insurance approval, public authority approval, provider selection, community consent, Indigenous consent, deployment authorization, operational command, or execution authority.

### 15.5.12 Archived.

**Archived** release class shall apply to objects preserved for historical memory, citation, audit, correction traceability, research history, institutional memory, or non-current reference. Archived objects may be open, controlled, secure, metadata-only, or sealed depending on access class and sensitivity.

Archived release shall not authorize current use, current support, current publication, current Marketplace promotion, current handoff, current deployment, or current execution.

### 15.5.13 Non-continuing.

**Non-Continuing** release class shall apply to objects, projects, builds, datasets, models, learning objects, reports, Campaigns, Studio workflows, Marketplace listings, Registry records, or handoff contexts that shall not continue into the next cycle. Non-continuation may reflect lack of evidence, lack of support, changed priorities, safety concerns, public-safe concerns, licensing constraints, insufficient demand, correction burden, or strategic retirement.

Non-continuing release shall include reason where appropriate, archive instructions, successor alternatives where applicable, correction implications, and no-current-use notice.

## 15.6 Grid and TRL Boundary Rules

### 15.6.1 Grid input is not certification.

A Nexus Grid input, readiness record, evidence sufficiency note, review gate result, support status, quality class, release class, TRL note, or downgrade record shall not constitute certification, conformity assessment, maturity certification, AI safety certification, cybersecurity certification, public authority approval, procurement certification, finance certification, insurance approval, or deployment approval. Grid inputs are bounded evidence records only.

### 15.6.2 TRL is not procurement readiness.

A TRL classification shall not mean that an object is approved for procurement, qualified as a supplier offering, preferred for purchase, compliant with a tender, validated as a vendor solution, or suitable for procurement reliance. Procurement readiness requires separate competent procurement processes, independent diligence, legal authority, conflict controls, and provider-neutrality discipline.

### 15.6.3 TRL is not financeability.

A TRL classification shall not mean that an object, system, project, pathway, National Portfolio object, Foundry build, Studio workflow, digital public-good package, or handoff context is financeable, bankable, investable, creditworthy, grant-approved, guaranteed, public-finance-eligible, transaction-ready, or suitable for financial reliance. Finance-readiness questions may be recorded, but finance decisions occur separately.

### 15.6.4 TRL is not insurability.

A TRL classification shall not mean that an object is insurable, underwritten, priced, covered, risk-transferred, approved by an insurer, validated for claims purposes, or suitable for insurance reliance. Insurance-readiness questions, protection-gap notes, risk-layering notes, and DRI context may be recorded only as bounded, no-reliance context.

### 15.6.5 TRL is not public authority approval.

A TRL classification shall not create public authority approval, regulatory approval, compliance determination, permit, license, public warning, emergency command, public finance allocation, procurement decision, governmental endorsement, or official adoption. Public authority decisions remain outside DDPGF readiness records and must be made separately by competent public authorities.

### 15.6.6 TRL is not deployment authorization.

A TRL classification shall not authorize deployment, production use, operational command, infrastructure operation, real-world implementation, public authority action, enterprise execution, provider selection, community implementation, Indigenous-context implementation, or field operation. Deployment authorization requires separate lawful authority, competent actors, recipient responsibility, safeguards, operational controls, and recorded handoff outside default DDPGF Grid and TRL status.


---

# 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/xv.-readiness.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.