> For the complete documentation index, see [llms.txt](https://docs.therisk.global/organization/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.therisk.global/organization/systems/nxs-fac.md). # NXS-FAC NXS-FAC, the blueprints, builds, verification, signing and assembly system of the Nexus ecosystem: purpose, rooms, inputs and outputs, areas, standards and boundaries. {% hint style="info" %} This page is generated from the twenty-system charters, the system profiles, the interface and authority registers, the room register, the areas of work, the systems article of the constitution set and the programme spine. Do not edit it in GitBook: change the source and export again. {% endhint %} **NXS-FAC** is one of the twenty systems of the Nexus ecosystem: the blueprints, builds, verification, signing and assembly system. It is described here as a system of the ecosystem, with its purpose, its rooms, what it receives and provides, the areas it serves, the standards that apply and its boundaries. Earlier pages may use the retired name `Nexus Factory`. ## Purpose and context Artifact/blueprint production (never runtime). The signing act: build, attest and request a signature through a scoped signer identity; holds no key material (ADR 0138). Its domain is engineering builds, verified artifacts, signing and release candidates. A typical setting is a coordinated software and analytical-artifact release with reproducible evidence. ## What it is the authority for It is the single owner of these fact families; any other system that needs them reads them from NXS-FAC: build signing authority. | Record | What the system must keep | | ------------------ | ------------------------------------------------------------------------ | | source snapshot | Pin commit, dependencies and generator versions. | | build contract | Declare artifact kind, environment and reproducibility envelope. | | verification suite | Separate required checks from advisory checks and record actual results. | | artifact digest | Approve the exact artifact, not a mutable branch name. | | signing authority | Keep signing and promotion credentials outside the room/browser. | ## Rooms and areas of work Every system has ten rooms: eight shared rooms, which work the same way across systems with this system's domain, and two specialist rooms. | Room | Kind | Purpose | | --------- | ---------- | ----------------------------------------------------------------------------------------------------------------------------------------------- | | Station | Shared | The system's home: posture of the system's own records, freshness, refusals and next actions; never a summary of another system's truth | | Mission | Shared | Mission and task work for the system's domain, linked to Universe missions and Project OS plans | | Builder | Shared | Composition of the system's artifacts and configurations from admitted packages (NXS-STU, NXS-FAC and NXS-NXQ boundaries apply) | | Maps | Shared | Spatial views of the system's records and NXS-GRX products, under the boundary licence gate | | Data | Shared | The system's datasets, sources and lineage as NXS-GRX products or system-owned records | | Commons | Shared | Shared methods, standards, templates and reusable artifacts, including Nexus Standards (NXS, a programme of the Nexus Consortium) participation | | Reports | Shared | Reports and editions built from the system's evidence, with cutoffs and correction history | | Knowledge | Shared | Institutional knowledge, records, runbooks and learning linked to NXS-HUB | | Builds | Specialist | Records: build contract, build execution, build artifact, verification result, reproducibility assessment | | Releases | Specialist | Records: release candidate, release gate assessment, signing request, release bundle, promotion record | **Kinds of work it carries:** Build pipelines; Release trains; Verified Build; Application Package; Container/Artifact; SBOM/Provenance Bundle; Release Candidate; Software delivery pipeline estates; Monorepo build programmes; Verified build programmes; Application packaging programmes; Release candidate qualification; Hotfix and patch programmes; Supply-chain provenance programmes; SBOM and vulnerability watch programmes; Artefact signing programmes; Open-source licence compliance; Test automation programmes; Build reliability and flaky-test remediation; Secure development and scanning programmes; Accessibility verification programmes; Container image factories; Model artefact pipelines; Data and science pipeline packaging; Edge and offline package production; Map and tile package pipelines; Legacy modernisation programmes; Governed AI-assisted engineering. **This system in the Nexus model.** Generated from the Nexus Standards index and the programme spine; statuses are registry statuses, never adoption or certification. | | | | -------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Descriptor | Blueprints, builds, verification, signing and assembly | | In the programme | Built, simulated and prepared in the [Foundry pillar](/organization/programme/foundry.md); its records serve the other pillars through the handoffs of [the programme year](/organization/programme/the-programme-year.md), and the competent authority decides outside the programme. | | System profile | [NRS-S16](https://nexustandards.com/standards/nrs/#nrs-s16): NXS-FAC (Blueprints, builds and signing) (status OPEN) | | Nexus Risk Standards that apply | 7 in 3 series: ai-native: [NRS-A4](https://nexustandards.com/standards/nrs/#nrs-a4), [NRS-A5](https://nexustandards.com/standards/nrs/#nrs-a5), [NRS-A6](https://nexustandards.com/standards/nrs/#nrs-a6); system: [NRS-S0](https://nexustandards.com/standards/nrs/#nrs-s0), [NRS-S16](https://nexustandards.com/standards/nrs/#nrs-s16); technology: [NRS-T8](https://nexustandards.com/standards/nrs/#nrs-t8), [NRS-T11](https://nexustandards.com/standards/nrs/#nrs-t11) | | Nexus Reports technology streams | SFW Software and supply-chain integrity | ## Inputs What it receives, and from whom. Each interface carries its context (estate, tenant, workspace, purpose, jurisdiction, time and place) and is checked under the policy authority. | From | What it receives | | ------------------------------------------- | -------------------------------------- | | [NXS-LAB](/organization/systems/nxs-lab.md) | validated experiment/candidate handoff | ## Outputs What it provides, and to whom. Consumers read projections; the system stays the authority for its own records and their corrections. | To | What it provides | | ------------------------------------------- | --------------------------------------- | | [NXS-NXQ](/organization/systems/nxs-nxq.md) | signed package release/admission | | [NXS-NSF](/organization/systems/nxs-nsf.md) | authorization/policy evaluation request | | the evidence fabric | append consequential receipt/evidence | ## Interfaces with other systems Beyond its interfaces, it relies on fact families owned elsewhere: application lifecycle ([NXS-APP](/organization/systems/nxs-app.md)); agentic intelligence fabric ([NXS-STU](/organization/systems/nxs-stu.md)); trust root and key custody ([NXS-NSF](/organization/systems/nxs-nsf.md)); capability and package registry ([NXS-NXQ](/organization/systems/nxs-nxq.md)). ## Areas it serves | Area | Category | What the area covers | | -------------------------------------------------- | ---------- | --------------------------------------------------- | | [Cyber resilience](/organization/systems/areas.md) | Technology | Cyber risk to essential services and public systems | ## Standards that apply Every record of the system is identified through the UNI identifier fabric of Nexus Standards (NS-1), and its public name follows the Nexus Standards naming rules. The areas it serves reference these external standards; naming a standard records where it is referenced and is not a claim of certification, accreditation, conformance or endorsement. | Standard | Issuer | Year | Use | | ----------------------------------------------------- | ------------------------------------------------------------------- | ---- | --------------------------------------------------- | | Cybersecurity Framework 2.0 | United States National Institute of Standards and Technology (NIST) | 2024 | Govern, identify, protect, detect, respond, recover | | ISO/IEC 27001 Information security management systems | ISO/IEC | 2022 | Security management requirements | | NIS2 Directive, Directive (EU) 2022/2555 | European Union | 2022 | Obligations for essential entities in the EU | ## Governance boundaries Policy authority for the system sits with [NXS-NSF](/organization/systems/nxs-nsf.md); identifiers come from the UNI identifier fabric. The system exports read projections and commands through typed contracts, and no other system writes its records. It does not own, and never stands in for: * private key material (held by KMS/HSM in the sovereignty cell) * trust-root and key policy (NXS-NSF) * runtime (Apps) * configuration (Studio) **Method boundary.** Reproducibility requires pinned inputs, declared nondeterminism and independent rebuild comparisons. Passing a fixture test is not production qualification or evidence of external effect. Do not treat a signed build or release candidate as permission to deploy to production. [All twenty systems](/organization/systems.md) ยท [Areas](/organization/systems/areas.md) *** *Generated page. It records names, roles and design for reading, not readiness: release is on hold, and nothing here is presented as ready, certified or official.* --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.therisk.global/organization/systems/nxs-fac.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. 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.