# VII. FOUNDRY

Nexus Agile Framework Foundry defines the **NAF public-good production system** for building reusable, reviewable, and correctionable outputs. This section explains how **BuildGrid, programs, tracks, quests, bounties, builds, maintainers, quality gates, release classes, and handoff dependency packages** turn docketed work into structured production.

This section sets the operating model for **micro-production**, **public-good software builds**, **data pipeline builds**, **dashboard builds**, **Studio workflow builds**, **Registry and Marketplace objects**, **maintainer systems**, and **Foundry quality gates**. It helps Nexus produce evidence-bearing outputs at speed while preserving non-execution, public-safe release, correction discipline, and lawful handoff boundaries.

### What this section covers

* **Foundry architecture** - Defines BuildGrid, quests, bounties, builds, release classes, and maintainers.
* **Production model** - Explains micro-production, review gates, support classes, and reusable public-good outputs.
* **Governance boundaries** - Defines correction, archive, lawful handoff, and no-execution controls.

Use this section with [Nexus Agile Framework (NAF)](/organization/operations/frameworks/nexus-agile-framework-naf.md) for the full framework overview, [IV. LIFECYCLE](/organization/operations/frameworks/nexus-agile-framework-naf/iv.-lifecycle.md) for work movement and release discipline, [V. PORTFOLIOS](/organization/operations/frameworks/nexus-agile-framework-naf/v.-portfolios.md) for strategy and portfolio routing, and [VI. PEOPLE](/organization/operations/frameworks/nexus-agile-framework-naf/vi.-people.md) for teams, guilds, and contribution boundaries.

## 7.1 Foundry Position in NAF

### 7.1.1 Foundry as Strategic Build Engine.

7.1.1.1 Nexus Foundry is the strategic build engine within NAF through which public-good priorities, National Portfolio needs, Docket items, evidence gaps, standards-interface gaps, data needs, software needs, Observatory needs, DRI needs, GRIx needs, Studio workflow needs, Campaign needs, Academy needs, Reports needs, Marketplace needs, Registry needs, Grid inputs, TRL notes, Nexus Universe preparation items, and lawful handoff dependencies are converted into structured, reviewable, reusable, correctionable outputs.

7.1.1.2 Foundry shall operate as the build-to-record environment for Nexus. It shall take work that has been signaled, docketed, classified, scoped, and reviewed for readiness, and shall convert such work into public-good objects capable of being released, routed, listed, recorded, taught, demonstrated, corrected, archived, or prepared for lawful handoff dependency review. Foundry shall not operate as an accelerator, venture studio, consultancy delivery shop, procurement workshop, regulated finance platform, standards authority, certification body, public authority substitute, project developer, operator, contractor, or execution vehicle by default.

7.1.1.3 Foundry shall make Nexus capable of disciplined production without collapsing into implementation. It shall permit rapid build activity while preserving non-execution, validity by record, correctionability, public-good firewall, provider neutrality, sponsor support without control, finance-readiness without finance, procurement neutrality, standards awareness without standards-authority overclaim, public authority learning without substitution, and lawful handoff without authority transfer.

### 7.1.2 Foundry as Epistemic Systems-Build Architecture.

7.1.2.1 Foundry is an epistemic systems-build architecture because its primary production function is to convert uncertainty, evidence gaps, risk intelligence, research questions, national priorities, public authority learning questions, technology possibilities, data constraints, standards-interface issues, and safeguard conditions into structured knowledge-bearing and evidence-bearing objects.

7.1.2.2 Foundry shall produce objects that carry their own epistemic status, including evidence basis, assumptions, dependencies, limitations, source classes, data-use labels, AI-use labels, review status, public-safe status, safeguard status, support class, release class, correction pathway, and archive rule. A Foundry output shall be intelligible not only as a technical artifact, but as a record-bearing institutional object.

7.1.2.3 Foundry shall be designed for complex systems where truth, readiness, capability, legitimacy, and lawful implementation cannot be reduced to product delivery. It shall build the evidentiary, technical, semantic, software, data, learning, reporting, and dependency structures that allow Nexus to move from signal to record, from record to public-good work, from work to evidence, from evidence to public-safe knowledge, from knowledge to readiness context, and from readiness context to lawful handoff where appropriate.

### 7.1.3 Foundry as Public-Good Production Layer.

7.1.3.1 Foundry is the public-good production layer of NAF. It shall create and maintain reusable public-good outputs including public-good software, open technical baselines, data pipelines, dashboards, notebooks, APIs, SDKs, connectors, adapters, methods, schemas, ontologies, controlled vocabularies, DRI indicators, GRIx mappings, Studio workflows, Reports, Campaign assets, Academy learning objects, Registry records, Marketplace objects, Grid inputs, TRL evidence notes, Nexus Universe outputs, and lawful handoff dependency packages.

7.1.3.2 Public-good production shall mean production for shared learning, evidence, interoperability, resilience, public-safe reporting, national capability, public authority learning, open where safe and controlled where necessary, correctionable records, and lawful downstream use by competent actors. Public-good production shall not mean free extraction, sponsor capture, provider capture, unpaid labor exploitation, uncontrolled publication, unrestricted data release, unrestricted AI use, or execution by implication.

7.1.3.3 Foundry outputs shall be governed by object identity, versioning, steward assignment, maintainer assignment, contributor records, review records, release class, support class, Registry status, Marketplace eligibility, public-safe release rules, data and AI controls, cyber and privacy controls, safeguard controls, correction rules, withdrawal rules, recall rules, archive rules, and handoff dependency rules.

### 7.1.4 Foundry as National Portfolio Build Support.

7.1.4.1 Foundry shall support National Portfolios by converting national priorities, National Challenge Briefs, Evidence Need Records, Observatory Need Records, Core Build Requests, Safeguard Records, Public Authority Learning Records, Readiness Question Records, Competence Cell Workplans, Universe Arena Routing Records, and National Portfolio correction items into structured builds.

7.1.4.2 Foundry support to National Portfolios shall preserve national ownership before local delivery. National Portfolio builds shall record national context, language and localization requirements, public authority dependencies, data sovereignty, public-safe requirements, community safeguards, Indigenous protocols where applicable, protected knowledge constraints, provider-neutrality conditions, sponsor-boundary conditions, finance-readiness questions, procurement-neutrality conditions, and lawful handoff pathways.

7.1.4.3 Foundry shall not bypass National Nexus Consortiums, National Councils, National Working Groups, National Nodes, public authority learning pathways, safeguard processes, community pathways, Indigenous protocols where applicable, or lawful national implementation channels. Foundry may support national build readiness; it shall not create national adoption, public authority approval, procurement status, financeability, insurance approval, consent, deployment authorization, or execution.

### 7.1.5 Foundry as Nexus Universe Preparation Engine.

7.1.5.1 Foundry shall operate as a principal preparation engine for Nexus Universe. It shall prepare Core Build items, arena materials, Studio workflows, Reports, Campaign assets, Marketplace objects, Registry updates, Grid inputs, TRL notes, National Portfolio outputs, public authority learning materials, readiness-room materials, capital-reader room materials, insurance-reader room materials, donor-reader room materials, public finance learning materials, and handoff dependency packages for annual convergence.

7.1.5.2 Foundry shall convert year-round distributed work into Nexus Universe-ready records. It shall support the formula of annual surge and year-round development; temporary stack and permanent record; open contribution and controlled release; technical intensity and institutional memory; distributed contributors and recorded authority; public-good learning and lawful handoff; ambition without execution by implication.

7.1.5.3 Nexus Universe readiness produced by Foundry shall not imply endorsement, certification, financeability, insurance approval, procurement readiness, public authority decision, community consent, Indigenous consent, deployment authorization, or execution. Foundry preparation makes work presentable, reviewable, reusable, and correctionable; it does not make work approved.

### 7.1.6 Foundry as Lawful Handoff Dependency Producer.

7.1.6.1 Foundry shall produce lawful handoff dependency packages where public-good outputs may become relevant to competent downstream actors. Such packages may include evidence context, data context, method context, software context, Studio context, Grid and TRL context, public-safe status, safeguard status, public authority dependencies, legal dependencies, finance-readiness questions, insurance-readiness questions, donor-readiness questions, public finance relevance questions, procurement-neutrality notes, provider-neutrality notes, sponsor-boundary notes, support status, recipient responsibilities, correction pathway, recall pathway, and archive rule.

7.1.6.2 Foundry handoff dependency packages shall transfer context, not authority. They shall help lawful recipients understand what has been built, reviewed, limited, corrected, supported, restricted, unresolved, or dependent on external decisions. The recipient shall remain responsible for independent diligence, legal authority, public authority approvals, procurement processes, finance decisions, insurance decisions, implementation decisions, community processes, Indigenous processes where applicable, safety duties, and operational execution.

7.1.6.3 Foundry shall not authorize handoff by itself. Foundry output shall not create implementation authority, financing, underwriting, procurement, certification, public authority approval, consent, deployment, operation, command, or execution.

### 7.1.7 Foundry as Non-Executing Production Context.

7.1.7.1 Foundry shall be production without default execution. It may produce technical artifacts, public-good software, data objects, Reports, workflows, dashboards, learning objects, records, readiness notes, and handoff dependency packages, but it shall not operate, deploy, procure, finance, insure, certify, approve, command, regulate, or execute projects unless a separate lawful execution pathway is created outside Foundry’s default public-good posture.

7.1.7.2 Foundry participants, maintainers, reviewers, contributors, sponsors, providers, public authorities, capital readers, insurers, donors, hosts, communities, Indigenous participants where applicable, media actors, and lawful handoff recipients shall be bound by Foundry’s no-conversion rule. Their presence or contribution shall not convert Foundry work into endorsement, approval, certification, financeability, procurement status, consent, deployment authorization, or execution.

7.1.7.3 Foundry shall preserve production boundaries through Docket discipline, release classes, support classes, review gates, Registry status truth, Marketplace disclaimers, public-safe reporting, role records, sponsor and provider controls, data and AI controls, safeguard records, legal boundary notices, correction records, and archive records.

### 7.1.8 Foundry as Repeatability, Lifecycle, and Correction Engine.

7.1.8.1 Foundry shall make Nexus production repeatable by defining common object classes, templates, build pathways, review gates, release classes, maintainer roles, support classes, correction actions, archive rules, and lawful handoff dependency structures. Repeatability shall not mean rigidity; it shall mean that public-good production can be trusted, transferred, localized, reviewed, corrected, and reused across national, regional, thematic, sectoral, and technology contexts.

7.1.8.2 Foundry shall manage lifecycle from intake to build, from build to review, from review to release, from release to Registry and Marketplace, from Registry and Marketplace to Reports, Studio, Grid, TRL, Academy, Campaigns, Nexus Universe, National Portfolios, and handoff dependency pathways, and from any stage to correction, withdrawal, recall, archive, or non-continuation.

7.1.8.3 Foundry correction shall be treated as core production, not exceptional failure. A correctionable Foundry output is superior to an uncorrectable output. Foundry shall record correction, addendum, revision, supersession, downgrade, suspension, withdrawal, retraction where necessary, recall, public repair, archive, and non-continuation, and shall propagate correction to affected Registry records, Marketplace listings, Reports, Studio workflows, Grid inputs, TRL notes, Campaigns, Academy materials, National Portfolios, Nexus Universe outputs, and handoff packages.

## 7.2 Distributed BuildGrid

### 7.2.1 Programs.

7.2.1.1 BuildGrid Programs are the highest build units within Foundry. Programs shall organize sustained production across major Nexus domains, pillars, mechanisms, technologies, hazards, national portfolios, regional clusters, Nexus Universe cycles, public-good software families, data commons, risk intelligence systems, Academy pathways, Campaign families, Studio environments, Grid and TRL pathways, Reports portfolios, Marketplace and Registry systems, and lawful handoff dependency systems.

7.2.1.2 A Program shall have a defined purpose, steward, scope, portfolio linkage, Docket linkage, affected Nexus pillars and mechanisms, national or regional relevance, output classes, support model, maintainer structure, review gates, release classes, data and AI controls, cyber controls, safeguard controls, public-safe controls, sponsor and provider boundaries, correction pathway, archive rule, and lawful handoff conditions where applicable.

7.2.1.3 Program status shall not create certification, approval, procurement, finance, insurance, public authority action, consent, deployment, or execution. Programs organize production; they do not authorize implementation.

### 7.2.2 Tracks.

7.2.2.1 Tracks are subdivisions of Programs organized around a narrower domain, theme, technology, output class, national priority, regional cluster, lifecycle stage, or build pathway. Tracks may include data tracks, AI tracks, cyber tracks, WFEH-B tracks, DRR tracks, DRF tracks, DRI tracks, Observatory tracks, Studio tracks, Reports tracks, Campaign tracks, Academy tracks, Marketplace tracks, Registry tracks, Grid tracks, TRL tracks, Nexus Universe tracks, and handoff dependency tracks.

7.2.2.2 Each Track shall define work scope, track lead or steward, Docket references, output classes, quality gates, dependencies, assumptions, support class, release class, contributor model, maintainer model, review rules, public-safe rules, safeguard rules, correction rules, and archive rule.

7.2.2.3 Tracks shall enable specialization without fragmentation. Track outputs shall remain interoperable with NAF records, DICE, GRIx, DRI, Nexus Observatory, Nexus Studio, Nexus Grid, Nexus Reports, Nexus Marketplace, Nexus Registry, Nexus Rails, Nexus Network, National Portfolios, and lawful handoff dependency structures.

### 7.2.3 Quests.

7.2.3.1 Quests are structured problem statements or contribution missions that convert Docket items into discoverable, scoped work opportunities. A Quest shall define the question, need, output sought, evidence basis, expected contribution type, review requirements, data and AI labels, public-safe status, safeguard status, support class, acceptance criteria, correction pathway, and archive rule.

7.2.3.2 Quests may invite learning contribution, research contribution, data contribution, software contribution, ontology contribution, DRI contribution, WFEH-B contribution, public-safe reporting contribution, safeguard contribution, National Portfolio contribution, Nexus Universe preparation contribution, or handoff dependency contribution.

7.2.3.3 A Quest shall not create employment, procurement qualification, provider validation, professional certification, public authority approval, financeability, insurance approval, consent, deployment authorization, or execution. Quest completion is contribution evidence, not authority.

### 7.2.4 Bounties.

7.2.4.1 Bounties are scoped contribution opportunities within BuildGrid that may be supported by recognition, iCRS credits, learning credit, honoraria, stipends, non-financial rewards, or other lawful support. Bounties shall have precise scope, acceptance criteria, review requirements, support status, labor boundary notice, data and AI labels, public-safe status, safeguard status, ownership or license terms, correction pathway, and archive rule.

7.2.4.2 Bounties may support micro-tasks, micro-builds, data labeling where lawful and safeguarded, dataset documentation, software fixes, dashboard improvements, Report components, public-safe summaries, translations, accessibility improvements, testing, benchmark contributions, Studio workflow components, Registry record cleanup, Marketplace metadata, Grid input preparation, TRL evidence notes, and handoff dependency preparation.

7.2.4.3 Bounty participation shall not create employment by implication, wage entitlement beyond recorded support, procurement status, certification, professional license, provider validation, financeability, insurance approval, public authority approval, consent, deployment authorization, or execution.

### 7.2.5 Builds.

7.2.5.1 Builds are concrete Foundry production objects created through structured work. Builds may be software builds, data pipeline builds, dashboard builds, Studio workflow builds, Marketplace object builds, Registry record builds, Grid input builds, TRL evidence builds, National Portfolio builds, Reports builds, Campaign builds, Academy builds, DRI builds, GRIx builds, Observatory builds, open technical baseline builds, Nexus Universe builds, and handoff dependency builds.

7.2.5.2 Each Build shall include object identity, purpose, scope, source class, evidence basis, steward, contributors, maintainers, reviewers, dependencies, assumptions, data-use label, AI-use label, cyber status, privacy status, public-safe status, safeguard status, review status, release class, support class, Registry status, Marketplace eligibility, correction pathway, withdrawal pathway, recall pathway where applicable, archive rule, and handoff relevance where applicable.

7.2.5.3 Build completion shall not imply certification, warranty, security approval, AI safety approval, procurement readiness, financeability, insurability, public authority approval, consent, deployment authorization, or execution. Build completion means a bounded object has reached a recorded lifecycle state.

### 7.2.6 Maintainers.

7.2.6.1 Maintainers are persons or groups assigned to steward the continuity, quality, review, support, correction, versioning, deprecation, withdrawal, archive, or handoff dependency status of Foundry objects. Maintainers may be assigned by repository, dataset, model, ontology, API, dashboard, Studio workflow, Report family, Campaign asset, Academy object, Registry object, Marketplace object, Grid input, TRL note, National Portfolio object, or handoff dependency package.

7.2.6.2 Maintainers shall preserve support status, known issues, dependency status, vulnerability channels, correction records, release notes, public-safe documentation, accessibility status, localization status, user feedback, contributor records, provider contribution records, sponsor support records, and archive rules.

7.2.6.3 Maintainer status shall not create ownership by default, certification authority, professional license, public authority status, procurement authority, finance authority, insurance authority, consent authority, deployment authority, or execution authority. Maintainers steward continuity and correction within scope.

### 7.2.7 Review Gates.

7.2.7.1 Review Gates are required checkpoints through which Foundry work shall pass before movement to specified release classes, Registry statuses, Marketplace listings, Reports publication, Studio use, Grid input, TRL note, Nexus Universe presentation, National Portfolio routing, or handoff dependency packaging.

7.2.7.2 Review Gates may include intake review, evidence review, data review, AI-use review, cyber review, privacy review, public-safe review, safeguard review, standards-interface review, marketplace review, registry review, Grid and TRL review, release review, and handoff review.

7.2.7.3 Review Gates shall be recorded by scope, reviewer class, evidence reviewed, limitations, findings, required corrections, release implications, boundary notices, unresolved questions, and archive rule. Review Gate completion shall not create certification, approval, legal compliance determination, public authority action, finance approval, insurance approval, procurement decision, consent, deployment authorization, or execution.

### 7.2.8 Release Classes.

7.2.8.1 Foundry Release Classes shall define how a build may be used, viewed, shared, listed, published, demonstrated, routed, corrected, or archived. Release Classes may include draft, internal review, sandbox, Studio-only, secure-room-only, data-room-only, controlled public, public-safe summary, open public, Marketplace candidate, Registry-recorded, Nexus Universe-ready, handoff-recipient-only, archived, and non-continuing.

7.2.8.2 Release Class assignment shall be based on evidence, data, AI, cyber, privacy, public-safe, safeguard, support, standards-interface, national routing, and handoff considerations. Release Class assignment shall be reviewable and correctable.

7.2.8.3 Release Class shall not imply certification, approval, public authority decision, procurement status, financeability, insurance approval, consent, deployment authorization, or execution. Release Class controls exposure and use; it does not create authority.

### 7.2.9 Archives.

7.2.9.1 Foundry Archives shall preserve inactive, superseded, deprecated, unsupported, withdrawn, recalled, corrected, non-continuing, or historical Foundry objects. Archives shall include object identity, version, steward, contributors, maintainers, status, release history, correction history, support status, license status, access class, public-safe status, sensitivity class, successor link, retention rule, deletion or sealing rule where applicable, and permitted historical use.

7.2.9.2 Archives shall prevent obsolete objects from being misused as current authority. Archive-not-current notices shall be applied where appropriate. Archive records may support institutional memory, research, audit, learning, correction analysis, and future successor design.

7.2.9.3 Archive status shall not create current authority, support obligation, certification, procurement status, financeability, insurance approval, public authority approval, deployment authorization, or execution.

### 7.2.10 Correction Loops.

7.2.10.1 Correction Loops are continuous feedback and repair pathways that allow Foundry outputs to be corrected, revised, downgraded, suspended, withdrawn, recalled, superseded, archived, or reinstated where appropriate. Correction Loops may be triggered by evidence updates, user feedback, public-safe issues, data incidents, AI incidents, cyber incidents, privacy incidents, safeguard concerns, standards-interface changes, dependency changes, vulnerability reports, public authority boundary concerns, finance or procurement overclaims, sponsor or provider boundary issues, consent concerns, handoff concerns, or execution overclaims.

7.2.10.2 Correction Loops shall propagate to all affected records and outputs, including Dockets, Reports, Registry records, Marketplace listings, Studio workflows, Grid inputs, TRL notes, Campaign materials, Academy objects, National Portfolios, Nexus Universe materials, handoff dependency packages, public-safe notices, and archives.

7.2.10.3 Correction shall be treated as a normal lifecycle function. Foundry shall measure trust partly by correction quality, not by the absence of correction.

## 7.3 Micro-Production Model

### 7.3.1 Micro-Production Defined.

7.3.1.1 Micro-Production is the Foundry operating model through which large public-good outputs are decomposed into small, scoped, reviewable, reusable, evidence-bearing, and correctionable work units. Micro-Production enables distributed contributors, learners, experts, maintainers, reviewers, Working Groups, Competence Cells, Guilds, Academy Cohorts, Campaign Teams, Labs Streams, and National Portfolio Teams to contribute safely to complex Nexus outputs.

7.3.1.2 Micro-Production shall allow Nexus to build at ecosystem scale without losing records discipline. Each micro-output shall carry identity, purpose, scope, contributor record, review status, release implication, support class, data and AI label where applicable, public-safe status, safeguard status where applicable, correction pathway, and archive rule.

7.3.1.3 Micro-Production shall not fragment responsibility. The aggregation of micro-outputs into larger builds shall require maintainer oversight, review gates, integration records, release classes, Registry records, Marketplace records where applicable, and correction propagation.

### 7.3.2 Micro-Tasks.

7.3.2.1 Micro-Tasks are the smallest actionable units of Foundry work. They may include citation checking, metadata completion, schema drafting, data dictionary entry, translation, accessibility review, public-safe wording review, code fix, test addition, notebook update, model card field completion, system card review, benchmark note, DRI indicator note, GRIx mapping, dashboard label, Studio workflow step, Registry field update, Marketplace metadata update, Report section draft, Campaign asset review, or handoff dependency field completion.

7.3.2.2 Each Micro-Task shall include scope, expected output, acceptance criteria, contributor class, review requirement, support status, dependency, data or confidentiality restriction where applicable, public-safe status, correction pathway, and archive rule.

7.3.2.3 Micro-Task completion shall not create approval, certification, employment, procurement status, financeability, insurance approval, public authority action, consent, deployment authorization, or execution.

### 7.3.3 Micro-Bounties.

7.3.3.1 Micro-Bounties are small scoped contribution opportunities that may carry recognition, iCRS credit, learning credit, non-financial reward, stipend, honorarium, or other lawful support. They shall be used only where task scope, acceptance criteria, review conditions, labor boundary, support class, and correction pathway are clear.

7.3.3.2 Micro-Bounties shall be designed to avoid exploitation, ambiguity, disguised labor, unequal access, or private capture. They shall not substitute for necessary paid professional work where legal, ethical, safety, operational, or labor conditions require a different structure.

7.3.3.3 Micro-Bounty completion shall not create employment, wage entitlement beyond recorded support, certification, procurement qualification, provider validation, public authority approval, financeability, insurance approval, deployment authorization, or execution.

### 7.3.4 Micro-Builds.

7.3.4.1 Micro-Builds are small build outputs that can be integrated into larger Foundry builds. They may include code modules, API endpoints, dashboard widgets, dataset transformations, metadata packages, documentation fragments, Report sections, learning object units, Studio workflow components, Registry record fragments, Marketplace listing components, Grid evidence fragments, TRL evidence notes, and handoff dependency fragments.

7.3.4.2 Micro-Builds shall require integration review before becoming part of a larger object. Integration review shall check compatibility, dependency, security, public-safe status, data and AI labels, licensing, support class, review status, safeguard conditions, and correction propagation.

7.3.4.3 Micro-Build status shall not be represented as final release, certification, approval, deployment authorization, or execution.

### 7.3.5 Micro-Reviews.

7.3.5.1 Micro-Reviews are focused reviews of micro-tasks, micro-bounties, micro-builds, fields, records, sections, components, metadata, code fragments, datasets, labels, public-safe text, safeguard flags, or handoff dependency entries.

7.3.5.2 Micro-Reviews shall record reviewer identity or reviewer class, review scope, finding, limitations, required changes, acceptance or rejection status, correction need, and archive rule. Micro-Reviews may be performed by maintainers, reviewers, Guild members, Competence Cells, Working Groups, or designated stewards.

7.3.5.3 Micro-Review acceptance shall not create certification, legal approval, public authority approval, finance approval, insurance approval, procurement decision, consent, deployment authorization, or execution.

### 7.3.6 Micro-Releases.

7.3.6.1 Micro-Releases are controlled releases of small Foundry outputs into a defined environment, such as internal review, sandbox, Studio-only, data-room-only, secure-room-only, controlled public, public-safe summary, Registry update, Marketplace candidate, Nexus Universe preparation, or handoff-recipient-only context.

7.3.6.2 Micro-Releases shall include release class, version, scope, limitations, dependencies, public-safe status, support class, correction pathway, withdrawal rule, and archive rule. Micro-Releases shall be traceable to their parent Docket item and parent build where applicable.

7.3.6.3 Micro-Release shall not imply general availability, certification, warranty, approval, deployment authorization, or execution.

### 7.3.7 Micro-Corrections.

7.3.7.1 Micro-Corrections are focused corrections to micro-tasks, micro-builds, records, fields, labels, metadata, code fragments, documentation, public-safe wording, safeguard status, release class, support class, or handoff dependency entries.

7.3.7.2 Micro-Corrections shall be recorded and propagated to affected parent objects. Where a micro-correction affects a public object, Registry status, Marketplace listing, Report, Studio workflow, Grid input, TRL note, Nexus Universe material, National Portfolio object, or handoff package, appropriate correction notices shall be applied.

7.3.7.3 Micro-Correction shall not be hidden where downstream reliance, public-safe communication, data rights, AI use, cyber safety, safeguards, finance/procurement boundaries, public authority boundaries, consent boundaries, or handoff dependencies are affected.

### 7.3.8 Micro-Archives.

7.3.8.1 Micro-Archives shall preserve micro-tasks, micro-bounties, micro-builds, micro-reviews, micro-releases, micro-corrections, and abandoned or non-continuing micro-outputs. Micro-Archives shall include parent object linkage, status, support class, release class, correction history, successor link where applicable, and archive-not-current notice where appropriate.

7.3.8.2 Micro-Archives shall allow institutional memory and contributor recognition while preventing obsolete fragments from being reused as current authority.

### 7.3.9 Micro-Production Support Classes.

7.3.9.1 Micro-Production Support Classes shall define expected support for micro-outputs. Support classes may include unsupported contribution, community-supported, maintainer-supported, Academy-supported, Foundry-supported, National Node-supported, Studio-supported, handoff-recipient-supported, time-limited support, and archived support.

7.3.9.2 Support Class shall identify who may respond to issues, whether updates are expected, whether security review is maintained, whether public-safe review is maintained, whether documentation is current, whether localization is supported, and whether the object is suitable for integration.

7.3.9.3 Support Class shall not create warranty, service-level guarantee, procurement status, financeability, insurance approval, public authority approval, or deployment authorization.

### 7.3.10 Micro-Production Boundaries.

7.3.10.1 Micro-Production shall not be used to evade governance. Small tasks may still require data review, AI review, cyber review, privacy review, public-safe review, safeguard review, legal-boundary review, sponsor/provider controls, labor classification review, and correction where risk requires it.

7.3.10.2 Micro-Production shall not be used to disguise labor, fragment accountability, conceal sponsor influence, bypass national ownership, bypass public authority dependencies, bypass community safeguards, bypass Indigenous protocols where applicable, bypass data rights, bypass security controls, bypass procurement neutrality, bypass finance-readiness boundaries, or bypass lawful handoff review.

7.3.10.3 The final rule of Micro-Production is that small work remains real work, small records remain governance records, small errors require correction, and small contributions shall not create authority, employment, certification, procurement, finance, insurance, consent, deployment, or execution by implication.

## 7.4 Quest Architecture

### 7.4.1 Research Quests.

7.4.1.1 Research Quests shall structure research questions, literature reviews, evidence gaps, testbed questions, methods development, scientific translation, policy intelligence, public-safe research summaries, and Labs-to-Foundry transfer items. A Research Quest shall record research question, evidence need, method, source class, ethics considerations, data conditions, AI-use conditions, public-safe release limits, safeguard conditions, review pathway, correction pathway, and archive rule.

7.4.1.2 Research Quest outputs may become Labs records, Reports, Academy objects, Foundry builds, Studio workflows, Grid inputs, TRL notes, National Portfolio records, Nexus Universe materials, Marketplace objects, Registry records, or handoff dependency context.

7.4.1.3 Research Quest completion shall not create scientific certainty, policy approval, public authority decision, certification, financeability, insurance approval, procurement status, deployment authorization, or execution.

### 7.4.2 Data Quests.

7.4.2.1 Data Quests shall structure work involving data discovery, metadata, data dictionaries, schemas, lineage, data quality, public-safe transformation, synthetic data where appropriate, data-use labels, AI-use labels, DICE routing, data-room preparation, secure-room preparation, compute-to-data workflows, National Portfolio data needs, DRI data needs, Observatory data needs, and handoff data context.

7.4.2.2 Data Quests shall require rights review, sensitivity classification, data sovereignty review, privacy review, public authority-sensitive review where applicable, community-sensitive review where applicable, Indigenous protocol-sensitive review where applicable, protected knowledge review, cyber-sensitive review, geospatial-sensitive review, public-safe review, and correction pathway.

7.4.2.3 Data Quest completion shall not create data rights, publication permission, unrestricted reuse, AI training permission, public authority approval, handoff permission, or execution.

### 7.4.3 Evidence Quests.

7.4.3.1 Evidence Quests shall assemble, test, document, and review evidence for Docket items, National Portfolios, Reports, Studio workflows, Grid inputs, TRL notes, Marketplace listings, Registry records, Nexus Universe outputs, public authority learning, readiness rooms, and handoff dependency packages.

7.4.3.2 Evidence Quests shall record evidence sources, source quality, method quality, assumptions, dependencies, uncertainty, confidence where applicable, limitations, public-safe status, safeguard status, review pathway, correction pathway, and archive rule.

7.4.3.3 Evidence Quest completion shall not create approval, certification, public authority decision, financeability, insurance approval, procurement readiness, consent, deployment authorization, or execution.

### 7.4.4 Software Quests.

7.4.4.1 Software Quests shall structure work involving public-good software, open technical baselines, reference implementations, APIs, SDKs, connectors, adapters, dashboards, notebooks, templates, infrastructure-as-code, test suites, model evaluation tools, Studio components, Registry tools, Marketplace tools, Reports tools, Campaign tools, Academy tools, DICE tools, GRIx tools, DRI tools, Observatory tools, Rails tools, and National Node tools.

7.4.4.2 Software Quests shall include repository rules, license status, contribution rules, maintainer assignment, code review, dependency scanning, secret scanning, SBOM records where appropriate, vulnerability disclosure, documentation, accessibility review, support class, release class, correction pathway, deprecation rule, and archive rule.

7.4.4.3 Software Quest completion shall not create warranty, security certification, production approval, procurement recommendation, provider validation, public authority approval, deployment authorization, or execution.

### 7.4.5 Ontology Quests.

7.4.5.1 Ontology Quests shall structure work involving GRIx categories, controlled vocabularies, taxonomies, semantic mappings, schemas, data dictionaries, knowledge graphs, standards-interface mappings, localization, translation, risk categories, WFEH-B categories, DRR/DRF/DRI categories, technology categories, safeguard categories, public authority boundary categories, finance and insurance boundary categories, and handoff dependency categories.

7.4.5.2 Ontology Quests shall record term proposals, definitions, source basis, mapping status, localization status, translation status, scope, limitations, versioning, deprecation, correction pathway, and archive rule.

7.4.5.3 Ontology Quest completion shall not create legal classification, standards authority, certification, rating, public authority decision, or compliance determination.

### 7.4.6 DRI Quests.

7.4.6.1 DRI Quests shall structure disaster-risk-intelligence work involving indicators, signals, dashboards, hotspot records, multi-hazard records, cascade records, uncertainty labels, confidence labels, public-safe intelligence summaries, National DRI contributions, Observatory links, Studio scenarios, Reports, Grid inputs, Nexus Universe materials, and handoff context.

7.4.6.2 DRI Quests shall require public-safe communication controls, no-warning notices, no-rating notices, data sensitivity review, geospatial sensitivity review, public authority boundary review, finance/insurance boundary review, and correction pathway.

7.4.6.3 DRI Quest completion shall not create public warning, emergency command, insurance score, investment signal, procurement score, public authority decision, or execution.

### 7.4.7 WFEH-B Quests.

7.4.7.1 WFEH-B Quests shall structure water, food, energy, health, biodiversity, nature, infrastructure, climate, cyber-physical resilience, and cross-system cascade work. WFEH-B Quests may produce evidence packs, DRI inputs, Observatory needs, Studio scenarios, Reports, Campaigns, Academy modules, Foundry builds, National Portfolio records, Grid inputs, TRL notes, Nexus Universe materials, and handoff dependency packages.

7.4.7.2 WFEH-B Quests shall account for system dependencies, public authority dependencies, community safeguards, Indigenous protocols where applicable, protected knowledge, sensitive geospatial data, health-sensitive data, public-safe reporting, finance-readiness questions, insurance-readiness questions, donor-readiness questions, and procurement-neutrality controls.

7.4.7.3 WFEH-B Quest completion shall not create environmental approval, public health decision, resource allocation, public warning, public authority approval, financeability, insurance approval, procurement status, consent, deployment authorization, or execution.

### 7.4.8 Public-Safe Reporting Quests.

7.4.8.1 Public-Safe Reporting Quests shall structure work to convert evidence, data, risk intelligence, research, Studio outputs, National Portfolio objects, Campaign material, Foundry outputs, Grid inputs, TRL notes, and handoff dependency context into public-safe language and publication formats.

7.4.8.2 Such Quests shall apply no-warning language, no-approval language, no-finance language, no-procurement language, no-certification language, no-consent language, no-execution language, protected knowledge controls, sensitive geospatial controls, sponsor/provider controls, correction notices, and public repair pathways.

7.4.8.3 Public-Safe Reporting Quest completion shall not create public warning authority, media approval, public authority approval, legal clearance by default, certification, financeability, procurement status, consent, deployment authorization, or execution.

### 7.4.9 Safeguard Quests.

7.4.9.1 Safeguard Quests shall structure work involving community safeguards, Indigenous protocols where applicable, protected knowledge, youth safeguards, disability inclusion, accessibility, humanitarian sensitivity, conflict sensitivity, rights concerns, non-extractive engagement, community-facing correction, and safeguard stop-the-line conditions.

7.4.9.2 Safeguard Quests may produce safeguard records, public-safe restrictions, access restrictions, data restrictions, Studio room restrictions, Campaign modifications, Report restrictions, Marketplace delisting recommendations, Registry status updates, handoff conditions, and correction records.

7.4.9.3 Safeguard Quest completion shall not grant consent, legal permission, public authority approval, protected knowledge use permission, land access, deployment authorization, or execution.

### 7.4.10 National Portfolio Quests.

7.4.10.1 National Portfolio Quests shall structure work arising from National Context Records, National Systems-Risk Maps, National Challenge Briefs, Evidence Need Records, Observatory Need Records, Core Build Requests, Safeguard Records, Public Authority Learning Records, Readiness Question Records, Competence Cell Workplans, Universe Arena Routing Records, and National Portfolio corrections.

7.4.10.2 National Portfolio Quests shall preserve national ownership, localization, data sovereignty, public authority boundaries, national stakeholder pathways, community safeguards, Indigenous protocols where applicable, sponsor/provider boundaries, finance-readiness boundaries, procurement neutrality, public-safe reporting, and handoff dependency limits.

7.4.10.3 National Portfolio Quest completion shall not create government approval, national endorsement, public finance allocation, procurement readiness, financeability, insurance approval, consent, deployment authorization, or execution.

### 7.4.11 Nexus Universe Preparation Quests.

7.4.11.1 Nexus Universe Preparation Quests shall structure work required for arena readiness, Core Build readiness, Studio workflow readiness, Reports release, Campaign activation, Registry update, Marketplace listing, public authority learning room preparation, readiness room preparation, capital-reader room preparation, insurance-reader room preparation, donor-reader room preparation, public finance learning preparation, Grid and TRL preparation, and handoff dependency preparation.

7.4.11.2 These Quests shall record presentation class, release class, public-safe status, data and AI labels, safeguard status, sponsor/provider controls, public authority boundary notices, finance/insurance/procurement boundary notices, correction pathway, and post-Universe continuation.

7.4.11.3 Nexus Universe Preparation Quest completion shall not imply endorsement, approval, certification, financeability, insurance approval, procurement status, consent, deployment authorization, or execution.

### 7.4.12 Handoff Dependency Quests.

7.4.12.1 Handoff Dependency Quests shall structure work required to prepare lawful handoff dependency packages. Such Quests shall identify evidence context, data context, method context, software 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, and archive rule.

7.4.12.2 Handoff Dependency Quests shall be no-execution by design. They shall help clarify what remains for competent lawful actors and shall not make or imply implementation decisions.

7.4.12.3 Completion of a Handoff Dependency Quest shall not authorize handoff, implementation, finance, insurance, procurement, certification, consent, deployment, operation, command, or execution.

## 7.5 Bounty Architecture

### 7.5.1 Bounty Classes.

7.5.1.1 Bounty Classes shall define the type of scoped contribution opportunity offered through Foundry. Classes may include learning bounties, research bounties, data bounties, evidence bounties, software bounties, documentation bounties, testing bounties, translation bounties, accessibility bounties, public-safe reporting bounties, safeguard bounties, DRI bounties, GRIx bounties, WFEH-B bounties, Studio bounties, Marketplace bounties, Registry bounties, Grid bounties, TRL bounties, National Portfolio bounties, Nexus Universe bounties, correction bounties, archive bounties, and handoff dependency bounties.

7.5.1.2 Each Bounty Class shall carry appropriate contributor eligibility, review requirements, labor boundary notices, support class, reward or recognition structure, data and AI controls, public-safe controls, safeguard controls, and correction pathways.

7.5.1.3 Bounty Class shall not determine legal work status by itself. Legal status shall depend on applicable law, work design, support type, control, duration, compensation, beneficiary, and recorded agreement.

### 7.5.2 Bounty Scope.

7.5.2.1 Bounty Scope shall define the precise task, expected output, acceptance criteria, evidence basis, permitted methods, prohibited methods, data access conditions, AI-use permissions, tools permitted, timeline, support class, review gate, license or rights terms, public-safe obligations, safeguard obligations, and correction obligations.

7.5.2.2 Bounty Scope shall be narrow enough for fair contribution and review, and clear enough to avoid labor ambiguity, disguised employment, hidden sponsor influence, unclear ownership, or unreviewable outputs.

7.5.2.3 Work outside Bounty Scope shall not be accepted as authority, approval, release, or handoff context unless separately reviewed and recorded.

### 7.5.3 Bounty Evidence.

7.5.3.1 Bounty Evidence shall include the records required to prove that a bounty output was produced, reviewed, accepted, rejected, corrected, withdrawn, archived, or integrated. Evidence may include files, commits, datasets, notes, screenshots, logs, metadata, review comments, public-safe summaries, tests, benchmark outputs, model cards, system cards, Studio records, or dependency notes.

7.5.3.2 Bounty Evidence shall be linked to contributor records, Docket references, build records, review records, iCRS records where applicable, ILA records where applicable, Registry records where applicable, Marketplace objects where applicable, and correction records.

7.5.3.3 Bounty Evidence shall not create certification, employment, procurement qualification, financeability, insurance approval, public authority approval, deployment authorization, or execution.

### 7.5.4 Bounty Review.

7.5.4.1 Bounty Review shall determine whether the bounty output meets scope, quality, evidence, data, AI, cyber, privacy, public-safe, safeguard, licensing, support, and correction requirements. Review may be conducted by maintainers, reviewers, Guilds, Working Groups, Competence Cells, Studio stewards, Registry stewards, Marketplace stewards, Grid reviewers, TRL reviewers, or handoff dependency reviewers.

7.5.4.2 Bounty Review shall be recorded as accepted, conditionally accepted, returned for revision, rejected, withdrawn, archived, or escalated. Findings shall include limitations and downstream restrictions.

7.5.4.3 Bounty Review shall not create professional certification, provider validation, public authority approval, procurement decision, finance approval, insurance approval, consent, deployment authorization, or execution.

### 7.5.5 Bounty Support.

7.5.5.1 Bounty Support may include guidance, templates, mentorship, learning resources, data access, tool access, cloud access, compute access, Studio access, review access, translation support, accessibility support, technical support, stipend support, honorarium support, recognition support, or iCRS recognition.

7.5.5.2 Bounty Support shall be recorded, including source of support, sponsor involvement if any, provider involvement if any, support limits, no-control rules, no-validation rules, data and confidentiality conditions, and correction pathways.

7.5.5.3 Bounty Support shall not create sponsor control, provider validation, employment, service warranty, financeability, procurement status, public authority approval, consent, deployment authorization, or execution.

### 7.5.6 Bounty Reward and iCRS Relationship.

7.5.6.1 Bounty outputs may be recognized through the Integrated Credits and Rewards System where applicable. iCRS may record contribution credit, learning credit, review credit, mentor credit, bounty recognition, public-good contribution, correction contribution, or other non-financial recognition.

7.5.6.2 iCRS recognition shall be bounded, correctable, and non-convertible by default. It shall not be currency, equity, token, wage, professional credential, employment status, procurement qualification, finance claim, insurance claim, public authority status, or execution right.

7.5.6.3 Any monetary stipend, honorarium, or support associated with a bounty shall be separately recorded and shall not convert iCRS into a financial instrument or create employment by implication.

### 7.5.7 Bounty Non-Financial Default.

7.5.7.1 Bounties shall default to non-financial recognition unless a lawful support arrangement is separately recorded. Non-financial recognition may include contribution records, learning records, public-good recognition, iCRS credits, portfolio evidence, maintainer acknowledgment, Registry-linked contribution where appropriate, Marketplace-linked contributor recognition where appropriate, or Nexus Universe recognition where appropriate.

7.5.7.2 Non-financial default shall not prevent lawful stipends, honoraria, travel support, accessibility support, equipment access, cloud credits, compute access, or other lawful support where properly recorded and boundary-controlled.

7.5.7.3 Non-financial recognition shall not be used to extract unfair labor or avoid payment where work should be contracted, employed, or otherwise compensated.

### 7.5.8 Bounty Labor Boundary.

7.5.8.1 Each bounty shall include a labor boundary notice identifying whether the bounty is volunteer, learning, recognition-supported, stipend-supported, honorarium-supported, contracted, or otherwise structured. The notice shall explain that participation does not create employment by implication unless separately and lawfully recorded.

7.5.8.2 Bounty design shall consider work control, duration, compensation, dependency, supervision, beneficiary, output ownership, legal context, safety risks, and whether the work substitutes for regular paid labor.

7.5.8.3 Bounty structures shall not be used to disguise employment, avoid worker protections, impose unsafe work, extract unpaid operational labor, or transfer execution responsibility to contributors.

### 7.5.9 Bounty Correction.

7.5.9.1 Bounty outputs shall remain correctable. Correction may include revision, amendment, rejection, withdrawal, downgrade, suspension, recall, public-safe notice, Registry update, Marketplace update, Report correction, Studio restriction, Grid correction, TRL correction, handoff recall, archive, or non-continuation.

7.5.9.2 Where a bounty output has been integrated into a larger build, correction shall propagate to the parent build and all downstream records affected by the bounty output.

### 7.5.10 Bounty Archive.

7.5.10.1 Bounty Archive records shall preserve bounty scope, contributor record, support status, review status, acceptance status, correction history, integration status, release class, support class, and archive-not-current notice where applicable.

7.5.10.2 Bounty Archives may support contributor learning, iCRS records, ILA records, institutional memory, correction analysis, and successor bounties. Archived bounty records shall not be treated as current approval, certification, employment status, procurement qualification, financeability, insurance approval, deployment authorization, or execution.

## 7.6 Build Architecture

### 7.6.1 Public-Good Software Builds.

7.6.1.1 Public-Good Software Builds shall include repositories, libraries, services, applications, dashboards, APIs, SDKs, connectors, adapters, command-line tools, notebooks, templates, infrastructure-as-code, test suites, reference implementations, model evaluation tools, data tooling, Studio components, Marketplace components, Registry components, Reports components, Campaign components, Academy components, DICE tools, GRIx tools, DRI tools, Observatory tools, Rails tools, Network tools, and National Node tools.

7.6.1.2 Public-Good Software Builds shall include repository stewardship, licensing, contribution rules, maintainer assignment, code review, dependency scanning, secret scanning, SBOM records where appropriate, vulnerability disclosure, documentation, accessibility review, release notes, support class, release class, Registry record, Marketplace eligibility, correction pathway, deprecation rule, and archive rule.

7.6.1.3 Public-Good Software Builds shall not create warranty, security certification, AI safety approval, procurement recommendation, provider validation, public authority approval, financeability, insurance approval, deployment authorization, or execution.

### 7.6.2 Data Pipeline Builds.

7.6.2.1 Data Pipeline Builds shall include ingestion, transformation, validation, metadata creation, lineage capture, quality assessment, public-safe transformation, aggregation, synthetic data generation where appropriate, compute-to-data workflows, DICE routing, DRI data flows, Observatory data flows, Studio data flows, National Portfolio data flows, Reports data flows, Registry metadata flows, Marketplace metadata flows, Grid and TRL evidence flows, and handoff data context.

7.6.2.2 Data Pipeline Builds shall require data rights review, sensitivity classification, data-use labels, AI-use labels, privacy review, cyber review, cross-border review, data sovereignty review, public authority-sensitive review where applicable, community-sensitive review where applicable, Indigenous protocol-sensitive review where applicable, protected knowledge review, public-safe release review, correction pathway, and archive rule.

7.6.2.3 Data Pipeline Builds shall not create data ownership, data rights, publication permission, AI training permission, public authority approval, handoff permission, deployment authorization, or execution.

### 7.6.3 Dashboard Builds.

7.6.3.1 Dashboard Builds shall include Docket dashboards, National Portfolio dashboards, Foundry dashboards, Campaign dashboards, Academy dashboards, Reports dashboards, Marketplace dashboards, Registry dashboards, DICE dashboards, GRIx dashboards, DRI dashboards, Observatory dashboards, Studio dashboards, Grid dashboards, TRL dashboards, Nexus Universe dashboards, correction dashboards, archive dashboards, and handoff dependency dashboards.

7.6.3.2 Dashboard Builds shall include source notes, data status, update cadence, uncertainty labels where applicable, confidence labels where applicable, limitations, public-safe notices, sensitive location controls, accessibility review, localization, correction pathway, and archive rule.

7.6.3.3 Dashboard Builds shall not create decisions, ratings, rankings by default, public warnings, insurance scores, investment signals, procurement scores, public authority actions, operational commands, deployment authorization, or execution.

### 7.6.4 Studio Workflow Builds.

7.6.4.1 Studio Workflow Builds shall include controlled workflows for dashboards, digital twins, simulations, scenarios, AI workflow review, data-room workflows, secure-room workflows, public authority learning, readiness rooms, capital-reader rooms, insurance-reader rooms, donor-reader rooms, public finance learning rooms, Nexus Universe workflows, and handoff demonstrations.

7.6.4.2 Studio Workflow Builds shall include access controls, role permissions, data classification, AI-use labels, no-write-back rules, no-command rules, output review, logging, public-safe restrictions, safeguard controls, shutdown triggers, correction triggers, and archive rules.

7.6.4.3 Studio Workflow Builds shall not create operational command, public authority decision, finance approval, insurance approval, donor commitment, procurement status, certification, deployment authorization, or execution.

### 7.6.5 Marketplace Object Builds.

7.6.5.1 Marketplace Object Builds shall prepare discoverable public-good objects for Nexus Marketplace, including software listings, data listings, model listings, API listings, dashboard listings, Studio workflow listings, learning object listings, Report listings, Campaign listings, Foundry object listings, National Portfolio listings, Grid and TRL object listings, Nexus Universe object listings, and handoff context listings.

7.6.5.2 Marketplace Object Builds shall include metadata, description, version, steward, license, access class, support class, review status, Registry status, public-safe status, correction pathway, boundary notices, provider-neutrality review, sponsor-boundary review, procurement-neutrality review, finance-boundary review, and archive rule.

7.6.5.3 Marketplace Object Builds shall not create endorsement, procurement recommendation, provider validation, certification, financeability, insurance approval, public authority approval, deployment authorization, or execution.

### 7.6.6 Registry Record Builds.

7.6.6.1 Registry Record Builds shall create or update status-truth records for Foundry objects, including object identity, lifecycle state, version, steward, contributors, maintainers, review status, data-use label, AI-use label, license status, support class, release class, provider contribution records, sponsor support records, public authority participation records where applicable, correction records, withdrawal records, recall records, archive records, and non-continuation records.

7.6.6.2 Registry Record Builds shall preserve validity by record and shall prevent status overclaim. Registry fields shall be clear, bounded, versioned, correctable, and linked to evidence where appropriate.

7.6.6.3 Registry Record Builds shall not create certification, approval, provider validation, procurement status, financeability, insurance approval, public authority approval, consent, deployment authorization, or execution.

### 7.6.7 Grid Input Builds.

7.6.7.1 Grid Input Builds shall prepare bounded evidence inputs for Nexus Grid, including evidence sufficiency, method quality, data status, AI-use status, cyber status, privacy status, public-safe status, safeguard status, support status, repository status, Marketplace status, Registry status, Studio status, National Portfolio status, Nexus Universe status, and handoff dependency status.

7.6.7.2 Grid Input Builds shall include source basis, scope, limitations, review status, unresolved issues, correction pathway, downgrade triggers, suspension triggers, withdrawal triggers, reinstatement conditions, and archive rules.

7.6.7.3 Grid Input Builds shall not create maturity certification, procurement readiness, financeability, insurability, public authority approval, deployment authorization, or execution.

### 7.6.8 TRL Evidence Builds.

7.6.8.1 TRL Evidence Builds shall prepare evidence notes relating to TRL 1 through TRL 10 within the Nexus context. Such builds shall identify the technology or capability, evidence basis, environment, validation context, operational relevance, competent actor role where applicable, support status, limitations, assumptions, dependencies, public-safe status, safeguard status, and correction pathway.

7.6.8.2 TRL Evidence Builds shall preserve the rule that TRL is bounded evidence, not certification. TRL notes may support learning, readiness discussion, Studio review, Reports, Marketplace discovery, Registry status, Nexus Universe preparation, National Portfolio memory, and handoff dependency packages.

7.6.8.3 TRL Evidence Builds shall not create procurement readiness, financeability, insurability, public authority approval, deployment authorization, or execution.

### 7.6.9 National Portfolio Builds.

7.6.9.1 National Portfolio Builds shall produce National Context Records, National Systems-Risk Maps, National Challenge Briefs, Evidence Need Records, Observatory Need Records, Core Build Requests, Safeguard Records, Public Authority Learning Records, Readiness Question Records, Competence Cell Workplans, Universe Arena Routing Records, National Portfolio dashboards, National Portfolio Reports, National Registry records, National Marketplace objects, Grid inputs, TRL notes, and handoff dependency packages.

7.6.9.2 National Portfolio Builds shall preserve national ownership, localization, data sovereignty, public authority boundaries, community safeguards, Indigenous protocols where applicable, sponsor/provider boundaries, finance-readiness boundaries, procurement neutrality, public-safe reporting, correction, and archive.

7.6.9.3 National Portfolio Builds shall not create country rankings, government approval, procurement plans, financeability, insurance approval, consent, deployment authorization, or execution.

### 7.6.10 Reports Builds.

7.6.10.1 Reports Builds shall produce public-safe knowledge products, technical notes, National Portfolio Reports, WFEH-B Reports, DRR Reports, DRF Reports, DRI Reports, DICE Reports, GRIx Reports, Observatory Reports, Foundry Reports, Campaign Reports, Academy Reports, Labs Reports, Risk Agency Reports, Nexus Universe Reports, Grid and TRL Reports, handoff context notes, correction reports, and archive reports.

7.6.10.2 Reports Builds shall include evidence basis, method notes, data availability statement, AI-use statement, public-safe abstract, protected knowledge controls, sensitive geospatial controls, licensing, repository package where applicable, DOI or repository identifier where applicable, correction pathway, withdrawal pathway, and archive rule.

7.6.10.3 Reports Builds shall not create public warning, public authority approval, certification, procurement recommendation, financeability, insurance approval, country ranking, consent, deployment authorization, or execution.

### 7.6.11 Campaign Builds.

7.6.11.1 Campaign Builds shall produce Campaign pages, Campaign records, public-safe messages, signature tools, pledge tools, support tools where lawful, volunteer pathways, team and chapter tools, ambassador materials, Campaign dashboards, Campaign Reports, Support Ledgers, Campaign-to-Academy routes, Campaign-to-Foundry routes, Campaign-to-National Portfolio routes, Campaign-to-Universe routes, and Campaign correction channels.

7.6.11.2 Campaign Builds shall include public-safe review, trust and safety review, fraud controls, data controls, youth safeguards where applicable, community consent boundary controls, Indigenous protocol controls where applicable, sponsor controls, provider controls, support controls, claims freeze triggers, data freeze triggers, technical freeze triggers, stop-the-line triggers, correction pathway, and archive rule.

7.6.11.3 Campaign Builds shall not create public mandate, vote, public authority approval, finance commitment, donor commitment, procurement commitment, endorsement, consent, deployment authorization, or execution.

### 7.6.12 Handoff Dependency Builds.

7.6.12.1 Handoff Dependency Builds shall produce structured packages for competent lawful actors. Packages may include evidence context, data context, method context, software 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, support status, recipient responsibilities, correction pathway, recall pathway, and archive rule.

7.6.12.2 Handoff Dependency Builds shall be subject to handoff gate review and shall carry explicit no-authorization, no-finance, no-insurance, no-procurement, no-certification, no-consent, no-deployment, and no-execution notices unless a separate competent authority or lawful actor records otherwise outside NAF.

7.6.12.3 Handoff Dependency Builds shall not themselves authorize handoff, implementation, procurement, finance, insurance, certification, consent, deployment, operation, command, or execution.

## 7.7 Maintainer System

### 7.7.1 Maintainer Roles.

7.7.1.1 Maintainer Roles shall define who is responsible for continuity, review coordination, issue handling, correction, release management, support classification, deprecation, withdrawal, recall, archive, and successor routing for a Foundry object or object family. Roles may include repository maintainer, data maintainer, model maintainer, ontology maintainer, API maintainer, dashboard maintainer, Studio workflow maintainer, Report maintainer, Campaign maintainer, Academy object maintainer, Marketplace listing maintainer, Registry record maintainer, Grid input maintainer, TRL note maintainer, National Portfolio maintainer, public-safe release maintainer, security maintainer, safeguard maintainer, handoff dependency maintainer, and archive maintainer.

7.7.1.2 Maintainer Roles shall be recorded with scope, authority limits, review duties, support class, conflict disclosures, sponsor/provider relationship if any, escalation pathways, correction duties, replacement rules, and archive duties.

7.7.1.3 Maintainer role shall not create ownership, employment, certification authority, public authority status, procurement authority, finance authority, insurance authority, consent authority, deployment authority, or execution authority by implication.

### 7.7.2 Maintainer Standing.

7.7.2.1 Maintainer Standing is the recorded status of a maintainer within a defined Foundry scope. Standing may be provisional, active, limited, suspended, downgraded, withdrawn, retired, archived, or reinstated.

7.7.2.2 Standing shall be based on competence, contribution history, review quality, conflict status, reliability, public-safe discipline, data and AI discipline, cyber and privacy discipline, safeguard discipline, correction responsiveness, and adherence to Nexus boundaries.

7.7.2.3 Maintainer Standing shall not constitute professional license, public authority recognition, certification, procurement qualification, provider validation, or employment status by default.

### 7.7.3 Maintainer Review.

7.7.3.1 Maintainers shall be periodically reviewed for performance, conflict status, correction responsiveness, support capacity, release discipline, public-safe discipline, security responsiveness, safeguard responsiveness, contributor treatment, documentation quality, and archive discipline.

7.7.3.2 Maintainer Review may result in renewal, limitation, downgrade, suspension, removal, replacement, retraining, additional oversight, correction, or archive of maintainer role.

7.7.3.3 Maintainer Review shall be a governance record, not a public ranking, professional certification, employment evaluation by default, or legal determination.

### 7.7.4 Maintainer Conflicts.

7.7.4.1 Maintainer Conflicts may be actual, potential, perceived, financial, institutional, personal, professional, political, sponsor-related, provider-related, capital-related, public authority-related, research-related, or role-based. Maintainers shall disclose conflicts and shall comply with recusal, limitation, additional review, or removal rules where required.

7.7.4.2 Maintainer Conflicts shall be recorded where material to object integrity, review integrity, public-safe reporting, provider neutrality, sponsor boundaries, procurement neutrality, finance-readiness boundaries, public authority boundaries, safeguards, or handoff dependencies.

7.7.4.3 Conflict disclosure shall not automatically disqualify a maintainer, but unmanaged conflict shall trigger correction, limitation, suspension, or removal where necessary.

### 7.7.5 Maintainer Renewal.

7.7.5.1 Maintainer Renewal shall confirm that a maintainer remains suitable for a defined scope. Renewal shall consider performance, current competence, support capacity, conflicts, public-safe record, correction record, contributor feedback, security record, safeguard record, and object needs.

7.7.5.2 Renewal may be full, limited, conditional, time-limited, or denied. Renewal records shall include scope, conditions, review date, next review date, and correction obligations.

### 7.7.6 Maintainer Downgrade.

7.7.6.1 Maintainer Downgrade may occur where a maintainer’s scope should be reduced due to capacity, quality, conflict, conduct, delayed correction, outdated expertise, security concerns, safeguard concerns, public-safe concerns, or boundary mismanagement.

7.7.6.2 Downgrade shall be recorded with reason, scope change, affected objects, transition plan, correction needs, and archive implications.

7.7.6.3 Downgrade shall not be treated as punitive where it is a reasonable lifecycle adjustment, but it shall protect object integrity and public trust.

### 7.7.7 Maintainer Removal.

7.7.7.1 Maintainer Removal may occur where continued maintainer status would threaten object integrity, public-safe discipline, security, privacy, safeguards, correctionability, role separation, sponsor/provider neutrality, finance/procurement boundaries, public authority boundaries, contributor safety, or trust.

7.7.7.2 Removal shall be recorded with reason, effective date, affected objects, successor maintainer, access revocation where applicable, correction needs, public-safe notice where applicable, and archive rule.

7.7.7.3 Maintainer Removal shall not determine professional licensing, employment status, legal liability, or public authority status unless separately and lawfully determined by competent actors.

### 7.7.8 Maintainer Archive.

7.7.8.1 Maintainer Archive shall preserve historical maintainer records, including scope, term, contributions, review records, conflicts, support class, corrections, downgrades, removals, renewals, successor links, and archive-not-current notices.

7.7.8.2 Maintainer Archive shall support institutional memory, contributor recognition, correction analysis, and succession planning without creating current authority.

## 7.8 Foundry Quality Gates

### 7.8.1 Intake Gate.

7.8.1.1 The Intake Gate shall determine whether a proposed Foundry item has sufficient purpose, scope, source information, Docket linkage, portfolio linkage, output class, steward, contributor pathway, data classification, AI-use classification, public-safe classification, safeguard classification, support expectation, boundary notices, and correction pathway to enter Foundry.

7.8.1.2 Items that lack purpose, scope, lawful basis, public-good relevance, national routing where required, safeguard clarity, data rights clarity, or boundary discipline shall be returned, revised, restricted, escalated, or rejected.

7.8.1.3 Passing the Intake Gate shall not imply approval, certification, financeability, procurement readiness, public authority action, consent, deployment authorization, or execution.

### 7.8.2 Evidence Gate.

7.8.2.1 The Evidence Gate shall review whether a Foundry item has adequate evidence basis for its proposed lifecycle stage. It shall consider source quality, method quality, assumptions, dependencies, uncertainty, confidence where applicable, reproducibility, limitations, review status, public-safe status, and correction pathway.

7.8.2.2 Where evidence is insufficient, the item shall be routed to Research Quests, Evidence Quests, Labs Streams, Reports review, Studio review, Grid review, TRL note preparation, or correction.

7.8.2.3 Passing the Evidence Gate shall not create factual certainty, certification, public authority approval, financeability, insurance approval, procurement readiness, deployment authorization, or execution.

### 7.8.3 Data Gate.

7.8.3.1 The Data Gate shall review data rights, data classification, data-use labels, AI-use labels, metadata, lineage, data quality, privacy status, cross-border transfer issues, data sovereignty, public authority-sensitive status, community-sensitive status, Indigenous protocol-sensitive status where applicable, protected knowledge status, cyber-sensitive status, infrastructure-sensitive status, geospatial-sensitive status, retention, deletion, sealing, public-safe transformation, and archive rules.

7.8.3.2 The Data Gate may require secure-room routing, data-room routing, clean-room routing, compute-to-data routing, metadata-only release, public-safe transformation, access restriction, or stop-the-line.

7.8.3.3 Passing the Data Gate shall not create data ownership, unrestricted data rights, AI training permission, public authority approval, handoff permission, deployment authorization, or execution.

### 7.8.4 AI-Use Gate.

7.8.4.1 The AI-Use Gate shall review AI-use labels, model cards, system cards, benchmark cards, agent workflow cards, retrieval controls, human review requirements, prompt-injection controls, tool permissions, agentic workflow restrictions, bias and harm review, data leakage risks, prohibited uses, output classification, AI incident response, and correction pathways.

7.8.4.2 The AI-Use Gate may restrict AI use to no-AI use, retrieval-only, summarization with review, classification with review, evaluation-only, secure-room AI only, public-safe AI output only, or other controlled use classes.

7.8.4.3 Passing the AI-Use Gate shall not create AI safety certification, automated decision authority, public authority decision, professional competence certification, deployment authorization, or execution.

### 7.8.5 Cyber Gate.

7.8.5.1 The Cyber Gate shall review identity and access controls, least privilege, secure repositories, secret scanning, dependency scanning, SBOM records where appropriate, vulnerability disclosure, threat modeling, secure defaults, cyber-sensitive disclosure, incident response, logging, backup, recovery, and public-safe cyber reporting.

7.8.5.2 The Cyber Gate may require remediation, restricted release, secure-room routing, vulnerability embargo, public-safe transformation, marketplace delay, registry warning, withdrawal, recall, or archive.

7.8.5.3 Passing the Cyber Gate shall not create security certification, warranty, compliance determination, public authority approval, operational command, deployment authorization, or execution.

### 7.8.6 Public-Safe Gate.

7.8.6.1 The Public-Safe Gate shall review whether a Foundry output may be released publicly, released in controlled form, summarized, restricted, delayed, transformed, or withheld. It shall assess overclaim, false certainty, warning language, approval language, finance language, procurement language, certification language, consent language, execution language, sensitive geospatial disclosure, protected knowledge disclosure, cyber-sensitive disclosure, sponsor/provider promotional risk, public confusion, and correction readiness.

7.8.6.2 The Public-Safe Gate may assign or modify release class, require public-safe summary, require controlled public release, require data-room-only release, require secure-room-only release, require handoff-recipient-only release, require correction notice, or require archive.

7.8.6.3 Passing the Public-Safe Gate shall not create public warning authority, media approval, legal clearance by default, certification, public authority approval, financeability, procurement status, consent, deployment authorization, or execution.

### 7.8.7 Safeguard Gate.

7.8.7.1 The Safeguard Gate shall review community safeguards, Indigenous protocols where applicable, protected knowledge, youth safeguards, disability inclusion, accessibility, humanitarian sensitivity, conflict sensitivity, rights concerns, non-extractive engagement, community-facing correction, and safeguard stop-the-line triggers.

7.8.7.2 The Safeguard Gate may require restriction, redesign, additional engagement, protected knowledge removal, geospatial masking, public-safe transformation, access control, Campaign modification, Studio restriction, Report restriction, Marketplace delisting, Registry update, handoff condition, correction, withdrawal, recall, or archive.

7.8.7.3 Passing the Safeguard Gate shall not grant community consent, Indigenous consent, legal permission, land access, protected knowledge permission, public authority approval, deployment authorization, or execution.

### 7.8.8 Marketplace Gate.

7.8.8.1 The Marketplace Gate shall review whether a Foundry object is eligible for Marketplace listing. It shall examine object identity, metadata quality, Registry linkage, version, steward, license, access class, support class, public-safe status, review status, provider-neutrality status, sponsor-boundary status, procurement-neutrality status, finance-boundary status, correction pathway, and archive rule.

7.8.8.2 Marketplace Gate approval for listing shall not imply endorsement, validation, certification, procurement recommendation, financeability, insurance approval, public authority approval, deployment authorization, or execution.

### 7.8.9 Registry Gate.

7.8.9.1 The Registry Gate shall review whether a Foundry object has sufficient status-truth information for Registry recording. It shall examine object identity, lifecycle state, version, steward, source pathway, review status, data-use label, AI-use label, support class, release class, provider contribution records, sponsor support records, public authority participation records where applicable, correction records, withdrawal rules, recall rules, archive rules, and non-continuation status.

7.8.9.2 Registry Gate completion shall preserve truth of status and shall not create certification, approval, procurement status, provider validation, financeability, insurance approval, public authority approval, consent, deployment authorization, or execution.

### 7.8.10 Grid and TRL Gate.

7.8.10.1 The Grid and TRL Gate shall review whether a Foundry object may be routed into Nexus Grid or assigned TRL evidence notes. It shall assess evidence sufficiency, method quality, data status, AI-use status, cyber status, privacy status, public-safe status, safeguard status, support status, repository status, Marketplace status, Registry status, Studio status, National Portfolio status, Nexus Universe status, and handoff dependency status.

7.8.10.2 Grid and TRL Gate records shall include limitations, downgrade triggers, suspension triggers, withdrawal triggers, reinstatement conditions, correction pathway, and archive rule.

7.8.10.3 Passing the Grid and TRL Gate shall not create maturity certification, technology certification, procurement readiness, financeability, insurability, public authority approval, deployment authorization, or execution.

### 7.8.11 Release Gate.

7.8.11.1 The Release Gate shall determine whether a Foundry object may move from draft, internal review, sandbox, Studio-only, secure-room-only, data-room-only, controlled public, public-safe summary, open public, Marketplace candidate, Registry-recorded, Nexus Universe-ready, handoff-recipient-only, archived, or non-continuing status.

7.8.11.2 The Release Gate shall confirm that applicable evidence, data, AI, cyber, privacy, public-safe, safeguard, marketplace, registry, Grid, TRL, national routing, and handoff requirements have been satisfied for the chosen release class.

7.8.11.3 Release shall not create certification, warranty, procurement status, financeability, insurance approval, public authority approval, consent, deployment authorization, or execution.

### 7.8.12 Handoff Gate.

7.8.12.1 The Handoff Gate shall review whether a Foundry object may be included in a lawful handoff dependency package. It shall review evidence context, data context, method context, software 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, and archive rule.

7.8.12.2 The Handoff Gate shall ensure that the package transfers dependencies and context only. It shall include no-authorization, no-certification, no-procurement, no-finance, no-insurance, no-public-authority, no-consent, no-deployment, and no-execution notices unless a competent lawful actor has separately recorded otherwise outside NAF.

7.8.12.3 Passing the Handoff Gate shall not authorize implementation, recipient action, procurement, finance, insurance, certification, public authority approval, consent, deployment, operation, command, or execution. The final Foundry rule of Part VII is that Foundry builds public-good capability at speed and scale only by preserving records, review, release classes, support classes, correction, archive, and lawful handoff boundaries; no Foundry Program, Track, Quest, Bounty, Build, Maintainer role, Quality Gate, Release Class, Marketplace object, Registry record, Grid input, TRL note, Nexus Universe output, or handoff dependency package shall become authority, certification, procurement, finance, insurance, public warning, consent, deployment, operation, command, employment, agency, or execution by implication.


---

# 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/nexus-agile-framework-naf/vii.-foundry.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.