The Enterprise Automation Scale Standard: Shared Capabilities, Portfolio Governance and Capability Transfer

An automation that works in one team may need different controls and support before it can work elsewhere. Check the added users, dependencies, suppliers and failure risks. Agree who will own the shared capability and whether local teams can run it without permanent delivery-team support.

This standard helps the CEO, COO and CIO decide what to standardise, share, federate, transfer, constrain, retire or stop. It consumes accepted operating evidence from The Automation Production Operating Standard: Integration, Monitoring, Incidents and Change Control. It does not select the opportunity portfolio owned by The Automation Opportunity Portfolio: A Value, Feasibility, Risk and Learning Playbook and does not presume that AI is the appropriate mechanism.

1. The Market Connection Context

The recognisable condition is a collection of local successes that cannot be repeated safely. Teams buy overlapping tools, rebuild connectors and controls, use different identifiers and evidence rules, and compete for the same specialists. A central team becomes a queue, while business owners describe operating responsibilities as “the platform team’s problem”. Costs, incidents, exceptions and customer effects cannot be compared across services.

The value path is:

Accepted local operating evidence
→ explicit enterprise scale question
→ shared capability and control boundaries
→ federated ownership and reusable evidence
→ transferred operating capability
→ repeatable service value under portfolio and risk limits

Potential exposure includes duplicated investment, slower delivery, tool and supplier sprawl, unowned concentration risk, inconsistent customer treatment, central-team bottlenecks and benefits that cannot be reconciled. These effects remain REQUIRES VALIDATION until the organisation maps actual services, demand, dependencies, work, cost, capacity, incidents, outcomes and alternatives.

What scale means

Scale is an organisational operating decision, not a deployment count. It may mean:

• reusing a proven interface, identity pattern, evidence schema, control or runbook;
• offering a shared capability with an accountable service owner and published consumption contract;
• federating delivery while central governance retains minimum controls and portfolio visibility;
• transferring knowledge, tools and decision rights to receiving teams;
• consolidating duplicated capabilities where evidence supports it;
• deliberately keeping services local where shared dependency would cost more or create unacceptable risk;
• retiring an intervention, pattern, platform or supplier route that no longer earns its burden.

GOV.UK open-standards principles connect interoperability and open formats with reuse, transfer and reduced lock-in (Open Standards principles, VERIFIED official public-sector guidance within its context). Reuse still requires a local fitness gate; a common component can be wrong for a distinct workflow or population.

The scale unit and dispositions

Give every scale candidate a stable ID and classify it as a service, platform capability, integration, data contract, control, evidence pattern, runbook, supplier dependency or skill. Compare it against the local alternative and one scale boundary.

Use one primary disposition:

Boundaries with The Automation Opportunity Portfolio: A Value, Feasibility, Risk and Learning Playbook and The Automation Production Operating Standard: Integration, Monitoring, Incidents and Change Control

The Automation Opportunity Portfolio: A Value, Feasibility, Risk and Learning Playbook decides which automation opportunities deserve the next evidence gate across a portfolio. The Enterprise Automation Scale Standard: Shared Capabilities, Portfolio Governance and Capability Transfer does not reprioritise that demand portfolio. It decides how accepted, operating capabilities may become organisational leverage.

The Automation Production Operating Standard: Integration, Monitoring, Incidents and Change Control owns each production service: objectives, telemetry, incidents, versions, change, rollback and retirement. The Enterprise Automation Scale Standard: Shared Capabilities, Portfolio Governance and Capability Transfer consumes that service evidence and may establish common contracts, but cannot turn weak local operation into a scale case. Every receiving service still accepts its own production responsibility.

Shared capability contract

Every shared capability needs a purpose, consumers, owner, funding basis, service boundary, interface, data and identity contract, mandatory controls, version policy, support, capacity, evidence, exception route, change authority, portability and retirement route. Central provision does not remove business ownership of outcomes or affected people.

NIST CSF 2.0 elevates governance and aligns cybersecurity activity with enterprise risk, roles, policy and supply-chain considerations (NIST CSF 2.0, VERIFIED official source). This standard uses that governance orientation without claiming compliance or prescribing one security implementation.

Expected results are a scale charter and capability inventory, common capability/control contract, receiving-team transfer and adoption register, and enterprise evidence/decision review. They are decision artefacts, not proof of scale, savings, maturity or market outcome.

2. The Leadership vs. Delegation Boundary

The reader recognises that scale requires common platforms, reusable controls, portfolio governance, operating evidence, ownership and deliberate capability transfer.

Internal leadership

An internal team can lead when enterprise and local owners can challenge each other, production evidence is accessible, platform capacity and internal work are visible, receiving teams can refuse unsuitable reuse, and central capability owners are funded to operate rather than merely launch. The forum must distinguish enterprise minimum controls from preferences.

Independent leadership

Independent challenge is justified when a platform or supplier shapes the scale case, central and local budgets hide transfers of cost, teams mark their own reuse readiness, evidence definitions conflict, or an executive mandate makes dissent difficult. A partner may structure governance and transfer but cannot become permanent owner of the enterprise capability it recommends.

Narrow specialist support

Use architecture, reliability, data, security, privacy, procurement, finance, accessibility, workforce or learning specialists for bounded decisions. Return local production weaknesses to The Automation Production Operating Standard: Integration, Monitoring, Incidents and Change Control and opportunity prioritisation to The Automation Opportunity Portfolio: A Value, Feasibility, Risk and Learning Playbook.

Stop and escalation

Stop expansion when local operating evidence is absent, customer or employee harm is unresolved, ownership is unfunded, receiving teams lack authority or capacity, concentration breaches tolerance, shared controls cannot be evidenced, benefit assumptions depend on counting displaced cost twice, or transfer remains vendor or delivery-team dependence. Escalate enterprise investment to sponsor/CFO, operating ownership to COO, architecture and technical concentration to CIO, and specialist issues to qualified authorities.

Questions for evaluating a scale partner

1. Which local evidence supports reuse and which conditions remain service-specific?
2. What belongs in a shared service, a mandatory standard, a federated pattern or a local service?
3. Which central cost or burden will move to receiving teams?
4. How can a receiving owner reject an unsuitable capability?
5. Which controls, evidence and interfaces are mandatory, and who may grant exceptions?
6. How are platform capacity, supplier concentration, identity, data and incident dependencies governed?
7. What proves knowledge and operating authority have transferred?
8. How will teams contribute changes without fragmenting the standard?
9. Which evidence triggers redesign, retirement or decentralisation?
10. How will the organisation avoid creating permanent dependence on the partner?

3. The Step-by-Step Execution Standard

Use the Scale Charter and Capability Inventory, Shared Capability Control and Interface Register, Receiving Team Transfer and Adoption Register, and Enterprise Scale Evidence and Decision Register.

Step 01: Charter the enterprise scale decision

Purpose and decision served Define what leadership may standardise, share, federate, transfer, retain locally, validate, change, defer or stop.

Accountable owner Executive sponsor with COO and CIO acceptance.

Delegated lead and contributors Enterprise operating lead; CFO, portfolio forum, production owners, risk executive, architecture and receiving leaders contribute.

Preconditions, inputs and access Named enterprise outcome, The Automation Production Operating Standard: Integration, Monitoring, Incidents and Change Control operating evidence, The Automation Opportunity Portfolio: A Value, Feasibility, Risk and Learning Playbook boundary, authority, conflicts and access to local owners.

Actions

1. Assign stable decision and capability IDs and state the scale question without presuming replication.
2. Name affected services, teams, people, markets, dependencies and enterprise outcomes.
3. Define scope, exclusions, mandatory evidence, decision date, dispositions and stop authority.
4. Name sponsor, decision owner, capability owners, local owners, evidence custodian, challenger and specialists.
5. Record platform, supplier, budget, prior-investment and central-team conflicts.

Evidence to retain Scale charter, authority matrix, boundary record, conflict register and evidence request.

Decision or scoring rule Proceed only when the question concerns organisational reuse or transfer and accepted local evidence exists.

Output and template Charter rows in T01.

Acceptance gate CHARTERED, RETURN TO AUTOMATION PRODUCTION OPERATING STANDARD, RETURN TO AUTOMATION OPPORTUNITY PORTFOLIO, CHANGE, DEFER or STOP.

Leadership checkpoint Sponsor confirms that local retention and retirement remain legitimate options.

Human control point Only authorised humans define mandatory enterprise reach and exposure.

Failure modes and safeguards An enterprise mandate becomes assumed fitness; preserve a local acceptance gate.

Change, stop or escalation condition Stop for absent operating evidence, unowned outcome or unauthorised enterprise scope.

Handoff to the next step Send accepted question and evidence boundary to Step 02.

Step 02: Inventory capabilities, services and dependencies

Purpose and decision served Establish what actually exists, who owns it and which dependencies expansion would amplify.

Accountable owner CIO with COO acceptance.

Delegated lead and contributors Enterprise architect and service portfolio analyst; production owners, finance, procurement and data owners contribute.

Preconditions, inputs and access Accepted charter, The Automation Production Operating Standard: Integration, Monitoring, Incidents and Change Control service records, contracts, asset records, cost sources and incident evidence.

Actions

1. Inventory production services, platforms, interfaces, data contracts, controls, runbooks, evidence patterns, suppliers and skills.
2. Link each capability to consumers, owner, versions, service outcome, operating evidence, costs and lifecycle state.
3. Map shared and single points of dependency across identity, data, integration, supplier, people and support.
4. Identify duplication and variation without treating difference as waste automatically.
5. Classify evidence gaps, ownership gaps and candidates for standardise, share, federate, transfer, local retention or retirement.

Evidence to retain Capability inventory, dependency graph, duplication map, cost references and gap register.

Decision or scoring rule No capability becomes a scale candidate without an owner, consumer, operating evidence and dependency record.

Output and template Inventory rows in T01.

Acceptance gate INVENTORY FIT, VALIDATE, CHANGE BOUNDARY, RETURN TO AUTOMATION PRODUCTION OPERATING STANDARD or STOP.

Leadership checkpoint CIO and COO accept the material inventory and unknowns.

Human control point Local owners confirm source accuracy and service distinctions.

Failure modes and safeguards Tool inventory substitutes for capability understanding; link every asset to work and outcome.

Change, stop or escalation condition Escalate unknown critical dependencies, ownership or unsupported production state.

Handoff to the next step Send fit candidates to evidence reconciliation in Step 03.

Step 03: Reconcile local operating and outcome evidence

Purpose and decision served Determine what local evidence can and cannot support at enterprise scope.

Accountable owner Enterprise decision owner with local service owners.

Delegated lead and contributors Evidence lead; analysts, operations, finance, customer and risk owners contribute.

Preconditions, inputs and access Capability inventory, The Automation Production Operating Standard: Integration, Monitoring, Incidents and Change Control objectives, incidents, changes, burdens, costs, outcomes and evidence limits.

Actions

1. Reconcile service evidence by purpose, population, period, workload, version and operating boundary.
2. Separate availability, correctness, completion, customer outcome, human burden, control and cost evidence.
3. Record incidents, exceptions, fallback, manual repair and unresolved harm beside favourable observations.
4. Test whether evidence is transferable to proposed receiving contexts or requires validation.
5. Preserve alternative explanations, dissent and evidence expiry.

Evidence to retain Evidence reconciliation, source records, context differences, dissent and transferability gaps.

Decision or scoring rule Local evidence supports only observed contexts; scale fitness requires an explicit similarity or validation case.

Output and template Evidence rows in T04.

Acceptance gate EVIDENCE SUPPORTS SCALE DESIGN, VALIDATE, RETAIN LOCAL, RETURN TO AUTOMATION PRODUCTION OPERATING STANDARD or STOP.

Leadership checkpoint Sponsor sees service limits and unresolved adverse evidence.

Human control point Named business and service owners accept interpretations.

Failure modes and safeguards Successful anecdotes erase operating burden; require source-linked measures and failure evidence.

Change, stop or escalation condition Return weak production operation to The Automation Production Operating Standard: Integration, Monitoring, Incidents and Change Control rather than compensating through scale design.

Handoff to the next step Send evidence-fit candidates to Step 04.

Step 04: Choose the shared, federated or local boundary

Purpose and decision served Select an organisational model for each capability without forcing uniformity.

Accountable owner COO and CIO jointly.

Delegated lead and contributors Operating-model lead; capability owners, receiving teams, architecture, finance and risk contribute.

Preconditions, inputs and access Evidence-fit candidates, consumer needs, local constraints, capacity and dependency evidence.

Actions

1. Compare standard, shared service, federation, transfer, local retention, validation, redesign and retirement options.
2. Test variation needs, economies of reuse, central bottleneck, concentration, responsiveness and local accountability.
3. Define enterprise minimums and the decisions retained locally for each option.
4. Identify the provider-consumer contract and exception route.
5. Record chosen boundary, evidence, trade-offs, conditions and dissent.

Evidence to retain Boundary option cards, decision rights, trade-offs, exception design and rejected alternatives.

Decision or scoring rule Select the least centralised model that achieves the accepted enterprise purpose and controls.

Output and template Boundary rows across T01 and T02.

Acceptance gate STANDARDISE, SHARE AS A SERVICE, FEDERATE, TRANSFER, RETAIN LOCAL, VALIDATE, CHANGE or RETIRE.

Leadership checkpoint Receiving leaders can challenge fit and capacity before the model is fixed.

Human control point Enterprise leaders decide mandatory boundaries; local leaders retain named outcome accountability.

Failure modes and safeguards Centralisation is treated as scale; test responsiveness, ownership and failure concentration.

Change, stop or escalation condition Escalate unresolved decision-right conflict or unacceptable concentration.

Handoff to the next step Send accepted boundary to capability contract design in Step 05.

Step 05: Contract shared capabilities, interfaces and controls

Purpose and decision served Make reusable capability consumable, supportable and governable.

Accountable owner Named enterprise capability owner.

Delegated lead and contributors Platform/service lead; architecture, data, security, privacy, operations and consumer representatives contribute.

Preconditions, inputs and access Accepted boundary, consumer cases, architecture, The Automation Production Operating Standard: Integration, Monitoring, Incidents and Change Control controls and specialist requirements.

Actions

1. Define purpose, consumers, interface, identity, data, version, evidence and service boundary.
2. Separate mandatory common controls from configurable local policy and workflow.
3. Contract capacity, support, observability, incident, change, rollback, portability and retirement responsibilities.
4. Define onboarding, consumption, exception, contribution and deprecation routes.
5. Route security, privacy, legal, employment, accessibility and other specialist controls to qualified owners.

Evidence to retain Capability contract, interface schema, control ownership, service objectives, exception and lifecycle policy.

Decision or scoring rule A shared capability is ready only when provider and consumer obligations are testable and owned.

Output and template Contract rows in T02.

Acceptance gate CONTRACT ACCEPTED, VALIDATE, CHANGE MODEL, RETAIN LOCAL or STOP.

Leadership checkpoint Capability and receiving owners jointly accept responsibilities and evidence.

Human control point Qualified owners retain specialist control authority and exception decisions.

Failure modes and safeguards An API is mistaken for a service; include ownership, support, evidence and lifecycle.

Change, stop or escalation condition Stop for ownerless control, unsupported capacity or non-executable recovery and retirement.

Handoff to the next step Send accepted contracts to economics and capacity design in Step 06.

Step 06: Reconcile enterprise economics and capacity

Purpose and decision served Determine whether shared capability is fundable and operable without hiding transferred cost.

Accountable owner CFO with COO and capability-owner acceptance.

Delegated lead and contributors Finance analyst; platform, workforce, procurement, service and receiving-team owners contribute.

Preconditions, inputs and access Capability contract, demand evidence, internal work, supplier terms, current alternatives and capacity baselines.

Actions

1. Separate shared setup, recurring, usage, support, assurance, change, incident, transfer and retirement commitments.
2. Map cost and effort moving from central to local teams or between budgets.
3. Build organisation-approved demand and capacity scenarios without inventing volumes or savings.
4. Define funding, consumption, prioritisation and capacity-allocation decisions.
5. Record uncertainty, constraints, thresholds and evidence needed for expansion.

Evidence to retain Commitment model, capacity scenarios, funding decision, transfer-of-cost map and assumptions.

Decision or scoring rule Do not fund enterprise expansion from projected duplication savings unless baseline and attribution are accepted.

Output and template Economics and capacity rows in T04.

Acceptance gate FUND BOUNDED SCALE, VALIDATE, CHANGE, DEFER, RETAIN LOCAL or STOP.

Leadership checkpoint CFO and COO accept scenario limits and capacity ownership.

Human control point Finance and operational owners approve assumptions and allocation rules.

Failure modes and safeguards Central costs disappear into platform budgets; preserve full commitment categories and consumers.

Change, stop or escalation condition Escalate unfunded ownership, capacity conflict or unbounded supplier exposure.

Handoff to the next step Pass fundable capability contracts to receiving-team readiness in Step 07.

Step 07: Qualify receiving teams and contexts

Purpose and decision served Determine where the capability fits and what each receiving team must own.

Accountable owner Receiving business owner with service owner.

Delegated lead and contributors Adoption and operations lead; workflow, data, risk, people and customer representatives contribute.

Preconditions, inputs and access Capability contract, receiving workflow evidence, population, data, capacity, controls and local alternatives.

Actions

1. Compare receiving purpose, workflow, population, exception, data and consequence with the evidenced source context.
2. Confirm local outcome owner, service owner, support, human fallback, decision rights and stop authority.
3. Identify adaptation, local controls, evidence and specialist review required.
4. Assess adoption and workload without assuming that technical availability creates use.
5. Record accept, validate, change, retain local, defer or reject disposition.

Evidence to retain Context-fit assessment, owner acceptance, gap plan, local baseline and disposition.

Decision or scoring rule Every receiving context passes its own mandatory fit and ownership gates.

Output and template Readiness rows in T03.

Acceptance gate READY FOR TRANSFER PROOF, VALIDATE, CHANGE, RETAIN LOCAL, DEFER or REJECT.

Leadership checkpoint Receiving leader accepts real work and can refuse unsuitable reuse.

Human control point Affected owners decide local acceptance; enterprise mandate cannot auto-approve it.

Failure modes and safeguards Similarity is assumed from department labels; inspect actual workflow and consequence.

Change, stop or escalation condition Escalate missing owner, capacity, fallback, control or lawful authority.

Handoff to the next step Send fit receiving teams to transfer design in Step 08.

Step 08: Transfer knowledge, tools and decision authority

Purpose and decision served Make receiving teams capable of operating and challenging the shared capability.

Accountable owner Receiving service owner and enterprise capability owner jointly.

Delegated lead and contributors Capability-transfer lead; operators, trainers, support, security and evidence custodians contribute.

Preconditions, inputs and access Accepted context fit, roles, runbooks, environments, evidence access and transfer acceptance tests.

Actions

1. Define competencies by decision and operating task, not attendance.
2. Transfer documentation, interfaces, configuration, evidence, runbooks, escalation and change routes.
3. Rehearse normal, exception, failure, recovery, challenge and stop scenarios with real roles.
4. Verify receiving owners can diagnose, operate, escalate and refuse unsafe change without delivery-team rescue.
5. Record remaining dependency, support, remediation and transfer disposition.

Evidence to retain Competency map, rehearsal record, access evidence, owner acceptance and dependency log.

Decision or scoring rule Training completion is insufficient; acceptance requires demonstrated decisions and actions within authority.

Output and template Transfer rows in T03.

Acceptance gate CAPABILITY TRANSFERRED, CONDITION, EXTEND PROOF, CHANGE MODEL, DEFER or STOP.

Leadership checkpoint Receiving leader and capability owner sign the evidence boundary and support model.

Human control point Real accountable roles perform and judge transfer exercises.

Failure modes and safeguards Documentation masquerades as capability; require practical rehearsal and independent observation.

Change, stop or escalation condition Stop expansion where dependency on supplier, central or delivery-team heroics persists.

Handoff to the next step Send accepted transfer to bounded rollout in Step 09.

Step 09: Execute bounded expansion and observe

Purpose and decision served Generate enterprise-scale evidence without broad uncontrolled replication.

Accountable owner Enterprise capability owner with receiving service owner.

Delegated lead and contributors Release and adoption leads; operations, evidence, risk and customer owners contribute.

Preconditions, inputs and access Accepted capability contract, transfer evidence, baselines, telemetry, fallback, incident and stop controls.

Actions

1. Define bounded exposure units and human gates based on consequence, not calendar promises.
2. Verify version, consumer, owner, control and rollback identity before each expansion.
3. Observe service, workflow, customer, human burden, cost, control and dependency signals.
4. Compare source and receiving contexts while preserving failures and local variation.
5. Hold, reduce, roll back, validate, change or stop when accepted triggers occur.

Evidence to retain Exposure record, version and owner identity, measures, incidents, exceptions, decisions and rollback evidence.

Decision or scoring rule No exposure increase occurs without the previous unit’s mandatory evidence and human acceptance.

Output and template Adoption and evidence rows in T03 and T04.

Acceptance gate EXPAND WITHIN BOUNDARY, HOLD, VALIDATE, CHANGE, ROLL BACK, RETAIN LOCAL or STOP.

Leadership checkpoint Enterprise and local owners review outcomes and burden together.

Human control point Named owners approve each material exposure change.

Failure modes and safeguards Deployment counts become scale evidence; retain outcome, burden, control and ownership measures.

Change, stop or escalation condition Trigger The Automation Production Operating Standard: Integration, Monitoring, Incidents and Change Control incident/change controls for service failures; stop enterprise expansion independently.

Handoff to the next step Send bounded evidence to governance review in Step 10.

Step 10: Operate portfolio governance and exceptions

Purpose and decision served Maintain enterprise coherence without taking over The Automation Opportunity Portfolio: A Value, Feasibility, Risk and Learning Playbook opportunity selection or local operations.

Accountable owner Enterprise automation governance forum.

Delegated lead and contributors Portfolio evidence lead; capability, local, finance, risk, architecture and customer owners contribute.

Preconditions, inputs and access Capability/service inventory, current contracts, measures, exceptions, incidents, costs, decisions and The Automation Opportunity Portfolio: A Value, Feasibility, Risk and Learning Playbook interface.

Actions

1. Review shared capability health, concentration, duplication, adoption, exception, change and transfer evidence.
2. Maintain enterprise standards, patterns, versions, owners and expiry.
3. Decide exception requests by evidence, compensating controls, period and owner.
4. Route new opportunity priority questions to The Automation Opportunity Portfolio: A Value, Feasibility, Risk and Learning Playbook and local operating failures to The Automation Production Operating Standard: Integration, Monitoring, Incidents and Change Control.
5. Record retain, change, federate, decentralise, consolidate, retire or stop decisions.

Evidence to retain Forum agenda, evidence pack, exception decisions, standard versions, dissent and routing records.

Decision or scoring rule Govern capability coherence and evidence; do not use this forum to bypass authorised portfolio or service owners.

Output and template Governance rows in T04.

Acceptance gate RETAIN, CHANGE, FEDERATE, DECENTRALISE, CONSOLIDATE, RETIRE, STOP or ROUTE.

Leadership checkpoint Sponsor reviews material concentration, investment and customer consequence.

Human control point Named forum members decide exceptions and boundaries; dashboards do not decide.

Failure modes and safeguards Governance becomes an approval queue; publish decision rights and delegate bounded exceptions.

Change, stop or escalation condition Escalate cross-enterprise risk, unfunded service ownership or repeated exception patterns.

Handoff to the next step Send accumulated evidence to Step 11.

Step 11: Reconcile value, capability and guardrail evidence

Purpose and decision served Determine whether enterprise leverage is associated with accepted outcomes without double counting.

Accountable owner Benefit owner with CFO, COO and CIO acceptance.

Delegated lead and contributors Evidence and finance leads; capability, service, customer, people and risk owners contribute.

Preconditions, inputs and access Baselines, operating evidence, commitment model, adoption, transfer, incident and alternative evidence.

Actions

1. Reconcile capability reuse, local adoption, service outcomes, internal burden, cost and guardrails separately.
2. Avoid counting central savings and local effort reduction as the same benefit.
3. Record attribution limits, demand, policy, supplier, workforce and concurrent changes.
4. Compare standardise, share, federate, retain local, change, retire and stop options.
5. Produce decision cards with evidence, uncertainty, dissent and proposed disposition.

Evidence to retain Measure reconciliation, benefit and burden records, attribution notes, option cards and dissent.

Decision or scoring rule Reuse activity is not value; accepted outcome and guardrail evidence governs continuation.

Output and template Review and decision rows in T04.

Acceptance gate DECISION READY, VALIDATE, CHANGE, DEFER, RETIRE or STOP.

Leadership checkpoint Sponsor and CFO accept evidence limits before enterprise disposition.

Human control point Benefit and affected-owner judgements remain human and contestable.

Failure modes and safeguards Deployment and reuse counts inflate benefit; preserve outcome measures and counterfactual limits.

Change, stop or escalation condition Escalate unresolved harm, material benefit contradiction or unsustainable burden.

Handoff to the next step Send decision-ready evidence to Step 12.

Step 12: Decide, institutionalise, change or retire

Purpose and decision served Make an authorised enterprise disposition and close or renew capability authority.

Accountable owner Executive sponsor.

Delegated lead and contributors Governance forum and evidence custodian; CFO, COO, CIO, capability and receiving owners participate.

Preconditions, inputs and access Decision cards, residual risks, funding, ownership, dissent, obligations and closure routes.

Actions

1. Record one primary disposition for each capability and boundary.
2. Set conditions, owners, evidence gates and review triggers without inventing delivery duration.
3. Institutionalise accepted standards, services, federation and transfer responsibilities in controlled repositories.
4. For change or retirement, close access, interfaces, records, contracts, claims and dependencies through The Automation Production Operating Standard: Integration, Monitoring, Incidents and Change Control service routes.
5. Archive evidence and route new opportunity questions to The Automation Opportunity Portfolio: A Value, Feasibility, Risk and Learning Playbook.

Evidence to retain Signed decision, conditions, owner acceptance, controlled standard, closure evidence and routing record.

Decision or scoring rule Choose STANDARDISE, SHARE AS A SERVICE, FEDERATE, TRANSFER, RETAIN LOCAL, VALIDATE, CHANGE, DEFER or RETIRE OR STOP.

Output and template Final decision rows in T04.

Acceptance gate AUTHORISED AND OWNED only when funding, capability ownership, receiving ownership, evidence and stop routes are accepted.

Leadership checkpoint Sponsor confirms enterprise decision, benefit ownership and residual risk.

Human control point Only authorised leaders set enterprise reach or accept residual exposure.

Failure modes and safeguards A programme declares scale complete while owners remain dependent; require transfer and operating evidence.

Change, stop or escalation condition Re-charter material purpose, population, supplier, platform, data, authority or consequence changes.

Handoff to the next step Continue governed review; route opportunity selection to The Automation Opportunity Portfolio: A Value, Feasibility, Risk and Learning Playbook and production operation or retirement to The Automation Production Operating Standard: Integration, Monitoring, Incidents and Change Control.

4. The Evidence & Measurement Checklist

Preflight and authority

• The scale question names an enterprise outcome without presuming replication. Evidence: charter. Owner: sponsor.
• The Automation Opportunity Portfolio: A Value, Feasibility, Risk and Learning Playbook opportunity and The Automation Production Operating Standard: Integration, Monitoring, Incidents and Change Control production boundaries are explicit. Evidence: scope record. Owner: CIO.
• Enterprise, capability, receiving and benefit owners are named. Evidence: authority matrix. Owner: COO.
• Local retention, validation, change and retirement remain options. Evidence: disposition set. Owner: decision owner.
• Platform, supplier, budget and prior-investment conflicts are disclosed. Evidence: conflict register. Owner: challenger.

Evidence access and quality

• Each candidate links to accepted The Automation Production Operating Standard: Integration, Monitoring, Incidents and Change Control operating evidence. Evidence: service evidence index. Owner: service owner.
• Evidence preserves purpose, population, period, workload and version. Evidence: source register. Owner: custodian.
• Incidents, exceptions, fallback and human repair remain visible. Evidence: adverse evidence log. Owner: operations owner.
• Receiving-context differences remain REQUIRES VALIDATION until tested. Evidence: context map. Owner: analyst.
• Cost, capacity and outcome sources have named organisational owners. Evidence: evidence register. Owner: proof owner.

Method execution

• Capabilities include services, interfaces, controls, evidence, suppliers and skills. Evidence: inventory. Owner: architect.
• Shared, federated, transferred, local and retirement options are compared. Evidence: option cards. Owner: operating lead.
• Every shared capability has a provider-consumer contract. Evidence: capability contract. Owner: capability owner.
• Every receiving context passes local fitness and ownership gates. Evidence: readiness record. Owner: receiving owner.
• Expansion uses bounded exposure and human evidence gates. Evidence: exposure register. Owner: service owner.

Governance, privacy, security and risk

• Enterprise minimum controls are separate from configurable local policy. Evidence: control standard. Owner: risk executive.
• Identity, data, supplier and platform concentration are assessed. Evidence: dependency map. Owner: CIO.
• Specialist legal, privacy, security, employment and accessibility decisions have qualified owners. Evidence: referral log. Owner: sponsor.
• Exceptions state scope, compensating controls, owner and expiry. Evidence: exception register. Owner: governance forum.
• Receiving owners retain affected-person accountability and stop authority. Evidence: authority acceptance. Owner: COO.

Deliverables and acceptance

• All four working files use linked stable IDs. Evidence: pack index. Owner: evidence custodian.
• Capability contracts include owner, consumers, interface, service, control, evidence and lifecycle. Evidence: contract register. Owner: capability owner.
• Transfer acceptance uses demonstrated decisions and actions. Evidence: rehearsal record. Owner: receiving owner.
• Enterprise decisions retain conditions, dissent and rejected alternatives. Evidence: decision pack. Owner: challenger.
• Retirement closes access, interfaces, records, claims and dependencies. Evidence: closure record. Owner: service owner.

Measurement

• Reuse, adoption, operating, outcome and guardrail measures remain separate. Evidence: measure register. Owner: benefit owner.
• Measures state baseline, source, definition, owner, cadence and response. Evidence: metric contracts. Owner: analyst.
• Central and local commitment transfers remain visible. Evidence: commitment map. Owner: CFO.
• Capability transfer measures demonstrated ownership rather than attendance. Evidence: transfer record. Owner: COO.
• Attribution records demand, policy, supplier and concurrent changes. Evidence: review pack. Owner: proof owner.

Decision and handover

• Every capability receives one primary scale disposition. Evidence: signed decision. Owner: sponsor.
• Standards, services and federated responsibilities enter controlled repositories. Evidence: handover. Owner: capability owner.
• Receiving teams accept local work, controls, support and outcomes. Evidence: owner acceptance. Owner: receiving leader.
• New opportunity priority questions route to The Automation Opportunity Portfolio: A Value, Feasibility, Risk and Learning Playbook. Evidence: routing record. Owner: portfolio forum.
• Production operation and retirement remain under The Automation Production Operating Standard: Integration, Monitoring, Incidents and Change Control. Evidence: service handoff. Owner: service owner.

Review, change and stop controls

• Purpose, population, supplier, platform, data or authority changes trigger review. Evidence: trigger register. Owner: governance forum.
• Loss of operating evidence stops further expansion. Evidence: gate record. Owner: capability owner.
• Repeated exceptions trigger standard or boundary redesign. Evidence: exception analysis. Owner: CIO.
• Persistent central or supplier dependence triggers transfer remediation or stop. Evidence: dependency review. Owner: COO.
• Unresolved harm or control failure bypasses routine cadence. Evidence: escalation record. Owner: risk executive.

Measurement contracts

Measure A: Capability inventory and ownership coverage

Measure B: Shared contract acceptance

Measure C: Demonstrated capability transfer

Measure D: Shared capability operating burden

Measure E: Enterprise service or market outcome

Measure F: Concentration and exit control

Evidence classifications used in this guide

• VERIFIED: official external guidance or retained organisational evidence checked for identity, scope and relevance.
• INFERRED: a scale interpretation linked to evidence with alternatives and limitations visible.
• PROPOSED: a capability, standard, control, funding model or disposition awaiting authorised acceptance.
• REQUIRES VALIDATION: a material transfer, capacity, outcome or control claim that cannot support scale yet.

Sources and evidence notes

1. NIST Cybersecurity Framework 2.0 supports enterprise governance, roles, policy and supply-chain risk integration. VERIFIED official US source; it does not certify this method.
2. NIST AI RMF Core describes Govern, Map, Measure and Manage and lifecycle accountability. VERIFIED official source, relevant only where AI is intrinsic.
3. NIST AI RMF Playbook provides voluntary suggested actions and explicitly is not a universal ordered checklist. VERIFIED official source.
4. GOV.UK: Open Standards principles supports interoperability, open formats, reuse and change. VERIFIED official public-sector guidance.
5. GOV.UK: Technology Code of Practice provides official principles for public technology design and spend decisions. VERIFIED official guidance within its jurisdictional context.
6. NIST SP 800-161 Rev. 1 supports lifecycle cybersecurity supply-chain risk management. VERIFIED official source.

The twelve-step method, dispositions, contracts, measures and visuals are PROPOSED Abrasim operating methods. They do not establish maturity, compliance, savings, scale, capability transfer or market outcomes.