# XXVIII. TEMPLATES

Templates define the standard records and notices Nexus uses to make objects reviewable, reusable within limits, public-safe, and correctionable.

They set consistent structure for Registry, Marketplace, Reports, learning, handoff, and archive use without implying certification, approval, financeability, public authority action, or execution.

## 28.1 Core Object Templates

### 28.1.1 Digital Object Intake Template

Digital object intake template is the standard intake structure for any Nexus digital public-good object before it enters Registry review, Marketplace discovery, Studio use, Grid and TRL context, Reports, Academy pathways, Campaigns, National Portfolios, Nexus Universe, DRI, Observatory, infrastructure workflows, public authority learning, finance-readiness, safeguard review, or handoff.

A Digital Object Intake Template shall include:

1. Object identity, including object title, object identifier, object class, steward, contributor, source, version, date, jurisdictional context where relevant, language, repository or storage location, and intended Nexus pathway.
2. Object purpose, including public-good purpose, intended use, prohibited use, audience, relationship to Nexus Ecosystem, relationship to National Portfolio or Nexus Universe where applicable, and expected lifecycle.
3. Rights and use status, including license, contribution terms, attribution requirements, data-use label where applicable, AI-use label where applicable, reuse restrictions, provider restrictions, sponsor restrictions, protected knowledge restrictions, and handoff restrictions.
4. Sensitivity and access status, including public, controlled-public, restricted, secure-room-only, data-room-only, protected knowledge room-only, public authority learning-only, finance-readiness-only, handoff-recipient-only, archive-only, sealed, deletion-required, or non-continuing.
5. Review requirements, including evidence review, data review, AI review, cyber review, privacy review, public-safe review, accessibility review, safeguard review, public authority boundary review, finance boundary review, procurement boundary review, provider-neutrality review, sponsor-boundary review, handoff review, correction review, and archive review.
6. Operational status, including support class, maintainer role, known issues, dependency status, reliability status, correction channel, incident channel, archive rule, and non-current notice where applicable.
7. Boundary notices, confirming that intake does not create approval, certification, procurement status, financeability, insurability, public authority action, consent, deployment authorization, operational command, or execution.

### 28.1.2 Software Object Template

Software object template is the standard structure for Nexus software objects, including code repositories, tools, scripts, APIs, dashboards, notebooks, data pipelines, AI workflows, Studio workflows, Registry tools, Marketplace tools, Grid tools, Academy labs, Campaign tools, DRI tools, Observatory tools, and handoff-context tools.

A Software Object Template shall include object identity, repository location, steward, maintainer, license, contribution terms, version, release class, documentation, README, installation notes, dependency records, SBOM status where applicable, security review status, secret-scanning status, dependency-scanning status, public-safe documentation status, accessibility notes, support class, known issues, changelog, deprecation rule, correction pathway, archive rule, and handoff restrictions.

It shall also include standard notices that software release, repository availability, successful execution, installation instructions, or Marketplace listing does not create security certification, procurement approval, provider validation, public authority approval, financeability, insurability, deployment authorization, operational command, or execution.

### 28.1.3 Data Object Template

Data object template is the standard structure for Nexus data objects, including raw data, processed data, metadata, derived data, indicators, DRI data, Observatory data, Studio data, Campaign data, Academy data, Registry data, Marketplace data, Grid data, National Portfolio data, public authority learning data, finance-readiness data, safeguard data, and handoff-context data.

A Data Object Template shall include source, provenance, steward, data class, sensitivity class, data-use label, AI-use label, license or rights basis, jurisdictional context, data residency status, localization status, cross-border controls, access class, privacy controls, protected knowledge controls, public authority-sensitive controls, community-sensitive controls, Indigenous protocol controls where applicable, health-sensitive controls, cyber-sensitive controls, infrastructure-sensitive controls, geospatial controls, retention rule, deletion rule, correction pathway, archive rule, and public-safe release status.

It shall confirm that data availability is not open release, AI-use permission, ownership transfer, consent, public authority approval, handoff authorization, deployment authorization, or execution.

### 28.1.4 Dataset Card Template

Dataset card template is the structured public-safe or controlled record explaining a dataset’s origin, purpose, contents, limitations, sensitivity, permitted uses, prohibited uses, review status, correction status, and archive status.

A Dataset Card Template shall include dataset title, identifier, steward, source, collection method where safe, time period, geography at a safe level, variables or fields where safe, data quality, missingness, uncertainty, confidence, update cadence, data-use label, AI-use label, license, access class, sensitivity class, public-safe transformation, protected knowledge restrictions, geospatial masking, privacy controls, known limitations, intended uses, prohibited uses, correction channel, citation guidance where appropriate, and archive rule.

It shall include notices that the dataset card is not official statistics by default, not public authority approval, not open data release unless expressly labelled, not AI-training permission unless expressly labelled, not consent, not procurement approval, and not execution authority.

### 28.1.5 Model Card Template

Model card template is the structured record for AI models, statistical models, DRI models, Observatory models, Studio models, simulation models, public-safe transformation models, digital twin models, and other model objects used in Nexus.

A Model Card Template shall include model identity, steward, version, model family, intended use, prohibited use, input data context, output class, training or fitting context where safe, evaluation status, performance limits, confidence limits, uncertainty limits, bias and harm considerations, public-safe limits, AI-use label, data-use dependencies, human oversight pattern, red-team status where applicable, incident pathway, correction pathway, withdrawal and recall pathway, archive rule, and non-current notice where applicable.

It shall state that model documentation is not AI safety certification, not general validation, not public authority approval, not public warning authority, not procurement approval, not financeability, not insurability, not deployment authorization, and not execution.

### 28.1.6 System Card Template

System card template is the structured record for systems composed of models, data, APIs, workflows, interfaces, dashboards, agents, compute environments, human oversight, access controls, and operational dependencies.

A System Card Template shall include system identity, steward, purpose, user classes, components, model dependencies, data dependencies, API dependencies, infrastructure dependencies, access model, AI-use labels, data-use labels, human oversight, failure modes, public-safe controls, security controls, privacy controls, safeguard controls, public authority boundary controls, finance boundary controls, procurement boundary controls, known limitations, incident pathway, correction pathway, recall pathway, archive rule, and handoff restrictions.

It shall confirm that system cards describe bounded Nexus use only and do not create certification, public authority approval, procurement approval, financeability, insurability, deployment authorization, operational command, or execution.

### 28.1.7 Agent Workflow Card Template

Agent workflow card template is the structured record for any agentic or semi-agentic AI workflow used in Nexus, including tool-using workflows, retrieval workflows, drafting workflows, analysis workflows, public-safe transformation workflows, Studio workflows, DRI workflows, Observatory workflows, Registry workflows, Marketplace workflows, Grid workflows, Academy workflows, and handoff-preparation workflows.

An Agent Workflow Card Template shall include workflow identity, steward, purpose, allowed tools, prohibited tools, input classes, output classes, data-use labels, AI-use labels, access class, human-in-the-loop requirements, human-on-the-loop monitoring, tool-permission controls, write-back restrictions, no-command restrictions, prompt-injection controls, logging, output review, public-safe review, incident pathway, correction pathway, recall pathway, archive rule, and handoff restrictions.

It shall state that agent outputs are not public authority decisions, public warnings, procurement decisions, finance or insurance determinations, donor commitments, public finance allocations, consent determinations, deployment authorizations, operational commands, or execution instructions.

### 28.1.8 API Card Template

API card template is the structured record for Nexus APIs, connectors, endpoints, integrations, schemas, authentication flows, authorization scopes, rate limits, data flows, write-back permissions, logging, monitoring, security controls, and lifecycle status.

An API Card Template shall include API identity, steward, endpoint description, version, authentication model, authorization scopes, data classes, input classes, output classes, data-use labels, AI-use labels, access restrictions, rate limits, dependency objects, security review status, logging status, monitoring status, known issues, maintenance window, deprecation notice, correction pathway, archive rule, and handoff restrictions.

It shall confirm that API access is not data right, API availability is not service warranty, API integration is not public authority approval, and API use is not deployment authorization or execution.

### 28.1.9 Schema Template

Schema template is the structured record for schemas, ontologies, controlled vocabularies, metadata standards, API schemas, dataset schemas, Registry schemas, Marketplace schemas, Grid schemas, DRI schemas, Observatory schemas, Academy schemas, Campaign schemas, Studio schemas, and handoff package schemas.

A Schema Template shall include schema identity, steward, purpose, version, field definitions, required fields, optional fields, controlled terms, validation rules, localization status, interoperability notes, public authority terminology notes, finance boundary terms where applicable, safeguard terms, deprecated fields, successor links, correction history, archive rule, and non-current notice.

It shall state that schema use improves structure and interoperability but does not create legal classification, certification, standards conformance, public authority approval, procurement approval, or execution authority.

### 28.1.10 Dashboard Card Template

Dashboard card template is the structured record for dashboards, visualizations, status pages, monitoring displays, DRI dashboards, Observatory dashboards, Campaign dashboards, Academy dashboards, Studio dashboards, Registry dashboards, Marketplace dashboards, Grid dashboards, finance-readiness dashboards, public authority learning dashboards, and National Portfolio dashboards.

A Dashboard Card Template shall include dashboard identity, steward, purpose, audience, data sources, indicators, refresh cadence, confidence labels, uncertainty labels, public-safe status, accessibility status, localization status, geospatial controls, public authority boundary notices, finance boundary notices, procurement boundary notices, support class, known limitations, degraded-mode labels, correction pathway, archive rule, and non-current notice.

It shall confirm that a dashboard is not a decision, not an official warning, not official statistics by default, not procurement guidance, not finance or insurance advice, not consent, not deployment authorization, and not execution.

### 28.1.11 Digital Twin Card Template

Digital twin card template is the structured record for any digital twin, simulation environment, system model, scenario environment, or virtual representation used in Nexus.

A Digital Twin Card Template shall include twin identity, steward, system represented, purpose, scope, geography at safe level, time horizon, included variables, excluded variables, data sources, model dependencies, assumptions, calibration status, validation limits, update cadence, uncertainty labels, confidence labels, public-safe status, protected location controls, safeguard controls, public authority boundary controls, finance boundary controls, support class, correction pathway, archive rule, and handoff restrictions.

It shall state that a digital twin is a learning and simulation object, not the system itself, not forecast certainty, not public warning, not public authority decision, not procurement approval, not deployment authorization, and not execution.

### 28.1.12 Studio Workflow Template

Studio workflow template is the structured record for workflows used in Nexus Studio, including simulations, dashboards, digital twins, AI workflows, compute-to-data workflows, secure-room workflows, data-room workflows, public authority learning workflows, finance-readiness workflows, donor-readiness workflows, public finance learning workflows, National Portfolio workflows, Nexus Universe demonstrations, Academy exercises, Foundry builds, and handoff-awareness workflows.

A Studio Workflow Template shall include workflow identity, steward, purpose, inputs, outputs, runtime environment, assumptions, limitations, data-use labels, AI-use labels, access class, human oversight, no-write-back rule where required, no-command rule, public-safe transformation, safeguard status, public authority boundary status, finance boundary status, logging, monitoring, incident pathway, correction pathway, recall pathway, archive rule, and handoff restrictions.

It shall confirm that Studio workflows support learning and demonstration only and do not create public authority decisions, public warnings, operational commands, procurement decisions, finance or insurance decisions, consent, deployment authorization, or execution.

## 28.2 Registry and Marketplace Templates

### 28.2.1 Registry Record Template

Registry record template is the standard status-truth record for any Nexus object requiring provenance, status, correction, release, support, review, archive, or handoff traceability.

A Registry Record Template shall include object identifier, object title, object class, steward, source, provenance, version, support class, access class, sensitivity class, public-safe status, review status, Registry status, Marketplace linkage, Grid linkage, TRL context where applicable, proof receipt where applicable, correction history, withdrawal status, recall status, supersession link, archive status, non-current notice, and boundary notices.

It shall state that Registry status is status truth only and not certification, approval, procurement status, financeability, insurability, public authority action, consent, deployment authorization, or execution.

### 28.2.2 Marketplace Listing Template

Marketplace listing template is the standard discovery record for objects made findable through Nexus Marketplace.

A Marketplace Listing Template shall include listing title, object class, description, steward, Registry link, Grid link where applicable, support class, access class, public-safe status, localization status, accessibility status, provider-neutrality note, sponsor-boundary note where applicable, permitted use, prohibited use, dependency notes, correction channel, delisting pathway, archive rule, and standard notices.

It shall confirm that Marketplace listing is discovery only and not endorsement, procurement recommendation, provider validation, financeability, insurability, donor commitment, public finance allocation, public authority approval, consent, deployment authorization, or execution.

### 28.2.3 Support Status Template

Support status template is the standard record for describing support expectations and limitations for Nexus objects.

A Support Status Template shall include object identity, support class, support steward, support scope, support exclusions, support period, support expiry, issue channel, maintenance window where applicable, known issues, dependency status, continuity status, end-of-support notice where applicable, deprecation notice where applicable, archive rule, and no-warranty notice.

It shall state that support status is descriptive and does not create service warranty, uptime guarantee, maintenance guarantee, procurement approval, public authority approval, financeability, insurability, deployment authorization, or execution.

### 28.2.4 Provider Contribution Template

Provider contribution template is the standard record for provider, vendor, platform, cloud, telecom, AI, software, hardware, data, cybersecurity, identity, systems-integration, university-lab, or technical contributions to Nexus.

A Provider Contribution Template shall include provider class, contribution type, supported object, duration, dependency status, access status, conflict status, provider-neutrality review, portability note, support limits, logo or name-use limits, Marketplace wording controls, Registry wording controls, no-validation notice, no-procurement notice, correction pathway, withdrawal pathway, and archive rule.

It shall confirm that provider contribution does not create provider validation, endorsement, preferred-provider status, procurement approval, financeability, insurability, public authority approval, deployment authorization, or execution.

### 28.2.5 Sponsor Support Template

Sponsor support template is the standard record for lawful sponsor support, including funding support where lawful, in-kind support, cloud credits, equipment support, venue support, communications support, Academy support, Campaign support, Nexus Universe support, Foundry support, accessibility support, translation support, and infrastructure support.

A Sponsor Support Template shall include sponsor identity, support type, support purpose, support duration, conditions, display rules, logo and quote limits, conflict status, no-control notice, no-pay-to-influence notice, no-routing-priority notice, no-procurement notice, finance boundary notice, public authority boundary notice, correction pathway, withdrawal pathway, and archive rule.

It shall confirm that sponsor support is support without control and does not create endorsement, governance authority, review influence, procurement preference, financeability, public authority approval, deployment authorization, or execution.

### 28.2.6 Public Authority Participation Template

public authority participation template is the standard record for public authority participation in Nexus learning, review, rooms, workshops, Nexus Universe activities, National Portfolio formation, Studio demonstrations, DRI interpretation, Observatory summaries, Reports review, public finance learning, procurement literacy, or handoff dependency awareness.

A Public Authority Participation Template shall include public authority class, participation context, materials reviewed, questions raised, learning status, non-decision room status, no-public-authority-action notice, no-policy-adoption notice, no-regulatory-decision notice, no-procurement notice, no-public-finance-allocation notice, no-warning notice, no-command notice, correction pathway, archive rule, and public-safe status.

It shall state that participation is learning-only unless a separate competent public authority lawfully acts outside Nexus.

### 28.2.7 Correction Record Template

Correction record template is the standard structure for recording patch, erratum, addendum, revision, supersession, downgrade, suspension, withdrawal, retraction where necessary, recall, public repair, archive, sealing, deletion where required, and non-continuation.

A Correction Record Template shall include affected object, correction class, trigger, severity, prior status, corrected status, action taken, steward, reviewer, public-safe notice, Registry update, Marketplace update, Grid update, Report update, Campaign update, Academy update, Studio update, DRI update, Observatory update, handoff update, recipient notice where applicable, archive update, recurrence-prevention action, and boundary notices.

### 28.2.8 Archive Record Template

archive record template is the standard structure for preserving archived, withdrawn, recalled, superseded, deprecated, sealed, deleted-record, archive-only, and non-current Nexus objects.

An Archive Record Template shall include archived object, archive class, access class, steward, source, provenance, version, date, reason for archive, historical use note, archive-not-current notice, successor link where applicable, correction history, license status, data-use status, AI-use status, public-safe status, sensitivity class, retention rule, deletion rule, sealing status, restore test where applicable, and boundary notices.

It shall confirm that archive preserves memory and does not create current authority, approval, procurement status, financeability, insurability, deployment authorization, or execution.

## 28.3 Reports and Publication Templates

### 28.3.1 Report Package Template

Report package template is the standard structure for Nexus Reports, technical reports, public-safe reports, National Portfolio reports, DRI reports, Observatory reports, Campaign reports, Academy reports, Grid reports, Nexus Universe reports, finance-readiness summaries, public authority learning reports, and handoff-awareness reports.

A Report Package Template shall include title, identifier, steward, authors, contributors, version, date, purpose, audience, source records, evidence context, data context, method context, limitations, confidence and uncertainty notes, public-safe status, accessibility status, localization status, license and attribution, data availability statement, AI-use statement, public authority boundary notice, finance boundary notice, procurement boundary notice, safeguard notice, correction channel, citation guidance, archive rule, and non-current notice where applicable.

It shall confirm that a Report is not official policy, public warning, procurement document, finance document, insurance document, donor commitment, public finance allocation, consent, deployment authorization, or execution.

### 28.3.2 Technical Note Template

technical note template is the standard structure for focused technical explanations, methods notes, software notes, data notes, model notes, infrastructure notes, Studio notes, DRI notes, Observatory notes, Grid notes, and handoff technical notes.

A Technical Note Template shall include title, object class, steward, purpose, technical scope, method, assumptions, dependencies, limitations, evidence basis, review status, public-safe status, security sensitivity, data-use labels, AI-use labels, correction pathway, archive rule, and boundary notices.

It shall state that technical notes are explanatory and not certification, compliance approval, public authority approval, procurement approval, financeability, deployment authorization, or execution.

### 28.3.3 Public-Safe Summary Template

public-safe summary template is the standard structure for summaries intended to communicate Nexus work safely to public, controlled-public, community, public authority learning, finance-readiness, donor, public finance, media-safe, Marketplace, Registry, Grid, or handoff-awareness audiences.

A Public-Safe Summary Template shall include title, source object, audience, release class, summary text, excluded sensitive material, redactions, aggregation, geospatial masking, protected knowledge exclusions, limitation language, uncertainty language, no-warning notice, no-command notice, no-public-authority-action notice, no-procurement notice, no-finance notice, no-consent notice, correction channel, recall status, and archive rule.

It shall confirm that public-safe summary is not full disclosure, official warning, public authority decision, procurement approval, financeability, insurability, consent, deployment authorization, or execution.

### 28.3.4 Data Availability Statement Template

data availability statement template is the standard statement describing whether data underlying a Nexus output is open, controlled, restricted, unavailable, metadata-only, secure-room-only, data-room-only, protected knowledge room-only, public authority learning-only, handoff-recipient-only, archived, sealed, or deletion-required.

A Data Availability Statement Template shall include data object, access class, data-use label, AI-use label, license or rights basis, sensitivity class, data residency status, public-safe transformation, access request pathway where applicable, prohibited use, correction pathway, archive rule, and no-open-data-by-implication notice.

It shall confirm that data availability does not create open data release, AI-use permission, consent, public authority approval, handoff authorization, deployment authorization, or execution.

### 28.3.5 AI-Use Statement Template

AI-use statement template is the standard statement disclosing AI use, AI-use labels, AI role, human oversight, model or system references where safe, prohibited uses, review status, limitations, public-safe controls, and correction pathway.

An AI-Use Statement Template shall include whether AI was used, where AI was used, the class of AI workflow, human review, AI-use label, no-training restrictions, no-agentic-use restrictions where applicable, output review, hallucination and limitation controls, public-safe review, incident pathway, correction pathway, and archive rule.

It shall state that AI assistance does not create public authority decision, public warning, procurement decision, finance or insurance determination, consent, deployment authorization, or execution.

### 28.3.6 License and Attribution Template

license and attribution template is the standard structure for recording license terms, attribution, contribution rights, third-party materials, data-use restrictions, AI-use restrictions, public authority source limitations, provider restrictions, sponsor restrictions, protected knowledge restrictions, and reuse conditions.

A License and Attribution Template shall include object title, source, authors or contributors where appropriate, license class, attribution requirement, derivative use permissions, prohibited uses, third-party notices, data-use label, AI-use label, protected knowledge restrictions, public-safe restrictions, correction pathway, archive rule, and no-ownership-transfer notice where appropriate.

### 28.3.7 Repository README Template

repository README template is the standard front-page record for a Nexus repository.

A Repository README Template shall include project title, purpose, Nexus pathway, object class, steward, maintainer, status, support class, installation or use notes where safe, data-use labels, AI-use labels, license, contribution rules, security policy, public-safe status, accessibility notes, known limitations, no-warranty notice, no-certification notice, no-procurement notice, no-deployment notice, no-execution notice, correction channel, changelog link, archive status, and citation guidance where applicable.

### 28.3.8 Changelog Template

changelog template is the standard record of changes to Nexus objects, including software, data, models, dashboards, APIs, Reports, Studio workflows, Registry records, Marketplace listings, Grid records, Academy objects, Campaign objects, National Portfolio objects, and handoff packages.

A Changelog Template shall include version, date, change class, description, affected object, steward, compatibility note, security note where applicable, data-use change where applicable, AI-use change where applicable, public-safe change, safeguard change, correction link, deprecation link, archive link, and non-current notice.

### 28.3.9 DOI and Citation Template

DOI and citation template is the standard structure for citable Nexus objects where persistent identification is appropriate.

A DOI and Citation Template shall include title, authors or stewards, year, version, repository or publisher, DOI or persistent identifier where applicable, license, access class, public-safe status, correction status, archive status, successor link, citation format, citation limitation, and non-current notice where applicable.

It shall state that citation does not imply approval, endorsement, public authority adoption, procurement status, financeability, deployment authorization, or execution.

### 28.3.10 Correction Notice Template

correction notice template is the standard public-safe or controlled notice for correcting, superseding, downgrading, suspending, withdrawing, retracting, recalling, archiving, or marking non-current a Nexus object.

A Correction Notice Template shall include affected object, prior status, correction class, issue identified, correction made, affected versions, affected audiences, action required, successor object where applicable, Registry update, Marketplace update, Grid update, handoff notice where applicable, archive status, date, steward, and boundary notices.

## 28.4 Learning and Competence Templates

### 28.4.1 Learning Object Template

learning object template is the standard structure for Nexus Academy, Risk Academy, SCF, Foundry, Campaign, Studio, DRI, Observatory, public authority learning, and handoff literacy objects.

A Learning Object Template shall include title, identifier, steward, learning purpose, competency linkage, learner audience, prerequisites, duration, evidence of learning, accessibility status, localization status, public-safe status, AI-use statement, license, assessment method where applicable, credential boundary notice, correction pathway, archive rule, and no-employment, no-licensure, no-procurement-qualification, no-execution notices.

### 28.4.2 Course Template

course template is the standard structure for a sequence of Nexus learning objects.

A Course Template shall include course title, steward, pathway, target learners, competency map, modules, labs, Studio exercises, WILP linkages, micro-credential linkages where applicable, accessibility features, localization plan, learner safeguards, assessment approach, evidence requirements, support class, correction channel, archive rule, and credential boundary notices.

It shall confirm that course completion is not professional licensure, employment guarantee, immigration status, public authority status, procurement qualification, deployment authorization, or execution authority.

### 28.4.3 Module Template

module template is the standard structure for a unit within a Nexus course, Academy pathway, Risk Academy pathway, Foundry pathway, Campaign pathway, Studio exercise, or public authority learning pathway.

A Module Template shall include module title, learning objectives, competencies, prerequisites, content outline, activities, evidence of participation, accessibility features, language status, public-safe status, AI-use statement, assessment method where applicable, correction pathway, archive rule, and boundary notices.

### 28.4.4 Lab Template

lab template is the standard structure for practice-based learning in Academy, Risk Academy, Foundry, Studio, DRI, Observatory, data, AI, cyber, software, geospatial, WFEH-B, DRR, DRF, DRI, and public authority learning contexts.

A Lab Template shall include lab title, steward, learning objectives, environment, data or software objects used, safety requirements, access controls, AI-use labels, data-use labels, expected outputs, review process, public-safe controls, safeguard controls, correction pathway, archive rule, and no-deployment, no-operational-command, no-execution notices.

### 28.4.5 Studio Exercise Template

Studio exercise template is the standard structure for scenario-based, dashboard-based, simulation-based, digital twin-based, AI-assisted, public authority learning, finance-readiness, public finance learning, or handoff-awareness practice.

A Studio Exercise Template shall include exercise title, scenario, learning objectives, Studio workflow, input objects, assumptions, limitations, expected outputs, human oversight, no-command rule, no-warning rule, no-decision rule, public-safe status, correction pathway, archive rule, and boundary notices.

### 28.4.6 WILP Template

WILP template is the standard structure for Work-Integrated Learning Paths, including apprenticeships, internships, cooperative education, practicums, Studio practice, Foundry contribution, Campaign work, public authority learning placements, and field-based learning.

A WILP Template shall include pathway title, host context, learner class, competencies, work activities, supervision or mentorship, evidence requirements, labor-boundary controls, safeguarding requirements, accessibility requirements, stipend or bounty status where applicable, no-disguised-labor notice, no-employment-by-implication notice, correction pathway, archive rule, and credential boundary notices.

### 28.4.7 Micro-Credential Template

micro-credential template is the standard structure for Nexus micro-credentials linked to SCF competencies, Academy pathways, Risk Academy pathways, WILPs, Foundry contributions, Campaign contributions, reviewer roles, maintainer roles, and contribution evidence.

A Micro-Credential Template shall include credential title, steward or issuer, competency linkage, evidence requirements, assessment method, verification status, expiry or renewal period, revocation conditions, correction pathway, badge linkage where applicable, ILA linkage where applicable, iCRS linkage where applicable, archive rule, and notices that the credential is not professional licensure, employment guarantee, procurement qualification, immigration status, public authority status, or execution authority.

### 28.4.8 Badge Template

badge template is the standard structure for digital badges used to recognize learning, contribution, review, mentorship, translation, accessibility, public-safe review, safeguard review, Campaign participation, Foundry contribution, Studio participation, Academy participation, or Nexus Universe participation.

A Badge Template shall include badge title, badge class, steward, evidence basis, issue date, expiry or renewal if applicable, verification method, display controls, privacy controls, correction pathway, withdrawal or recall rule, archive rule, and credential boundary notices.

### 28.4.9 ILA Record Template

ILA record template is the standard structure for Integrated Learning Account records linked to learner identity, competencies, learning objects, micro-credentials, badges, WILPs, contribution records, iCRS records, Academy participation, Risk Academy participation, Foundry participation, Campaign participation, and National Capability inputs.

An ILA Record Template shall include learner-controlled identity or record class, competency evidence, learning history, credential links, contribution links, privacy controls, display permissions, correction pathway, withdrawal pathway, archive rule, and notices that ILA records are not professional licenses, employment guarantees, immigration status, wage promises, procurement qualifications, social scores, or execution authority.

### 28.4.10 iCRS Contribution Record Template

iCRS contribution record template is the standard structure for recognizing public-good contributions across Nexus.

An iCRS Contribution Record Template shall include contributor role, contribution object, contribution class, evidence basis, reviewer or maintainer validation within Nexus scope, attribution status, privacy status, rights status, contribution terms, public-safe status, credential linkage where applicable, ILA linkage where applicable, correction pathway, archive rule, and notices that contribution recognition is not employment, wage promise, ownership transfer, professional license, procurement qualification, finance signal, or execution authority.

## 28.5 Portfolio and Handoff Templates

### 28.5.1 National Context Record Template

National Context Record template is the standard structure for recording national context within Nexus without creating country ranking, official national plan status, public authority approval, or execution authority.

A National Context Record Template shall include country context, National Node context, National Portfolio linkage, WFEH-B context, DRR context, DRF context, DRI context, public authority learning context, legal and data sovereignty context, language context, accessibility context, community safeguard context, Indigenous protocol context where applicable, infrastructure context, Academy context, Campaign context, Foundry context, Nexus Universe context, correction pathway, archive rule, and no-country-ranking notice.

### 28.5.2 National Challenge Brief Template

National Challenge Brief template is the standard structure for framing a national or place-based challenge as a Nexus learning, evidence, public-good, readiness, safeguard, and handoff question.

A National Challenge Brief Template shall include challenge title, system domain, WFEH-B linkage, DRR/DRF/DRI linkage, affected context, evidence need, data need, public authority dependency, safeguard dependency, Studio need, Observatory need, Academy need, Campaign need, Foundry need, finance-readiness questions, public-safe status, correction pathway, archive rule, and boundary notices.

It shall not be treated as official national policy, public authority decision, procurement instruction, finance signal, public warning, consent, deployment authorization, or execution.

### 28.5.3 Evidence Need Record Template

Evidence Need Record template is the standard structure for identifying missing or required evidence before Nexus can responsibly review, release, route, hand off, or archive an object.

An Evidence Need Record Template shall include object, evidence question, source needed, method needed, data needed, model needed, public authority dependency, safeguard dependency, confidence need, uncertainty need, review pathway, responsible steward, status, correction pathway, archive rule, and boundary notices.

### 28.5.4 Readiness Question Record Template

Readiness Question Record template is the standard structure for capturing questions about whether an object, portfolio, project concept, campaign, build, Studio workflow, Grid input, National Portfolio item, Nexus Universe output, or handoff candidate is ready for further review.

A Readiness Question Record Template shall include readiness domain, evidence basis, unresolved dependencies, TRL context where applicable, Grid context where applicable, public-safe status, safeguard status, public authority dependencies, finance-readiness questions, procurement boundaries, provider-neutrality notes, correction pathway, archive rule, and notices that readiness questions are not approval, financeability, procurement readiness, deployment authorization, or execution.

### 28.5.5 Public Authority Dependency Record Template

Public Authority Dependency Record template is the standard structure for identifying public authority dependencies without creating public authority action.

A Public Authority Dependency Record Template shall include competent public authority class, dependency type, affected object, learning record linkage, required external process, status, limitation, no-decision notice, no-warning notice, no-command notice, no-public-finance-allocation notice, correction pathway, archive rule, and boundary notices.

### 28.5.6 Finance-Readiness Question Record Template

Finance-Readiness Question Record template is the standard structure for capital-readability questions.

A Finance-Readiness Question Record Template shall include object, question class, assumptions, dependencies, evidence gaps, data needs, support needs, cost context, public authority dependencies, safeguard dependencies, no-reliance statement, non-solicitation notice, non-transactionality notice, correction pathway, archive rule, and notices that finance-readiness is not financeability, investment advice, solicitation, transaction, or execution.

### 28.5.7 Insurance-Readiness Question Record Template

Insurance-Readiness Question Record template is the standard structure for insurance-readiness, protection-gap, and risk-layering questions.

An Insurance-Readiness Question Record Template shall include risk context, protection-gap question, risk-layering question, data dependency, DRI dependency, model dependency, public authority dependency, safeguard dependency, no-underwriting notice, no-insurance-approval notice, no-risk-score notice, correction pathway, archive rule, and boundary notices.

### 28.5.8 Handoff Dependency Record Template

Handoff Dependency Record template is the standard structure for dependencies that must be understood before downstream action outside Nexus.

A Handoff Dependency Record Template shall include handoff object, recipient class, dependency category, dependency description, dependency status, responsible recipient, required independent review, Nexus limitation, anti-bypass notice, correction pathway, recall trigger, archive rule, and no-authority-transfer notice.

### 28.5.9 Handoff Package Template

handoff package template is the standard structure for controlled public-good-to-enterprise transfer.

A Handoff Package Template shall include package identity, source object, recipient class, evidence context, data context, method context, Studio context, Grid and 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 pathway, recall pathway, archive rule, no-reliance statement, no-authority-transfer notice, no-execution notice, and recipient acknowledgment where appropriate.

### 28.5.10 Handoff Recall Template

handoff recall template is the standard structure for recalling or restricting a handoff package or part of a package.

A Handoff Recall Template shall include package identity, recipient list or recipient class, recall trigger, affected materials, required recipient action, replacement package where applicable, public-safe notice, Registry update, Marketplace update, Grid update, National Portfolio update, correction action, archive action, recurrence-prevention action, and no-continuing-reliance notice.

## 28.6 Standard Notices

### 28.6.1 Digital Public-Good Notice

Digital public-good notice shall state that the relevant object is provided as a Nexus digital public-good object or public-good record within its recorded scope, release class, support class, data-use label, AI-use label, public-safe status, correction pathway, and archive rule. It shall state that public-good status does not create certification, procurement approval, financeability, insurability, public authority approval, consent, deployment authorization, operational command, or execution.

### 28.6.2 No-Warranty Notice

No-warranty notice shall state that, unless separately and lawfully contracted or expressly recorded by a competent actor, Nexus objects, releases, software, data, models, dashboards, workflows, Reports, Registry records, Marketplace listings, Grid records, Academy materials, Campaign materials, Studio workflows, infrastructure environments, and handoff packages are provided without service-level warranty, uptime guarantee, performance guarantee, security guarantee, maintenance guarantee, continuation guarantee, renewal guarantee, or fitness-for-deployment warranty.

### 28.6.3 No-Certification Notice

No-certification notice shall state that Nexus records, reviews, Registry status, Marketplace listings, Grid and TRL context, Reports, public-safe summaries, models, datasets, software releases, dashboards, Studio workflows, Academy outputs, Campaign outputs, and handoff packages do not constitute certification, accreditation, compliance approval, standards conformance, safety approval, security certification, quality certification, professional licensing, or public authority approval unless separately and lawfully recorded by a competent body.

### 28.6.4 No-Procurement Notice

No-procurement notice shall state that Nexus materials do not constitute procurement recommendation, tender support, supplier approval, vendor validation, preferred-provider designation, procurement scoring, award justification, purchasing instruction, public procurement decision, or contract award. Any procurement must occur through separate competent procurement processes outside Nexus.

### 28.6.5 No-Finance Notice

No-finance notice shall state that Nexus finance-readiness, capital-readability, insurance-readiness, donor-readiness, public finance relevance, assumptions registers, dependency registers, diligence-gap registers, readiness rooms, metrics, Reports, Marketplace listings, Registry records, Grid context, and handoff packages are provided for learning and dependency awareness only and do not constitute investment advice, insurance advice, underwriting, rating, solicitation, transaction, donor commitment, public finance allocation, financeability, bankability, insurability, or financial instrument.

### 28.6.6 No-Public-Authority Notice

No-public-authority notice shall state that Nexus participation, hosting, public authority learning, non-decision rooms, National Portfolios, dashboards, Reports, DRI outputs, Observatory summaries, Studio workflows, Registry records, Marketplace listings, Grid records, Nexus Universe outputs, and handoff packages do not constitute public authority action, policy adoption, regulatory decision, public finance allocation, procurement decision, official statistics, public warning, emergency command, public health advisory, infrastructure approval, or official endorsement unless separately and lawfully issued by a competent public authority outside Nexus.

### 28.6.7 No-Consent Notice

No-consent notice shall state that participation, display, quotation, mapping, Campaign signature, pledge, contribution, community involvement, Indigenous participation where applicable, public-safe summary, safeguard review, National Portfolio inclusion, Studio scenario, or handoff package does not constitute community consent, Indigenous consent, data-use permission, AI-use permission, land access permission, facility access permission, publication permission, deployment permission, endorsement, or waiver unless separately and lawfully recorded.

### 28.6.8 No-Deployment Notice

No-deployment notice shall state that Nexus readiness, infrastructure readiness, Grid or TRL context, Registry status, Marketplace discovery, software release, model record, dashboard, Studio workflow, public-safe report, public authority learning record, finance-readiness record, or handoff package does not authorize deployment, installation, production use, operational use, public service use, infrastructure use, public authority use, or field implementation.

### 28.6.9 No-Execution Notice

No-execution notice shall state that Nexus does not execute projects, operate infrastructure, procure systems, finance projects, insure projects, underwrite risks, allocate public finance, issue public warnings, command emergencies, provide clinical or public health decisions, deliver regulated services, employ contributors by implication, or implement deployments by virtue of any record, participation, support, listing, review, metric, readiness note, public-safe output, or handoff.

### 28.6.10 Data-Use Notice

Data-use notice shall state the permitted and prohibited uses of data, including whether data is open, controlled, restricted, secure-room-only, data-room-only, protected knowledge room-only, metadata-only, public authority learning-only, handoff-recipient-only, archive-only, sealed, or deletion-required, and whether reuse, redistribution, mapping, publication, AI use, training, embedding, transfer, or handoff is permitted.

### 28.6.11 AI-Use Notice

AI-use notice shall state whether AI use is permitted, restricted, prohibited, no-training, no-embedding, no-agentic-use, human-reviewed, public-safe-transformed, secure-room-only, data-room-only, protected knowledge room-only, or handoff-recipient-only, and shall identify output review, incident pathway, correction pathway, and prohibited uses.

### 28.6.12 Provider-Neutrality Notice

provider-neutrality notice shall state that provider contribution, support, infrastructure, cloud credits, software, hardware, data, APIs, demonstrations, documentation, Marketplace presence, Registry reference, Nexus Universe visibility, Academy support, Studio support, Foundry support, or handoff participation does not create endorsement, validation, preferred-provider status, supplier approval, procurement recommendation, financeability, insurability, public authority approval, deployment authorization, or execution.

### 28.6.13 Sponsor-Boundary Notice

sponsor-boundary notice shall state that sponsor support, funding support where lawful, in-kind support, cloud credits, equipment, venue, communications support, Academy support, Campaign support, Nexus Universe support, Foundry support, accessibility support, or translation support is support without control and does not create agenda control, review influence, routing priority, Registry status, Marketplace preference, Grid status, procurement preference, financeability, public authority approval, deployment authorization, or execution.

### 28.6.14 Handoff-Context Notice

handoff-context notice shall state that a handoff package transfers context, evidence, dependencies, assumptions, limitations, safeguards, public-safe status, readiness questions, public authority dependencies, finance and insurance questions, procurement boundaries, provider-neutrality notes, sponsor-boundary notes, recipient responsibilities, correction pathways, recall pathways, and archive status only, and does not transfer authority, approval, procurement, finance, insurance, public finance allocation, consent, deployment authorization, operational command, or execution.

### 28.6.15 Correction Notice

correction notice shall state that an object has been patched, corrected, revised, superseded, downgraded, suspended, withdrawn, retracted where necessary, recalled, publicly repaired, archived, sealed, deleted where required, or marked non-current, and shall identify the affected object, correction class, effective date, required user action, successor link where applicable, and archive status.

### 28.6.16 Archive Notice

archive notice shall state that an object is archived, non-current, superseded, withdrawn, recalled, deprecated, sealed, deletion-required, deleted-record-only, or archive-only, and shall identify permitted historical use, prohibited current reliance, successor object where applicable, access class, correction history, license status, public-safe status, retention rule, and boundary notices.

The final Templates, Tooling, and Standard Notices rule is: Nexus shall use core object templates, Registry and Marketplace templates, Reports and publication templates, learning and competence templates, portfolio and handoff templates, and standard notices to make every object recordable, reviewable, reusable within limits, public-safe, safeguard-aware, correctionable, recallable, archivable, and boundary-safe. Templates and notices standardize trust; they do not create certification, procurement approval, financeability, insurability, public authority action, consent, deployment authorization, operational command, or execution by implication.

<br>


---

# 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/standardization/nexus-ecosystem/ii.-structure/xxviii.-templates.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.
