The Automation and Technology Readiness Assessment: An Executive Standard for Choosing What Should Change

You have been asked to automate work, introduce AI or release capacity, but the business case is not ready. The workflow may be unstable, inputs unreliable, permissions unclear or support unassigned. Check those conditions before investing in technology and passing unresolved problems to customers and employees.

Use the Automation and Technology Readiness Assessment to examine one workflow and the proposed change. Check its value, data, architecture, controls and operating capability, then decide what needs to happen first. The decision is whether to progress, validate, defer or stop before investing. A single maturity score cannot establish readiness.

This is an Abrasim decision-support working methodology. It is not a technology selection, production architecture, implementation plan, legal or privacy opinion, security assessment, financial assurance engagement, employee-impact determination or guarantee of capacity, quality, cost, revenue or service improvement. Organisation-specific baselines, readiness findings, supplier claims, control effectiveness, commercial exposure and future outcomes remain REQUIRES VALIDATION until authorised evidence establishes them.

Executive decision card: complete before assessing tools

Decision in one view

1. Name the bounded workflow, customer/service commitment and decision owner.
2. Test value, workflow, data/evidence, architecture, governance/control and operating capability separately; one material safety, legal, privacy, security, customer or employee stop condition remains decisive.
3. Record PROGRESS, VALIDATE, DEFER or STOP with evidence, limits and dissent.
4. Route a pilot candidate to The Automation Architecture Decision: Rules, Platforms, Agents, Custom Software or No Build architecture first unless accepted architecture evidence is already linked; The Proof-of-Value Pilot Standard: Designing Automation Tests That Can Earn Production pilot design additionally requires The Workflow Constraint and Root-Cause Audit: Simplify the Work Before Automating It diagnosis, The AI and Automation Governance Standard: Proportionate Control from Assistance to Autonomous Action controls where applicable and its own receiving-owner acceptance.

1. The Market Connection Context

The buyer recognises the problem when the organisation is being asked to invest in automation or AI while the work, evidence and ownership remain unsettled.

Typical signals include:

• a board, executive or departmental mandate names a technology category but not the customer, service or operating result it should improve;
• demonstrations look capable, yet the live workflow contains undocumented exceptions, manual judgement and controls the demonstration did not test;
• several teams have bought overlapping tools or enabled embedded features without one current-use, permission, data or operating view;
• employees use manual workarounds because the approved process, source information or system integration does not support the real work;
• a pilot appears faster, but rework, verification, exception handling, supplier cost, support effort or downstream service impact are excluded;
• the proposed intervention depends on data whose owner, lawful use, quality, currency or access route has not been accepted;
• risk and technology teams are brought in after a solution has been preferred rather than while permissions, failure and consequence can still change the choice;
• no one can name who operates the intervention, handles incidents, changes the rules, supports users or owns the benefit after delivery.

The affected market connection is practical. A customer promise becomes work. Work passes through people, information, decisions, systems, controls and handoffs. The output becomes a delivered product, service, decision or response. If the intervention adds delay, hides an error, excludes a user, weakens accountability or creates unsupported operating burden, technology activity has not become value.

The value path this assessment protects

The primary whole-business value path is Commitments and work → usable capacity and reliable service. Capacity is usable only when the organisation can redirect it to an agreed need without degrading quality, safety, customer experience or employee conditions. A reduction in task time is therefore not automatically a bottom-line result.

Six use-case readiness lenses

Readiness is assessed for a specific workflow and intervention boundary. Do not average these lenses into one enterprise label.

One weak lens does not always mean stop. It may identify enabling work or a controlled validation step. A material legal, safety, security, customer or employee stop condition cannot be cancelled by strength elsewhere.

Use this causal chain for every material readiness finding:

Recognisable mandate or workflow condition → break in the commitment-to-service value path → customer or operating consequence → potential revenue, margin, cost, capacity, retention, risk, investment-efficiency or service-value exposure → evidence required to quantify it → dated executive disposition.

The potential economic effect remains REQUIRES VALIDATION until the organisation accepts the affected unit, baseline, period, source, mechanism, displaced burden and attribution limits.

The decision to make

Complete this statement before evidence collection:

By [decision date], [named decision owner] will decide whether [bounded workflow and candidate intervention] should [progress to discovery or proof, validate a material assumption, complete enabling work, defer, or stop] to improve or protect [named customer, service or business outcome], subject to [data, architecture, governance, people, financial and operating guardrails].

The decision date is the date for resolving the readiness question, requesting a bounded validation action or recording why work will not proceed. It is not a delivery estimate.

When to use this method

Use the assessment when:

• a material automation, AI or technology mandate exists but the decision is not tied to one accepted workflow outcome;
• current experiments, tools or embedded capabilities are not governed through one ownership and operating view;
• the same visible symptom could be caused by unnecessary work, workflow design, data, systems, control, capability or technology;
• a candidate intervention crosses functions, data owners, systems, suppliers or decision rights;
• the consequence of error, inappropriate access or service failure requires explicit human and control design;
• leadership needs to decide which opportunities may progress, which require enabling work and which should stop;
• a proof or implementation decision requires baselines, evaluation evidence and an operating owner before funding.

Do not use the full method when:

• an immediate safety, security, privacy, legal, financial-control or customer-harm issue requires containment by an authorised specialist;
• the problem is one known configuration defect with a trusted definition, one owner and a complete acceptance test;
• a stable manual or deterministic process can be corrected directly at lower burden;
• the organisation wants a predetermined tool or supplier recommendation and will not consider no-build or stop;
• no sponsor will own evidence access, workforce participation, risk acceptance or the final decision;
• there is no current capacity or legitimate reason to act on a finding;
• the required conclusion is a regulated assurance, legal, privacy, employment, security or architectural certification outside the team’s authority.

Scope, exclusions and dependencies

The scope must name one decision, the affected customer or service commitment, the organisational and workflow boundary, the selected current uses and candidate interventions, the evidence period, the six readiness lenses, the decision forum and the material exclusions. If several opportunities have different users, data, permissions, consequences or owners, create separate use-case records rather than one blended score.

Material exclusions normally include production implementation, final system or model selection, detailed solution architecture, procurement award, data engineering, integration build, model training, production evaluation, ongoing monitoring, legal or employment advice, privacy or security certification, financial assurance and guaranteed benefits. The assessment may identify that one of these is needed; it does not perform or pre-approve it.

Dependencies normally include a COO or equivalent sponsor, a workflow owner, CIO/CTO or delegated technical authority, finance participation in economic definitions, information and security authorities, customer or service representation, employee or labour authority where work changes materially, access to operating evidence, and capacity to make the decision.

Expected result

A completed assessment should leave leadership with:

• an approved decision charter and cross-functional responsibility map;
• a current-use and commitment register covering approved, unapproved, embedded, pilot and manual workarounds in scope;
• an observed workflow and commitment-to-service value-path map;
• a defensible baseline and evidence/uncertainty record;
• a small set of root-cause findings showing what should be removed, simplified, clarified or enabled before technology;
• bounded intervention options that include process, policy, existing-system, deterministic automation, augmentation, AI and no-build routes where relevant;
• a use-case-specific readiness profile across all six lenses, with material blockers and shared dependencies visible;
• a failure, permission, human-control and guardrail record;
• a prioritised portfolio with explicit progress, validate, defer and stop dispositions;
• a controlled proof or enabling plan where action is justified;
• an executive decision, operating handover and topic-specific measurement contract;
• dated continue, change, hold, stop or scale gates.

These are decision, evidence and operating artefacts, not proof that an intervention will create capacity, reduce cost, improve service or produce commercial value.

Where the assessment stops and the next standard begins

The assessment establishes whether a defined opportunity deserves a next phase. It does not complete the deeper work needed to execute that phase.

The handoff is conditional. A progress disposition is not approval to build, procure, deploy or scale.

2. The Leadership vs. Delegation Boundary

The assessment can be run internally. The relevant test is whether the organisation can assemble workflow authority, technical and information access, independent challenge, employee and customer accountability, and protected capacity without allowing the mandate or supplier proposal to become the diagnosis.

When an internal team is sufficient

A capable internal team can lead when the sponsor can grant access across the workflow; process participants can describe and demonstrate real work without retaliation; finance can accept the baseline; technical and information owners can test the candidate boundary; risk and people authorities retain their mandates; and a senior challenger is not committed to one tool.

Use the narrowest competent team. A known rules-engine configuration defect may need a system specialist and workflow owner. An unstable handoff may need process improvement. A missing source definition may need data governance. A labour, privacy or security question needs the relevant qualified authority. None requires a broad readiness assessment merely because automation was mentioned.

When an independent senior partner is justified

Independent leadership is proportionate when:

• the mandate, budget and evidence span operations, technology, finance, data, risk and people owners;
• current suppliers or internal teams benefit from one preferred intervention;
• the workflow contains contested causes, hidden exceptions or politically difficult ownership;
• a material investment, customer-facing action or high-consequence decision requires challenge before a proof;
• the internal team lacks temporary capacity to observe work, reconcile evidence and facilitate a cross-functional disposition;
• the work must leave complete artefacts that another qualified internal or external team can operate.

If those conditions apply, Abrasim can lead the Automation & Technology Readiness Assessment and leave the organisation with the evidence, options, readiness conditions and operating ownership. If the issue is narrow and the evidence is trusted, internal execution or a focused specialist is more proportionate. Any later discovery, proof, transformation, implementation, operation or scale phase requires a separate evidence gate and scope.

An external partner must disclose implementation, platform, reseller, referral and supplier interests. It may propose a follow-on phase, but it may not approve its own readiness finding, accept the organisation’s risk or mark its own implementation as successful.

Conditions that stop or narrow the work

Stop, contain or re-charter when:

• access, observation or testing would breach law, contract, privacy, security, safety or employee/customer protection;
• an immediate material harm or control failure requires a specialist incident route;
• leadership will not name the decision, owner, date or evidence threshold;
• the workflow owner cannot make participants or records available and no valid alternative evidence exists;
• the mandate excludes remove, simplify, existing-system, no-build or stop options;
• the candidate would rely on prohibited data, unbounded permissions or an unowned high-consequence action;
• evidence cannot establish a defensible baseline and leadership will not fund a bounded validation step;
• an operating owner, support route or capacity cannot be named;
• further assessment burden exceeds the value of the decision it could improve.

A stop disposition must record the reason, evidence, accepted exposure, containment where required, owner and condition for restart.

Decision and escalation route

Questions for evaluating a provider

1. Which bounded investment or operating decision will your assessment resolve?
2. How will you connect the workflow to a customer, service or business commitment before assessing technology?
3. How will you observe real tasks, handoffs, exceptions, controls and workarounds rather than rely on workshops alone?
4. Which current uses, embedded features, pilots, suppliers, permissions and incidents will you inventory?
5. How will you separate a process, ownership, policy, data or control problem from a technology gap?
6. Which non-build, simplify, existing-system, deterministic automation and human-augmentation alternatives will you compare?
7. How will you define what a candidate may read, transform, recommend, generate or execute?
8. Which evidence will support value, workflow, data, architecture, governance and operating-readiness conclusions?
9. How will you model failure, detectability, reversibility, affected people and human authority?
10. How will finance, information, security, employee/customer and operating owners approve their conditions?
11. What would make you recommend validation, enabling work, deferral or stop rather than a proof?
12. Which definitions, evidence, runbooks and decision records remain usable by another qualified team?
13. What is included in the assessment, and what implementation, procurement or assurance work would be separately scoped?

3. The Step-by-Step Execution Standard

Run the sequence against one bounded decision. Where candidates have materially different workflows, users, data, permissions, consequences or owners, keep separate use-case records and connect shared dependencies at portfolio level.

Step 01: Charter the investment and change decision

Purpose and decision served Turn an automation or AI mandate into one dated question about what should change and whether a bounded opportunity may progress, needs validation, should defer or must stop.

Accountable owner COO or equivalent operating executive; the economic buyer accepts the investment boundary and final forum.

Delegated lead and contributors Assessment lead facilitates. CIO/CTO, finance, workflow, customer/service, data, security, people, procurement and risk owners contribute only where the decision requires them.

Preconditions, inputs and access A recognisable mandate or workflow condition, authorised sponsor, affected customer or service commitment, known constraints, current budget or investment question and calendar of the decision forum.

Actions

1. Write the important decision using the Section 1 pattern.
2. Name the affected customer, service, employee or operating outcome and the primary value-path transition.
3. Define workflow, business-unit, market, system, supplier, data, people and time boundaries.
4. Record suspected causes without treating automation, AI or any supplier as the finding.
5. State economic lenses, material exclusions, conflicts, specialist authorities and no-action exposure.
6. Agree the evidence threshold, expected artefacts, burden limit, decision date and allowed dispositions.

Evidence to retain Sponsor-approved charter, decision statement, scope map, market/service connection, conflict declaration, exclusions and approval reference.

Decision or scoring rule Proceed only when one important decision, one owner, one date, one bounded workflow and one affected outcome are explicit. Otherwise disposition is change, validate, defer or stop.

Output and template The Automation and Technology Readiness Assessment: An Executive Standard for Choosing What Should Change readiness charter and current-use register, beginning with Charter and Authority rows.

Acceptance gate Proceed when the sponsor confirms that contrary evidence can change or stop the mandate; otherwise change, defer or stop.

Leadership checkpoint The sponsor confirms that remove, simplify, existing-system, no-build and stop routes remain available.

Human control point A named executive approves scope, risk appetite, evidence authority and final decision rights. No tool or supplier defines its own mandate.

Failure modes and safeguards Failures include enterprise-wide scope, a model or platform question, no downstream outcome and a decision already made. Safeguard with one sentence, one workflow boundary and explicit alternatives.

Change, stop or escalation condition Re-charter if evidence changes the affected need, workflow or consequence. Stop if leadership wants procurement justification rather than a real decision.

Handoff to the next step Pass the approved charter, decision date and conflicts to responsibility and evidence-authority design.

Step 02: Assign authority and evidence boundaries

Purpose and decision served Create one accountable route for workflow, technology, information, people, risk and investment decisions before sensitive evidence or candidate design begins.

Accountable owner COO owns the end-to-end assessment; CIO/CTO and other authorised executives retain technical, information, security, people and financial mandates.

Delegated lead and contributors Assessment lead drafts the responsibility map. Workflow, finance, data, architecture, security, privacy, customer/service, people, procurement and supplier owners define their authority.

Preconditions, inputs and access Approved charter, organisation and supplier structure, decision forums, source inventory, policies, contractual limits, information classifications and known current uses.

Actions

1. Assign sponsor, decision owner, assessment lead, workflow owner, evidence coordinator, technical owner, information authority, security/risk owner, people authority, benefit owner and operating owner.
2. Record who may approve observation, evidence access, personal or confidential information use, technical testing, supplier contact and employee participation.
3. Define who may change scope, accept a limitation, approve a proof, contain an incident and make a stop or scale decision.
4. Record supplier, platform, budget, prior-decision and implementation conflicts with mitigation or recusal.
5. Establish the controlled working environment, least-privilege access, copying, retention, deletion and incident route.
6. Identify legal, privacy, security, employment, sector, financial or assurance conclusions that require qualified review.

Evidence to retain Responsibility and decision-rights map, access approvals, conflict register, evidence-handling route, escalation map and authority acceptance.

Decision or scoring rule Every decision-critical responsibility must have one accountable owner and an escalation route. Shared contribution does not replace accountable authority.

Output and template The Automation and Technology Readiness Assessment: An Executive Standard for Choosing What Should Change readiness charter and current-use register, using Authority, Access and Conflict rows.

Acceptance gate Proceed when all material access, risk, information and decision authorities are named; otherwise narrow, validate, defer or stop.

Leadership checkpoint The sponsor resolves ownership gaps and protects participant capacity before fieldwork.

Human control point Named authorities approve evidence use and retain risk, legal, privacy, security, employee and customer accountability.

Failure modes and safeguards Failures include “IT owns everything”, shared accountability with no decision right, external self-authorisation and copying unrestricted evidence. Safeguard with explicit authority rows and least-privilege handling.

Change, stop or escalation condition Pause any unauthorised or unsafe access. Escalate an ownership conflict that could reverse the decision.

Handoff to the next step Pass the approved authority and evidence route to current-use inventory.

Step 03: Inventory current automation and technology use

Purpose and decision served Establish what is already operating, being tested, embedded, contracted or worked around so leadership does not assess a fictional starting point.

Accountable owner CIO/CTO for technology inventory; COO and workflow owners for operating use; procurement and finance for commitments.

Delegated lead and contributors Evidence coordinator, application and architecture owners, information security, procurement, finance, process participants, service desk and supplier managers.

Preconditions, inputs and access Approved authority, application and supplier inventories, procurement records, expense or licence evidence, workflow observation access, incident records and a safe route for participants to disclose workarounds.

Actions

1. Register each in-scope approved system, embedded feature, automation, AI use, proof, custom tool and material manual workaround as a separate record.
2. Record purpose, workflow, owner, users, supplier, status, data handled, integrations, permissions, allowed actions and business criticality.
3. Record cost basis, contract boundary, renewal or exit condition and support owner without inventing total cost.
4. Record evaluation method, monitoring, incidents, complaints, overrides, failure route and operating evidence where available.
5. Distinguish approved, restricted, unapproved, unknown, retired and proposed use; do not label a use “shadow” without evidence.
6. Reconcile the register with workflow participants and source owners rather than relying on the formal application list alone.
7. Contain or escalate a material unsafe use through the authorised route; do not wait for the final assessment.

Evidence to retain Current-use records, source references, owner confirmations, contract and permission evidence, incident references, workarounds, discrepancies and containment decisions.

Decision or scoring rule A current-use record is complete only when its workflow, owner, data, permission, action, supplier or support boundary and operating status are explicit or visibly unknown.

Output and template The Automation and Technology Readiness Assessment: An Executive Standard for Choosing What Should Change readiness charter and current-use register, using Current use and Commitment rows.

Acceptance gate Proceed when every material current use and known commitment has an owner and disposition; otherwise validate, contain, narrow or stop.

Leadership checkpoint COO and CIO/CTO review duplication, unowned uses, commitments and immediate control gaps before new opportunities are added.

Human control point Named risk and operating owners decide containment. Participant disclosure is handled without punitive inference or unnecessary personal-data capture.

Failure modes and safeguards Failures include treating procurement records as actual use, treating demonstrations as production, omitting embedded features and exposing participants who identify unsafe workarounds. Safeguard with multiple sources and controlled disclosure.

Change, stop or escalation condition Escalate unowned high-consequence use, prohibited access or a material incident immediately. Re-scope if current use changes the investment question.

Handoff to the next step Pass the charter, current-use register and immediate controls to workflow observation.

Step 04: Observe the workflow and market connection

Purpose and decision served Understand what the work actually does for customers and the organisation before treating manual effort or delay as a technology gap.

Accountable owner Workflow owner; customer or service owner accepts the intended outcome and recipient.

Delegated lead and contributors Process researcher or analyst, frontline participants, customer/service representative, data analyst, control owner, accessibility or human-factors specialist where relevant, and assessment lead.

Preconditions, inputs and access Approved charter and observation route, current-use register, process documentation, representative work, participants, exception and complaint evidence, service commitments and customer or user research.

Actions

1. Observe representative work from trigger to accepted output and downstream handoff.
2. Map tasks, decisions, inputs, systems, owners, queues, handoffs, exceptions, rework, controls, outputs and recipients.
3. Compare documented and observed work; retain both when they differ.
4. Ask which step creates customer or service value, satisfies a control, compensates for a defect or no longer has a defensible purpose.
5. Observe how participants identify ambiguity, recover errors, seek approval and use workarounds.
6. Connect the workflow to customer, service, quality, capacity and operating evidence without inferring intent from system traces alone.
7. Record accessibility, employee, customer and safety conditions requiring specialist review.

Evidence to retain Dated observations, workflow nodes, source references, participant roles, representative exceptions, documentation differences, customer/service evidence and stated limitations.

Decision or scoring rule A workflow node remains in the readiness boundary only when its trigger, owner, input, action or decision, output, recipient, exception and purpose are explicit or visibly unresolved.

Output and template The Automation and Technology Readiness Assessment: An Executive Standard for Choosing What Should Change workflow evidence and readiness register, beginning with Workflow node, Handoff and Observation rows.

Acceptance gate Proceed when the real workflow and affected market/service connection are accepted by participants and owners; otherwise validate, narrow or stop.

Leadership checkpoint The COO sees where work is necessary, compensatory, duplicated, disputed or unowned before intervention ideas are assessed.

Human control point Process participants and affected customer/employee authorities validate observation context; the analyst does not declare human judgement unnecessary.

Failure modes and safeguards Failures include workshop-only maps, happy-path process diagrams, individual blame, automation of obsolete work and system logs treated as the full human process. Safeguard with direct observation, exceptions and participant review.

Change, stop or escalation condition Contain immediate harm. Re-charter when the observed workflow serves a different commitment or crosses a material boundary excluded from scope.

Handoff to the next step Pass accepted workflow nodes, handoffs, exceptions and evidence gaps to baseline reconciliation.

Step 05: Establish and reconcile the workflow baseline

Purpose and decision served Define the current condition well enough to distinguish a material constraint from a persuasive anecdote and to measure a later proof without reconstructed precision.

Accountable owner Workflow owner for operating definitions; finance or service-value owner accepts material economic definitions; source owners accept technical lineage.

Delegated lead and contributors Data or process analyst, evidence coordinator, finance analyst, customer/service owner, quality or control owner, workforce representative where required, and source-system specialists.

Preconditions, inputs and access Accepted workflow map, source inventory, task and exception records, service or customer evidence, time and effort records where available, finance or cost basis, quality definitions and authorised access.

Actions

1. Select only the baseline measures needed for the chartered decision, such as eligible demand or case volume, cycle and wait time, quality, exceptions, rework, skilled effort, service outcome, cost basis or capacity.
2. Define unit, population, denominator, period, exclusions, source, owner and natural value-realisation lag for each measure.
3. Reconcile workflow records with authoritative operational, finance, customer or service evidence where the consequence is material.
4. Separate active work, waiting, checking, exception handling, rework, support and downstream burden rather than treating elapsed time as labour released.
5. Record missing populations, manual adjustments, changed definitions, sampling, unmatched records and source limitations.
6. Mark interview statements, estimates, calculated values and direct observations with the correct evidence and public claim status.
7. State baseline required rather than reconstructing a precise value from incompatible records.

Evidence to retain Metric definitions, source and query references, accepted period and population, reconciliation workpapers, exception sample, effort or cost basis, limitations and owner approvals.

Decision or scoring rule A baseline is decision-grade only when definition, unit, period, population, source, owner, exclusions and limitation are explicit. An estimate may guide validation but may not be presented as verified operating or commercial exposure.

Output and template The Automation and Technology Readiness Assessment: An Executive Standard for Choosing What Should Change workflow evidence and readiness register, using Baseline, Evidence and Limitation rows linked to workflow IDs.

Acceptance gate Proceed when the baseline can support the readiness decision or the sponsor accepts a bounded validation plan; otherwise narrow, validate, defer or stop quantification.

Leadership checkpoint COO and finance accept what the baseline can and cannot establish, including whether claimed capacity could become usable capacity.

Human control point Business and finance owners approve meaning; source owners approve lineage; qualified authorities approve personal, employee and customer evidence use.

Failure modes and safeguards Failures include invented precision, total elapsed time treated as labour, supplier savings used as the organisation’s baseline, open work mixed with completed work and quality omitted. Safeguard with explicit definitions and workload displacement.

Change, stop or escalation condition Escalate a source or definition conflict that could reverse the investment decision. Stop quantified claims when no compatible baseline exists.

Handoff to the next step Pass the accepted workflow, baseline, exceptions and limitations to root-cause diagnosis.

Step 06: Diagnose what should be removed, simplified or enabled

Purpose and decision served Identify why the workflow is constrained before defining technology, and decide which work or control should change first.

Accountable owner Workflow owner; COO accepts the material diagnosis and cross-functional consequence.

Delegated lead and contributors Process analyst or improvement lead, participants, customer/service owner, control and quality owners, finance analyst, data and technology specialists, and independent challenger.

Preconditions, inputs and access Observed workflow, accepted baseline, current-use register, exceptions, rework, service evidence, controls, participant explanations and source limitations.

Actions

1. Classify each material constraint as unnecessary work, unclear commitment, policy or decision ambiguity, ownership, queue or capacity, exception design, information quality, access, integration, system behaviour, control design, capability or another evidenced cause.
2. Write the condition, affected transition, evidence, customer or operating consequence, potential economic lens, likely cause, alternatives and uncertainty.
3. Test whether removing, stopping, clarifying, simplifying, standardising or reassigning work addresses the cause without new technology.
4. Separate a necessary control from duplicated checking and distinguish human judgement from undocumented routine.
5. Test participant, customer, finance, technology and control-owner explanations against observation and records.
6. Identify conditions that must stabilise before any proof, including definitions, ownership, source quality, exception policy or service capacity.
7. Reject technical observations that do not change the chartered decision.

Evidence to retain Root-cause findings, workflow and evidence IDs, alternative explanations, participant challenge, control purpose, rejected observations, enabling conditions and proof status.

Decision or scoring rule A finding is decision-grade only when it names the value-path transition, survives a credible alternative explanation, states uncertainty and could change what leadership funds. Otherwise classify it REQUIRES VALIDATION.

Output and template The Automation and Technology Readiness Assessment: An Executive Standard for Choosing What Should Change workflow evidence and readiness register, using Finding, Root cause and Enabling condition rows.

Acceptance gate Proceed when the decision owner accepts a bounded cause or a specific validation route; otherwise change, validate, defer or stop.

Leadership checkpoint The sponsor challenges whether a non-build action resolves the material constraint and whether the original mandate should change.

Human control point Participants and owners accept the workflow facts; the executive owner accepts the diagnosis. No automated process-mining or scoring tool declares a root cause.

Failure modes and safeguards Failures include automating obsolete work, blaming participants, confusing correlation with cause, treating every exception as waste and protecting a preferred platform. Safeguard with evidence links, alternatives and owner challenge.

Change, stop or escalation condition Return to observation or baseline work when an alternative could reverse the finding. Stop the technology path if remove, simplify or clarify resolves the decision at lower burden.

Handoff to the next step Pass accepted causes, enabling conditions and no-build routes to candidate-intervention design.

Step 07: Define bounded intervention alternatives

Purpose and decision served Translate an accepted constraint into proportionate options without selecting a technology category before permissions, value and operating consequences are explicit.

Accountable owner Workflow owner for the work outcome; CIO/CTO for the technical boundary; COO owns the investment choice.

Delegated lead and contributors Process designer, architect, data owner, security and information authorities, customer/service and people representatives, finance, procurement, subject specialists and assessment lead.

Preconditions, inputs and access Accepted finding, workflow and baseline, current uses, control purposes, source/data boundaries, affected people, architecture context, supplier commitments and constraints.

Actions

1. Create applicable alternatives across stop/remove, policy or ownership clarification, workflow simplification, existing-system configuration, information improvement, deterministic automation, human augmentation, bounded AI assistance and controlled multi-step execution.
2. Include retain-and-monitor, do-nothing, defer and enabling-work routes.
3. State the causal mechanism linking each option to the accepted workflow constraint.
4. Define exactly what the intervention may read, retrieve, transform, calculate, recommend, generate, approve, communicate or execute.
5. Define prohibited data, actions and recipients; human review, approval and override; and the consequence of an incorrect or unavailable result.
6. Record integration, identity, supplier, data, evaluation, logging, support, resilience, exit and operating assumptions at decision level without pretending to complete detailed architecture.
7. Identify the smallest reversible intervention that can test the material assumption.
8. Record displaced work, new verification, exception, training and support burden rather than counting task removal alone.

Evidence to retain Separate candidate records, causal mechanism, permission boundary, non-build alternatives, assumptions, prohibited use, human-control design, dependencies, displaced burden and dissent.

Decision or scoring rule An option remains eligible only when it addresses an accepted cause, has a bounded permission and operating model, retains human authority where required and can be validated or stopped safely.

Output and template The Automation and Technology Readiness Assessment: An Executive Standard for Choosing What Should Change intervention readiness and risk portfolio, beginning with Candidate and Alternative rows linked to Finding IDs.

Acceptance gate Proceed when at least one proportionate option and its no-build alternative are explicit; otherwise return to diagnosis, defer or stop.

Leadership checkpoint COO and CIO/CTO confirm that the option set is not a disguised procurement shortlist and that simpler interventions remain comparable.

Human control point Named business, technical, information, customer/employee and risk owners accept the proposed permission and decision boundaries within their mandates.

Failure modes and safeguards Failures include tool-category brainstorming, vague “human in the loop”, unbounded system access, no exit route and hidden verification burden. Safeguard with action verbs, prohibited actions and one owner per boundary.

Change, stop or escalation condition Stop an option that requires prohibited data, unreviewable high-consequence action, unavailable operating ownership or a permission level beyond accepted appetite.

Handoff to the next step Pass distinct candidates, permission boundaries, assumptions and alternatives to use-case readiness assessment.

Step 08: Assess readiness for each use case

Purpose and decision served Establish what must be true for each candidate to progress and prevent an enterprise-wide maturity average from hiding a material blocker.

Accountable owner COO as decision owner; each readiness-lens owner accepts the evidence and condition within their mandate.

Delegated lead and contributors Assessment lead coordinates. Finance/value, workflow, data, architecture, governance/risk, people/change, support and supplier owners evaluate separate conditions.

Preconditions, inputs and access Bounded candidate records, accepted finding and baseline, current-use evidence, workflow and data sources, architecture and integration context, policies, support capacity and affected-person evidence.

Actions

1. Assess each candidate separately across value, workflow, data and evidence, technology and architecture, governance and control, and operating capability.
2. For every lens, record the required condition, retained evidence, owner, limitation, dependency and disposition.
3. Distinguish a hard stop, enabling dependency, bounded validation need and acceptable limitation.
4. Test whether the workflow is stable enough for the proposed intervention while retaining necessary exceptions and judgement.
5. Test data fitness and permitted use at the candidate level, including source, quality, currency, access, identity, retention and prohibited data.
6. Test integration, identity, monitoring, resilience, supplier and exit assumptions only to the depth needed for the next decision.
7. Test adoption, support, incident, change, training, capacity and benefit ownership after delivery.
8. Keep every lens visible; do not add the ratings into an automatic readiness score.

Evidence to retain Readiness-condition rows, evidence IDs, owner decisions, blockers, accepted limits, enabling dependencies, dissent and per-use-case disposition.

Decision or scoring rule A candidate is not “ready” in the abstract. It may progress only when no material stop condition remains and the next phase has enough evidence, authority and operability; otherwise validate, enable, defer or stop.

Output and template The Automation and Technology Readiness Assessment: An Executive Standard for Choosing What Should Change intervention readiness and risk portfolio, using one Readiness condition row per candidate and lens.

Acceptance gate Proceed when every material lens has an accepted condition, owner and disposition; otherwise validate, enable, defer or stop.

Leadership checkpoint The executive group sees which blockers are use-case specific, which are shared across candidates and which make the original mandate inappropriate.

Human control point Each authorised owner accepts its evidence; the decision owner resolves the portfolio disposition. No composite score overrides a material veto or specialist authority.

Failure modes and safeguards Failures include generic maturity averages, evidence-free scoring, technology readiness substituting for workflow readiness, policy existence treated as control operation and named skills without allocated capacity. Safeguard with condition-level records.

Change, stop or escalation condition Return to evidence when a lens conclusion is unsupported. Stop a candidate when a hard constraint cannot be addressed proportionately.

Handoff to the next step Pass candidate readiness conditions, blockers, dependencies and dispositions to failure and control analysis.

Step 09: Model failure, consequence and human authority

Purpose and decision served Determine whether a candidate can fail, degrade or be misused within an acceptable and governable boundary before any proof is approved.

Accountable owner Relevant risk authority for consequence and appetite; workflow owner for operational impact; CIO/CTO for technical controls; executive sponsor accepts residual exposure.

Delegated lead and contributors Security, privacy/information, architecture, data, safety/quality, customer/service, people, supplier and domain specialists; assessment lead maintains the record.

Preconditions, inputs and access Candidate permission boundary, readiness conditions, workflow exceptions, affected people and decisions, data and supplier context, existing incidents, control policies and escalation routes.

Actions

1. Describe credible wrong, missing, delayed, duplicated, unauthorised, misleading or unavailable outputs and actions for the candidate.
2. Record affected people, customer/service and operating consequence, likelihood basis where evidence exists, detectability, reversibility, containment and escalation.
3. Test data exposure, identity and access misuse, prompt or input manipulation where relevant, integration failure, supplier outage, rule or model change, human over-reliance and workarounds.
4. For probabilistic or AI candidates, define evaluation examples, failure classes, human review, uncertainty handling and monitoring appropriate to the allowed action.
5. Set prohibited use, permission limits, approval points, logging, incident, rollback or kill route, retention and change-control requirements.
6. Distinguish control design from evidence that the control operates; mark untested effectiveness REQUIRES VALIDATION.
7. Route legal, privacy, employment, safety, security and sector conclusions to qualified authorities.
8. Record residual risk and the person authorised to accept, change, contain or stop it.

Evidence to retain Failure scenarios, affected-person analysis, source and incident references, permissions, controls, evaluation requirements, residual risk, specialist decisions, prohibited uses and escalation route.

Decision or scoring rule A candidate may progress only when every material failure has an owner, detection or review route, containment or stop path and an authorised residual-risk decision. An unbounded high-consequence action is a stop condition.

Output and template The Automation and Technology Readiness Assessment: An Executive Standard for Choosing What Should Change intervention readiness and risk portfolio, using Failure, Control, Prohibited use and Residual risk rows.

Acceptance gate Proceed when the candidate has a proportionate and testable control boundary; otherwise change, validate, defer or stop.

Leadership checkpoint The sponsor sees the consequence of failure and verification burden alongside the proposed value, not after funding.

Human control point Named authorities approve permissions, customer/employee protections and residual risk. Human review is defined as an accountable task with competence, time and escalation, not a label.

Failure modes and safeguards Failures include risk checklists detached from permissions, controls copied from policy, no degradation mode, an unavailable stop route and review work excluded from cost. Safeguard with scenario-to-control-to-owner traceability.

Change, stop or escalation condition Contain immediate risk. Stop a candidate whose material consequence cannot be detected, reversed, governed or accepted by the authorised owner.

Handoff to the next step Pass the readiness and control evidence to portfolio comparison and investment sequencing.

Step 10: Compare candidates and sequence the next decisions

Purpose and decision served Compare bounded candidates without allowing enthusiasm, a maturity average or a supplier demonstration to hide evidence, risk, dependency or no-action choices.

Accountable owner COO as decision owner; the economic buyer or authorised investment forum accepts funding and sequencing.

Delegated lead and contributors Assessment lead facilitates. Workflow, finance, technology, data, risk, people, customer/service, procurement and operating owners contribute evidence within their mandates.

Preconditions, inputs and access Accepted findings, candidate alternatives, per-lens readiness conditions, failure/control records, baselines, dependencies, current commitments, no-action exposure and capacity.

Actions

1. Compare customer or service relevance, operating and economic materiality, evidence strength, workflow readiness, data and technical feasibility, governance, operability, reversibility, dependency and time to learning.
2. Keep every criterion and rationale visible; do not multiply or add ratings into an automatic winner.
3. Apply material stop conditions before relative attractiveness.
4. Classify each candidate as progress, validate or enable first, defer or stop, with an owner and reason.
5. Record the no-action route, displaced investment, existing commitments and potential shared dependencies without assuming that shared technology should be built.
6. Identify which decision can be made now and which requires a deeper The Workflow Constraint and Root-Cause Audit: Simplify the Work Before Automating It root-cause, The Automation Opportunity Portfolio: A Value, Feasibility, Risk and Learning Playbook portfolio, The Automation Architecture Decision: Rules, Platforms, Agents, Custom Software or No Build architecture, The AI and Automation Governance Standard: Proportionate Control from Assistance to Autonomous Action governance or The Proof-of-Value Pilot Standard: Designing Automation Tests That Can Earn Production proof standard.
7. Separate use-case-specific dependencies from shared capability questions.
8. Record dissent and why a high-interest candidate is not ready.

Evidence to retain Criterion assessments, source IDs, hard stops, dispositions, dependency relationships, no-action route, dissent, handoff recommendation and rejected candidates.

Decision or scoring rule Progress only a candidate with an accepted value mechanism, no unresolved hard stop, named next-phase owner and measurable gate. A higher relative rating cannot cancel unlawful use, unbounded consequence or absent operating ownership.

Output and template The Automation and Technology Readiness Assessment: An Executive Standard for Choosing What Should Change intervention readiness and risk portfolio, using Portfolio disposition and Handoff rows.

Acceptance gate Proceed when every candidate has an evidence-linked progress, validate, defer or stop disposition and shared dependencies are explicit; otherwise return, narrow or defer.

Leadership checkpoint The executive forum confirms what will not be funded, what evidence comes next and whether a deeper follow-on standard is justified.

Human control point The authorised investment owner makes the sequence decision; specialist authorities retain veto and acceptance rights within their mandates.

Failure modes and safeguards Failures include one opaque score, high interest mistaken for value, shared architecture assumed too early, sunk cost protected and stopped ideas silently revived. Safeguard with separate criteria, stable IDs and recorded dispositions.

Change, stop or escalation condition Escalate a portfolio that exceeds funding or risk authority. Stop a candidate whose material blocker cannot be addressed proportionately.

Handoff to the next step Pass selected validation, enabling or progress candidates and their evidence conditions to next-gate design.

Step 11: Define the controlled validation or proof gate

Purpose and decision served Specify the evidence and controls a separately scoped discovery, enabling action or proof must provide before implementation or production can be considered.

Accountable owner Named next-phase business owner; COO owns the benefit question; CIO/CTO and risk authorities own applicable technical and control gates.

Delegated lead and contributors Assessment lead drafts the gate. Workflow, research, process, architecture, data, security, information, people, finance, evaluation and operating owners define requirements.

Preconditions, inputs and access Selected candidate and disposition, accepted baseline, readiness blockers, permission boundary, failure scenarios, dependencies, authorised resources and intended next-phase scope.

Actions

1. State the unresolved assumption and the decision that new evidence must enable.
2. Choose the smallest suitable next action: evidence repair, workflow discovery, enabling dependency, low-risk validation, controlled proof or stop.
3. Define eligible users, cases or workflow boundary, baseline, evaluation evidence, implementation evidence, operating adoption, outcome and guardrail measures.
4. Define what the next phase may read, transform, recommend, generate or execute and where named human approval remains mandatory.
5. Define delivery, evidence, quality, control, operability and handover acceptance gates.
6. Define monitoring, exception, incident, containment, rollback or shutdown, supplier and support requirements at decision level.
7. State what cannot be learned from the proposed next phase and what remains REQUIRES VALIDATION.
8. Route a full proof design and execution to The Proof-of-Value Pilot Standard: Designing Automation Tests That Can Earn Production; this assessment records the commissioning gate, not proof completion.

Evidence to retain Next-gate brief, assumption, evidence plan, measure definitions, permission and control conditions, authorised scope, handoff target, exclusions and stop route.

Decision or scoring rule A next phase is commissionable only when its evidence can resolve the stated decision, material harm can be contained, ownership exists and completion cannot be misrepresented as value.

Output and template The Automation and Technology Readiness Assessment: An Executive Standard for Choosing What Should Change investment, proof and decision register, beginning with Validation plan, Measure and Gate rows.

Acceptance gate Proceed when every mandatory evidence, authority, control, operating and handoff condition is approved; otherwise change, defer or stop.

Leadership checkpoint The sponsor accepts the cost and burden boundary, the possibility of an inconclusive result and the stop route.

Human control point Named business, technical, information, customer/employee and risk owners approve the next gate. A tool or supplier cannot expand scope automatically.

Failure modes and safeguards Failures include a demonstration presented as proof, no baseline, no evaluation population, several uncontrolled changes, no operating evidence and implementation implied by readiness. Safeguard with decision-specific gates and explicit exclusions.

Change, stop or escalation condition Do not commission when a mandatory owner, baseline, permission, control or containment route is absent. Re-design when the proposed evidence cannot answer the decision.

Handoff to the next step Pass the complete readiness portfolio and next-gate briefs to the executive decision forum.

Step 12: Make the executive decision and transfer ownership

Purpose and decision served Turn the assessment into authorised dispositions, resource conditions and explicit handoffs without implying that readiness approval is implementation approval.

Accountable owner Named executive decision owner; economic buyer accepts investment; benefit and operating owners accept ongoing accountability.

Delegated lead and contributors Assessment lead presents. COO, CIO/CTO, CFO or finance delegate, workflow, data, security, information, people, customer/service, procurement and risk owners participate as required.

Preconditions, inputs and access Charter, current-use register, workflow and baseline evidence, findings, candidates, readiness and risk conditions, portfolio dispositions, next-gate briefs, dissent and decision authority.

Actions

1. Present the customer or service commitment, workflow constraint and evidence limits before the candidate recommendation.
2. State what is VERIFIED, INFERRED, PROPOSED and REQUIRES VALIDATION.
3. Record each disposition as progress, validate or enable, defer or stop.
4. Record rejected options, dissent, accepted exposure, prohibited uses and reasons.
5. Assign one owner, authorised resource boundary, first dated gate, measure owners and escalation route for every approved next action.
6. Transfer definitions, evidence, permission boundary, controls, dependencies, current commitments and open issues to the next-phase owner.
7. Route deeper work explicitly: The Workflow Constraint and Root-Cause Audit: Simplify the Work Before Automating It root cause, The Automation Opportunity Portfolio: A Value, Feasibility, Risk and Learning Playbook portfolio, The Automation Architecture Decision: Rules, Platforms, Agents, Custom Software or No Build architecture, The AI and Automation Governance Standard: Proportionate Control from Assistance to Autonomous Action governance or The Proof-of-Value Pilot Standard: Designing Automation Tests That Can Earn Production proof.
8. Confirm that procurement, build, deployment, production and scale remain unapproved unless a later gate expressly authorises them.

Evidence to retain Decision paper, forum record, dispositions, funding or resource conditions, prohibited uses, dissent, owner acceptance, handover inventory and next review dates.

Decision or scoring rule No candidate progresses without one authorised disposition, one accountable owner, one dated evidence gate, mandatory specialist authority and an explicit change or stop route.

Output and template The Automation and Technology Readiness Assessment: An Executive Standard for Choosing What Should Change investment, proof and decision register, with separate Decision, Handover and Gate rows.

Acceptance gate Proceed only when the decision and handover are traceably accepted; otherwise validate, defer or stop remains the recorded result.

Leadership checkpoint The forum confirms what is approved now, what remains conditional and which candidates are closed.

Human control point Executives make business and investment decisions; qualified authorities retain legal, privacy, security, employee, customer and risk decisions; future implementers cannot self-approve.

Failure modes and safeguards Failures include verbal approval, “ready” treated as procurement authority, unowned enabling work, hidden dissent and artefacts handed off without evidence limits. Safeguard with separate decision, measure, gate and handover rows.

Change, stop or escalation condition Do not start a next phase without accepted ownership and mandatory authority. Escalate any later scope, permission, supplier, data or investment change.

Handoff to the next step Pass the authorised decision register and handover pack to the named review cadence.

Step 13: Review evidence and decide whether to change, stop or scale

Purpose and decision served Keep the readiness decision current as validation, enabling work or a proof produces evidence, and prevent a successful demonstration from becoming ungoverned production.

Accountable owner Benefit owner for the intended outcome; operating owner for work and adoption; executive decision owner for continue, stop or scale.

Delegated lead and contributors Measurement owner collects agreed evidence. Workflow, technology, data, finance, customer/service, people, support and risk owners explain results and act on decisions.

Preconditions, inputs and access Accepted baseline and measures, approved next-gate plan, implementation/evaluation records where applicable, operating and adoption evidence, incidents and exceptions, guardrails and decision authority.

Actions

1. Confirm that the validation or proof ran within the approved workflow, population, permission, data, supplier and control boundary.
2. Review evidence quality and gate completion before interpreting value.
3. Separate technical or evaluation performance, workflow adoption, customer/service outcome, usable capacity and guardrails.
4. Record rework, verification, exception, support, change and displaced burden.
5. State attribution limits, concurrent changes, missing evidence, lag and unexpected effects.
6. Review incidents, prohibited-use attempts, overrides and affected customer or employee consequences.
7. Decide continue, change, hold, stop or progress to the next separately approved gate.
8. Approve scale only after the relevant The Proof-of-Value Pilot Standard: Designing Automation Tests That Can Earn Production production evidence, The AI and Automation Governance Standard: Proportionate Control from Assistance to Autonomous Action governance, The Automation Architecture Decision: Rules, Platforms, Agents, Custom Software or No Build architecture and operating conditions exist; readiness alone cannot authorise scale.
9. Update the current-use register, workflow, readiness conditions, decision record and learned constraints.

Evidence to retain Gate results, evaluation and operating evidence, measure records, incidents, exceptions, verification burden, dissent, review decision, change history and updated operating artefacts.

Decision or scoring rule Continue or progress only when all mandatory outcome, control, operability and evidence gates pass. A delivered integration, licence activation or model response is not a business outcome.

Output and template The Automation and Technology Readiness Assessment: An Executive Standard for Choosing What Should Change investment, proof and decision register, with dated Measure, Review, Change and Stop rows.

Acceptance gate Continue or progress only when mandatory gates pass; otherwise change, hold or stop and record the restart condition.

Leadership checkpoint The executive forum reviews the commitment-to-service value path, usable capacity, operating burden and guardrails rather than technical activity alone.

Human control point Named humans accept evidence interpretation, residual risk, funding and any later production or scale decision. Tools calculate agreed measures but do not change the gate.

Failure modes and safeguards Failures include demo-to-production drift, changed denominators, early benefit claims, unrecorded support effort, employee workarounds and controls assumed from design. Safeguard with frozen definitions, separate measures and dated human decisions.

Change, stop or escalation condition Contain material harm immediately. Re-charter when the workflow, permissions, supplier or value mechanism changes. Stop when exposure exceeds appetite or evidence no longer supports the intervention.

Handoff to the next step Transfer accepted learning into workflow ownership, technology and governance standards, investment sequencing and the next charter; close stopped candidates with their evidence and restart conditions intact.

4. The Evidence & Measurement Checklist

Copy the relevant tests into the assessment record. A checked box means the named evidence exists and the named owner has accepted it; it is not a readiness score or an assurance opinion.

Preflight and authority

• One bounded investment or change decision has a named executive owner and date. Evidence: approved readiness charter. Owner: COO or named decision owner.
• The affected customer or service commitment and commitment-to-service value path are explicit. Evidence: charter and value-path record. Owner: workflow and customer/service owners.
• Workflow, technical, information, risk, people, benefit and operating owners have accepted their roles. Evidence: responsibility and authority rows. Owner: executive sponsor.
• Scope, material exclusions, dependencies, conflicts and burden limits are approved. Evidence: charter control fields. Owner: assessment lead.
• Remove, simplify, existing-system, no-build, defer and stop routes remain available. Evidence: sponsor decision statement. Owner: executive sponsor.
• The organisation has authority and capacity to act on at least one plausible finding. Evidence: capacity and decision-rights confirmation. Owner: executive sponsor.

Evidence access and quality

• Every material evidence item has a source, owner, period, population, decision use and access authority. Evidence: workflow evidence and readiness register. Owner: evidence coordinator.
• Each current use or commitment records workflow, users, data, permissions, allowed actions, supplier and operating status. Evidence: current-use register. Owner: CIO/CTO delegate.
• The observed workflow includes triggers, decisions, handoffs, exceptions, controls, outputs and recipients. Evidence: accepted workflow records. Owner: workflow owner.
• Baselines define unit, denominator, period, exclusions, source, owner and known limitation. Evidence: baseline rows and workpapers. Owner: metric owners.
• Direct observation, participant statements, calculations, assumptions, evidence gaps and constraints are classified correctly. Evidence: classified evidence records. Owner: proof owner.
• Conflicting sources and incompatible definitions remain visible with a reconciliation disposition. Evidence: evidence limitation and reconciliation rows. Owner: assessment lead.

Method execution

• Current use is reconciled across formal inventories, operating evidence and participant accounts. Evidence: current-use discrepancy review. Owner: CIO/CTO and workflow owners.
• Representative work and material exceptions are observed rather than inferred from process documentation alone. Evidence: dated observation records. Owner: process lead.
• Every material finding links workflow evidence to a customer or operating consequence and alternative explanation. Evidence: root-cause finding rows. Owner: assessment lead.
• Every candidate includes remove, simplify or no-build consideration and a causal value mechanism. Evidence: candidate and alternative rows. Owner: workflow owner.
• Each candidate is assessed separately across all six readiness lenses with owners and evidence. Evidence: readiness-condition records. Owner: assessment lead.
• Failure, permission, human-control, containment and residual-risk conditions are linked to each progressing candidate. Evidence: risk and control rows. Owner: risk owner.

Governance, privacy, security and risk

• Evidence collection and observation use approved lawful, ethical and least-privilege routes. Evidence: access and authority records. Owner: information and people authorities.
• Personal, confidential, employee and customer information is limited to what the decision requires. Evidence: information-boundary record. Owner: information officer or delegated authority.
• Allowed read, transform, recommend, generate, approve, communicate and execute actions are explicit. Evidence: candidate permission boundary. Owner: technical and workflow owners.
• Prohibited data, uses, actions and recipients are recorded for every material candidate. Evidence: prohibited-use rows. Owner: risk and information owners.
• Material failures have detection, human review, containment, incident and stop routes. Evidence: failure-control register. Owner: relevant risk authority.
• Legal, privacy, security, employment, safety, financial and sector conclusions are routed to qualified authorities. Evidence: specialist-review decision. Owner: executive sponsor.

Deliverables and acceptance

• The charter and current-use register are accepted and versioned. Evidence: approval and change references. Owner: COO and CIO/CTO.
• The workflow map and baseline expose exceptions, displaced burden and evidence limitations. Evidence: accepted workflow and baseline pack. Owner: workflow and finance owners.
• The finding set states what should be removed, simplified, clarified, enabled or validated before technology. Evidence: finding acceptance record. Owner: decision owner.
• Candidate options include permission boundaries, non-build alternatives, dependencies and operating conditions. Evidence: intervention portfolio. Owner: assessment lead.
• Every candidate has an evidence-linked progress, validate, defer or stop disposition. Evidence: portfolio disposition rows. Owner: executive decision owner.
• Every approved next phase has a bounded evidence gate and the correct The Workflow Constraint and Root-Cause Audit: Simplify the Work Before Automating It–The Proof-of-Value Pilot Standard: Designing Automation Tests That Can Earn Production handoff. Evidence: decision and handover register. Owner: next-phase owner.

Measurement

• Learning, delivery, operating, outcome and guardrail measures are kept separate. Evidence: measurement-contract rows. Owner: measurement owner.
• Every measure defines unit, denominator, period, population, exclusions, source, owner and lag. Evidence: versioned metric definition. Owner: metric owner.
• Baselines use compatible accepted evidence or state baseline required. Evidence: baseline approval record. Owner: finance and workflow owners.
• Evaluation evidence is representative of the approved use and records failure classes and limitations. Evidence: evaluation-plan and result rows. Owner: evaluation owner.
• Capacity or cost claims include verification, exception, support and displaced-work burden. Evidence: net-burden workpaper. Owner: finance and operating owners.
• Thresholds name the continue, change, hold, stop or next-gate response. Evidence: approved gate rows. Owner: decision owner.

Decision and handover

• Each candidate disposition is explicitly progress, validate or enable, defer or stop. Evidence: executive decision rows. Owner: decision owner.
• Rejected alternatives, dissent, accepted exposure and prohibited uses are retained. Evidence: decision and dissent record. Owner: executive sponsor.
• Every approved action has one owner, authorised resources and a dated evidence gate. Evidence: action and gate rows. Owner: next-phase owner.
• Definitions, evidence, permissions, controls, dependencies and open issues transfer with accepted limitations. Evidence: signed handover inventory. Owner: operating or next-phase owner.
• Readiness approval is separated from procurement, build, deployment, production and scale authority. Evidence: decision-scope statement. Owner: executive decision owner.
• Internal execution, focused specialist support or cross-functional assessment is selected proportionately. Evidence: delegation and sourcing decision. Owner: executive sponsor.

Review, change and stop controls

• Every validation, enabling action or proof has a dated continue, change, hold or stop review. Evidence: review gate record. Owner: benefit owner.
• Material harm, prohibited use or control failure triggers containment and named human review. Evidence: incident and decision record. Owner: risk owner.
• Workflow, data, permission, supplier, population or measure changes trigger revalidation where material. Evidence: change assessment. Owner: operating owner.
• Stopped and deferred candidates retain reasons, accepted exposure and restart conditions. Evidence: decision register. Owner: decision owner.
• Current-use and readiness records are updated when new evidence changes the operating position. Evidence: version history. Owner: register owner.
• Production or scale requires the separately approved architecture, governance, proof and operating gates relevant to the candidate. Evidence: next-phase approval record. Owner: investment forum.

Topic-specific measurement contract

Do not create one automation-readiness percentage. Select the smallest set of measures that can answer the chartered decision, and retain the workflow unit, value mechanism, baseline, displaced burden and attribution limits.

Measure A: Decision-grade readiness evidence coverage

Measure B: Readiness dependency gate completion

Measure C: Candidate evaluation acceptance by failure class

Measure D: Correct operating use and exception adherence

Measure E: Named workflow or service transition performance

Measure F: Net usable capacity or operating burden

Measure G: Material readiness or intervention guardrail breaches

Evidence classifications used in this guide

For engagement evidence, separately classify observed fact, corroborated interpretation, single-source statement, assumption, evidence gap and constraint. A VERIFIED record that a person made a statement does not make the statement’s explanation a verified cause.

Sources and proof boundaries

• Abrasim six-lens readiness model and execution sequence: PROPOSED Abrasim working methodology. It is a decision structure, not proof that a use case is ready, a control operates or an intervention creates value.
• NIST: Artificial Intelligence Risk Management Framework 1.0: VERIFIED official framework source at the 25 August 2026 source cut-off. NIST describes it as voluntary, rights-preserving, non-sector-specific and use-case agnostic. This guide borrows risk disciplines without claiming NIST certification or conformity.
• NIST: AI Risk Management Framework current programme page: VERIFIED official status source at the source cut-off. It states that AI RMF 1.0 is being revised. Any later publication must recheck the applicable current version rather than freezing this draft’s source state.
• NIST: Generative Artificial Intelligence Profile, NIST AI 600-1: VERIFIED official companion source at the source cut-off. It is relevant only when generative AI is intrinsic to the candidate and does not make its suggested actions mandatory for every automation or prove a particular control effective.
• Protection of Personal Information Act 4 of 2013: VERIFIED official South African statutory source. It establishes conditions governing processing of personal information, including accountability, purpose, information quality and security safeguards. Application to a particular workflow, automated decision or data transfer requires the organisation’s information officer or qualified legal/privacy reviewer.
• Information Regulator South Africa: POPIA resources: VERIFIED official regulator resource at the source cut-off. It is a route to current regulator material, not a substitute for an organisation-specific legal or information-officer decision.
• OECD: The Adoption of Artificial Intelligence in Firms: VERIFIED institutional research source published in 2025. Its survey and interview evidence provides context on adoption inputs and constraints; it does not establish readiness, value or adoption conditions for a South African organisation or this use case.
• GOV.UK Service Manual: How the discovery phase works: VERIFIED government service guidance at the source cut-off. It supports problem, user, constraint, alternative and stop thinking before build; its public-service context must be adapted and is not a universal corporate delivery standard.

The Leadership Audit Working Pack remains the shared governance layer. The Automation and Technology Readiness Assessment: An Executive Standard for Choosing What Should Change adds current-use, workflow, readiness, permission, failure, dependency, proof-gate and operating evidence. Keep stable assessment, decision, evidence, workflow, finding, candidate, risk, control and gate IDs across the files; keep one material evidence item per evidence row; and separate decisions, measures, gates and reviews.