Nexus Foundry
Nexus Foundry: governed self-service
Foundry is the governance and self-service module of the platform. It publishes a governed catalog, captures requests through guided wizards, applies policy and cost checks, routes multi-stage approvals and provisions through Nexus with a full audit record.
Request to provisioned service
Fulfilment is not a separate tool. It is a Nexus workflow, which is why the approval and the provisioning share one record.
- of governed service
- 5 classesof governed service
- multi-stage approvals
- Policy-drivenmulti-stage approvals
- before approval
- Cost shownbefore approval
- adoption by department
- Measureadoption by department
Operation
A module of the platform, not a second product to integrate.
Foundry governs services that are delivered through Nexus and the infrastructure integrations Nexus already has. That is what keeps the catalog honest: an item can only be published if there is a workflow that can fulfil it.
A catalog on its own
A form that creates a ticket
- Requests are captured, then fulfilled by hand elsewhere
- Approvals live in a different system to the work
- Cost appears after the fact, if at all
- The catalog drifts from what is actually supported
- Evidence is spread across tools
Foundry on Nexus
A catalog wired to execution
- Each item is backed by a workflow that provisions it
- Approvals are nodes inside that execution
- Estimated cost is shown before submission and approval
- Options are limited to what the owner supports
- Request, approval and provisioning share one record
Governed catalog
Five classes of service, published under the same controls.
Organizations rarely need one catalog for infrastructure and another for applications, workflows and AI. Publishing them together is what makes entitlement and approval consistent.
Infrastructure services
Compute, storage, networking and cluster resources published as requestable items with defined sizes, regions and constraints rather than as a ticket asking for capacity.
Platform services
Databases, message brokers, runtimes and shared platform capabilities offered with the configuration options a service owner is willing to support.
Application services
Business applications, environments and access packages that teams need in order to work, published with their own approval and provisioning path.
Workflows
Automations built on Nexus published as catalog items, so a governed process can be requested and run by the people who need it without being rebuilt locally.
AI agents
Agents and AI-assisted capabilities published with their permitted scope, so their use is requested, approved and recorded like any other service.
Deployment and trust
The catalog runs inside the same boundary as the services it governs.
Foundry inherits the platform deployment, identity, secret handling and audit model. Its authority is limited to the workflows and integrations the organisation configures.
Deployment
On premises, private cloud, sovereign cloud or air-gapped with Nexus.
Identity
SSO, MFA and role-based entitlement govern catalog visibility, request and approval.
Secrets
Provisioning credentials remain in vault-backed storage and are resolved at execution time.
Evidence
Request, version, cost estimate, approvals, actions and results remain connected.
The flow
Publish, request, validate, approve, provision, audit.
Each stage produces something the next one depends on, which is why the record at the end is complete rather than assembled afterwards.
- Stage 01
Publish
A service owner publishes an item
The owner defines options, constraints, cost basis, required approvals and the Nexus workflow that will fulfil the request.
- Stage 02
Request
A user requests it through a wizard
A guided form collects only what the service needs, validating input as it goes rather than accepting free text that has to be clarified later.
- Stage 03
Validate
Policy and cost are checked
Entitlement, quota, environment rules and configuration policy are evaluated, and the estimated cost is shown before the request is submitted.
- Stage 04
Approve
Multi-stage approval runs
The request routes to the approvers the policy requires, in order, with reviewer context and a recorded reason for each decision.
- Stage 05
Provision and audit
Nexus fulfils and records the work
An approved request runs as a Nexus workflow. The request, approvals, provisioning steps and result are retained as one execution record.
- Stage 06
Measure
See where adoption is growing
Track which departments are requesting and using services, workflows and AI agents. Compare adoption across the organization so leaders can invest where demand is proven, investigate low-usage areas, and identify where additional enablement or training may be needed.
Questions
Foundry scope, operation and boundaries.
Capabilities
What Foundry provides.
The capabilities below exist to make self-service safe enough that platform teams are willing to open it up.
Guided request wizards
Requests are captured through structured forms with validation, dependent options and sensible defaults. The service owner decides what a requester may choose, which prevents unsupported combinations from reaching provisioning.
Cost visibility at request time
Estimated cost is shown against the options selected, before submission and before approval. Approvers see the same figure the requester saw, which makes the financial consequence part of the decision rather than a later surprise.
Policy-driven approvals
Approval routing follows policy: value thresholds, environment, data classification, requesting team and service type can each change who has to approve and in what order. Stages run in sequence with each decision recorded.
Provisioning through Nexus
Fulfilment is a Nexus workflow, so it can span cloud APIs, Kubernetes, infrastructure as code, enterprise applications, databases and code nodes. The same request can create infrastructure, register it and update the systems that need to know.
End-to-end audit
Who requested, what was selected, what it was estimated to cost, who approved, what was provisioned and what the target systems returned are held together as a single record.
Entitlement
Catalog visibility and request rights are scoped by role, team and workspace, so users see the services they are entitled to rather than a catalog they must filter mentally.
Lifecycle
Entitlement and lifecycle management.
A catalog is only useful for as long as it reflects reality. Ownership, revisions and decommission paths are what keep it accurate.
Ownership is explicit
Every catalog item has an owner responsible for its options, constraints and fulfilment workflow, which keeps the catalog maintained rather than gradually abandoned.
Versions and revisions
Catalog items change through revisions. What was requested can be explained against the version that was published at the time.
Entitlement changes
Access to request a service follows role and team membership, so movers and leavers do not leave standing entitlement behind them.
Change and decommission
Modification and decommission are catalog actions with their own approval path, so removing a service is as governed as creating one.
Environment scope
The same service can be offered with different options and approval requirements per environment, which keeps production stricter than development by design.
Retirement
Items can be withdrawn from the catalog without losing the record of what was provisioned through them while they were active.
Stakeholders
What each group gets.
Self-service programmes usually fail because one group carries the cost and another gets the benefit. Foundry is designed around the five groups that have to agree.
Platform teams
Publish supported services once instead of fulfilling the same request by hand. Standard options replace bespoke builds, and provisioning runs through workflows the team controls.
Service owners
Define what is offered, which configurations are supported and what has to be approved, then keep that definition current through revisions.
Finance and procurement
See estimated cost at the point of request and approval, with a record of what was authorized and by whom.
Security and governance
Enforce entitlement, separation of duties and approval policy in the request path, and review a complete record afterwards.
End users
Request what they need through a guided form, see where the request stands, and receive a provisioned service rather than a ticket reference.
Where it fits
Sector-neutral, with an obvious fit where approval is mandatory.
Any organization with more demand than platform capacity benefits from a governed catalog. The fit is strongest where requests already require documented authorization.
Regulated enterprise
Where separation of duties and documented approval are control requirements, routing them through the request path removes the manual evidence collection that usually follows.
Public sector
Where authorization, budget visibility and record keeping are part of the mandate, a governed catalog delivers services without loosening those obligations.
Large platform organizations
Where a central team supports many delivery teams, publishing supported services is usually faster than answering the same request repeatedly.
Boundaries
Operating responsibilities.
Service owners publish the catalog, define approval policies and govern fulfilment through Nexus workflows.
Cost at request and approval
Foundry shows estimated cost at request and approval time. Broader cost management, optimisation and chargeback remain with your finance and platform tooling.
An owner-published internal catalog
The catalog holds services your own owners publish for internal requesters, with approval and fulfilment policies defined by your organisation.
Configured policy enforcement
Foundry enforces the policies you configure and records requests, approvals and fulfilment outcomes for your governance and audit processes.
Governs what Nexus can deliver
Foundry governs services delivered through Nexus workflows and related infrastructure integrations. Fulfilment performed entirely outside the platform stays outside the record.
Catalog design
Start with the five requests your platform team answers most often.
Those five are usually enough to prove the model: publish them as catalog items, attach the approval policy they already require, and let the provisioning run as a workflow with the record attached.