Skip to content

New service onboarding

Trigger

A new service or component needs to exist, be deployable and be operable.

Intended outcome

A service with codified infrastructure, a pipeline, environments, observability and an on-call owner.

Workflow steps and gates

Step Accountable role Activity Handover Gate
1 Cloud Architect sets the landing zone, resilience and residency constraints target platform design Resilience claims substantiated by a tested failure scenario
2 Infrastructure as Code Engineer codifies the infrastructure and its guardrails versioned modules, remote locked state, policy-as-code Applies idempotently from clean; plan reviewed before apply
3 Container Platform Engineer establishes the image build chain and base image lineage signed images with SBOM, immutable tags Non-root, no build secrets, pinned digests
4 CI/CD Platform Engineer wires the service onto the shared pipeline platform pipeline with federated identity and signed provenance No static cloud credentials in the CI system
5 Secrets and Configuration Management Engineer issues the service's credentials with a lifecycle dynamic short-lived credentials and a tested revocation path Static credentials only as a time-bound exception
6 Environment Manager provisions the non-production environments and their data environments with owners, refresh cadence and masked data No unmasked production personal data anywhere
7 GitOps and Continuous Delivery Engineer defines promotion and rollback across environments desired-state repositories and promotion model The same immutable artefact is promoted, never rebuilt
8 Observability Engineer instruments the service against its objectives dashboards and owned, actionable alerts Every alert has an owner, an action and a runbook
9 Site Reliability Engineer agrees the service objective and the error budget policy SLOs and error budget policy Exhausting the budget changes something, or the SLO is decorative
10 Application Support Analyst accepts the service into support with a runbook runbook and known-error entries A competent on-call engineer who has never seen it can follow it
11 Configuration Manager records the service, its relationships and its owner configuration items with verified relationships Owner, lifecycle status and verified-by date present
12 IT Service Owner takes end-to-end ownership of value, cost and risk service definition and service level agreement Named business contact and an agreed SLA exist

Running this workflow: operator and implementer boundary

In Claude Code or Codex CLI, use the prompt in the next section (or adapt it to your programme): it is a provider conversation request, not a shell program named after this workflow. You supply the source materials, actual owners, gate acceptance and any authorisation for changing real systems. The provider agent interprets the registered workflow stages and role contracts, calls supported tools if allowed, and returns explicit evidence and blockers. Stage completion in the diagram or metadata is not proof of a successful external tool call, an approved exception or a released system.

For consequential decisions explicitly start /layered (Claude) or $workflow-layered (Codex); this version does not force every direct/natural-language workflow invocation into Fabric. Human L0 authority remains separate, with Codex requiring the actual human to run any protected authority command in a trusted terminal. See the interaction model, layered engagement and human authority.

How to use this workflow

A practical prompt pattern is:

Apply the new-service-onboarding workflow to this situation. For each step, identify the current state, accountable role, required evidence, hand-over artefact, gate status and unresolved blocker. Do not skip a gate merely because the implementation is technically complete.

Operational interpretation

The workflow is most useful when the team keeps each hand-over explicit. The system can help generate or review the artefacts, but the accountable role and approval decision remain organisational responsibilities.