Source to contract to service¶
Perspective: enterprise buyer. This chain selects, contracts and accepts a supplier/service. For the supplier's opportunity, proposal and delivery economics, use Commercial delivery. Choose the required assurance arrangement using Methodical workflows.
Trigger¶
A capability may be sourced externally and must move from requirement/RFI/RFP through supplier selection and contract controls to implementation and accepted service.
Intended outcome¶
The selected supplier/service has evidence-backed fit, enforceable contract obligations, approved implementation and operational acceptance, with ongoing vendor governance.
Workflow steps and gates¶
| Step | Accountable role | Activity | Handover | Gate |
|---|---|---|---|---|
| 1 | Business Analyst | turns business/service need into outcome, requirement and acceptance baseline | sourcing requirement baseline | Requirements are testable and distinguish need from preferred solution |
| 2 | IT Procurement Specialist | creates and runs RFI/RFP process with comparable response structure | RFI/RFP pack and response evidence | Supplier responses are comparable and procurement rules are followed |
| 3 | Vendor Manager | assesses supplier capability, viability, support and governance fit | supplier assessment | Material supplier assumptions and dependency risks are evidenced |
| 4 | Third-Party Risk Manager | coordinates security/privacy/resilience risk assessment with specialist authorities | security/privacy/supplier risk assessment | Critical risks/obligations are resolved, mitigated or accepted by correct authority |
| 5 | Enterprise Applications Architect | assesses architecture/capability/integration fit and lock-in/exit implications | architecture-fit decision | Selection does not create hidden target-state or integration contradictions |
| 6 | IT Procurement Specialist | runs weighted selection and records rationale/conflicts | selection decision | Decision is traceable to declared criteria, evidence and authority |
| 7 | Contract Manager | translates agreed service/security/privacy/resilience/exit controls into enforceable clauses/schedules | contract control schedule | Every mandatory control has enforceable wording, evidence/measurement and remedy/exit path |
| 8 | Implementation Consultant | coordinates implementation against contract/design acceptance criteria | implementation plan and evidence | Implementation deviations are approved, not silently normalised |
| 9 | Service Transition and Operational Readiness Manager | validates support, monitoring, CMDB, DR, security, ownership and service acceptance | service acceptance | No production acceptance with missing critical operational ownership/evidence |
| 10 | Vendor Manager | establishes ongoing performance, risk, improvement, renewal and exit governance | vendor governance baseline | Contractual obligations map to measured service/vendor governance |
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
source-to-contract-to-serviceworkflow 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.