The Automation Architecture Decision: Rules, Platforms, Agents, Custom Software or No Build

Choose how the work should be done before choosing technology. An unsuitable tool can add integrations, cost and support work, or automate a process that would be better simplified or stopped.

This guide helps a CIO or CTO and COO choose, for one accepted workflow opportunity, among no build, direct process change, deterministic rules, configuration in an existing platform, AI assistance, bounded agentic action, purchased software and custom software. It produces an evidence-bounded architecture disposition. It does not approve governance, procurement, funding, a pilot, production release or scale.

1. The Market Connection Context

The recognisable condition is solution-first pressure: a supplier demonstration, an AI mandate, an expiring platform, a custom-build request or an automation target arrives before the workflow contract is clear. Teams compare feature lists while customer consequences, exception paths, verification burden, data rights, integration ownership and exit costs remain invisible.

The value path is:

Accepted workflow problem
→ bounded requirements and consequences
→ least-complex viable intervention
→ verifiable and supportable operation
→ usable capacity and reliable service
→ measured customer, employee or operating outcome

Every design choice must be justified by an accepted business requirement. Microsoft’s official Azure architecture guidance states this principle directly and asks architects to consider reliability, security, cost, operations and performance trade-offs (Build for business needs, VERIFIED within its Azure context). This guide generalises the requirement-led discipline, not Azure product choices.

The architecture decision contract

Leadership assigns one primary disposition:

Hybrid designs are allowed, but every component receives its own disposition and boundary. “AI” is not an architecture. A language model used for drafting, a classifier used for routing and an agent authorised to execute a transaction have materially different verification and control needs.

What must be decided workflow by workflow

The decision tests ten lenses without collapsing them into a magic score: user and service need; workflow stability; rule determinism; consequence of error; human verification; data provenance and rights; integration and state; reliability and recovery; lifecycle capability and total cost; and portability or exitability. One mandatory failure cannot be offset by attractive features.

The UK Technology Code of Practice connects technology choices to user needs, accessibility, security, privacy, interoperability, purchasing and sustainability (Technology Code of Practice, VERIFIED official UK government guidance). Its mandates apply only in their stated public-sector context; the linked decision concerns remain useful prompts elsewhere. The UK Open Standards Principles also call for estimating exit and migration costs at project start (Open Standards Principles, VERIFIED official guidance).

Scope and exclusions

Use this guide only after The Automation and Technology Readiness Assessment: An Executive Standard for Choosing What Should Change/The Workflow Constraint and Root-Cause Audit: Simplify the Work Before Automating It evidence identifies an accepted workflow problem and The Automation Opportunity Portfolio: A Value, Feasibility, Risk and Learning Playbook, where required, authorises an architecture evidence gate. Scope includes requirements, option boundaries, rule and uncertainty analysis, data and integration contracts, failure and verification design, lifecycle ownership, total-cost categories, exitability, comparative evidence, decision and handoff.

It excludes portfolio prioritisation, detailed AI and automation governance under The AI and Automation Governance Standard: Proportionate Control from Assistance to Autonomous Action, pilot design under The Proof-of-Value Pilot Standard: Designing Automation Tests That Can Earn Production, agent implementation under The Governed AI Agent Delivery Playbook: Human Authority, Tool Use and Verifiable Action, production operation under The Automation Production Operating Standard: Integration, Monitoring, Incidents and Change Control, supplier appointment under The Automation Partner and Commercial Due-Diligence Playbook: Scope, Cost, Risk and Exitability, enterprise scale under The Enterprise Automation Scale Standard: Shared Capabilities, Portfolio Governance and Capability Transfer and broad technology-investment decisions under The Build, Buy, Configure, Integrate or Stop Decision: An Executive Technology Investment Playbook. It does not provide legal, privacy, security, employment, financial or regulatory advice.

Expected outputs are an accepted architecture charter, requirement and consequence register, component and option matrix, lifecycle-cost and exit register, architecture decision record and downstream evidence brief. They are not an approved purchase, production design, benefit forecast or claim that automation will improve an outcome.

2. The Leadership vs. Delegation Boundary

The reader recognises that the decision must be made workflow by workflow against integrations, data rights, consequence of error, verification, exitability and total cost.

When an internal team can lead

An internal team can lead when it is free to recommend no build, has access to workflow and incident evidence, can expose platform and supplier interests, and includes architecture, operations, data, security, finance and affected-user perspectives. The architect must not be rewarded for choosing a particular platform or maximising custom construction.

When independent challenge is proportionate

Independent leadership is justified when a strategic supplier frames the options, sunk cost narrows debate, business and technology owners disagree about consequences, custom-build enthusiasm suppresses lifecycle cost, or AI language hides materially different autonomy. An independent partner may structure evidence and challenge assumptions but cannot accept risk or make the final commitment.

When a narrower specialist is enough

Use a process specialist to stabilise the workflow, a data specialist to test provenance or fitness, a security or privacy authority for a bounded conclusion, an integration architect for interface evidence, or finance for cost definitions. A supplier demonstration may inform one evidence question but cannot perform the comparative decision.

Stop and escalation

Stop if the problem has no owner, workflow evidence is absent, data access is unauthorised, a predetermined product makes comparison performative, human fallback is fictional, or lifecycle ownership cannot be assigned. Escalate outcome conflicts to the sponsor; service consequences to the COO; architecture exceptions to the CIO/CTO; financial definitions to the CFO; and security, privacy, legal, employment or regulatory matters to qualified authorities.

Questions for evaluating an architecture provider

1. How will you prove that no build and direct workflow change remain real alternatives?
2. How will you separate deterministic rules, AI assistance and agentic action?
3. Which error consequences require human verification or prohibit automation?
4. How will data rights, provenance, retention and model use be evidenced?
5. Which integration, identity, state and recovery assumptions need testing?
6. How will custom extensions affect upgrades, support and exit?
7. Which lifecycle costs and internal capability commitments are included?
8. How will supplier claims be tested independently?
9. Where does architecture end before governance, procurement and pilot approval?
10. Which records and decision capability remain with our team?

3. The Step-by-Step Execution Standard

Use the Architecture Charter and Authority Register, Requirement Consequence and Verification Register, Component Option and Trade-off Matrix, and Lifecycle Cost Exit and Decision Register. Retain stable IDs, source links, proof classifications and version history.

Step 01: Charter the architecture decision

Purpose and decision served Define the workflow, outcome, component boundary and architecture decision without naming a preferred solution.

Accountable owner CIO/CTO with the COO and operating owner accepting the service boundary.

Delegated lead and contributors Architecture lead, workflow owner, users, data, integration, security, privacy, finance, procurement and support contributors.

Preconditions, inputs and access Accepted The Automation and Technology Readiness Assessment: An Executive Standard for Choosing What Should Change/The Workflow Constraint and Root-Cause Audit: Simplify the Work Before Automating It problem evidence, The Automation Opportunity Portfolio: A Value, Feasibility, Risk and Learning Playbook handoff if applicable, source authority and permission to recommend no build.

Actions

1. State the decision and affected outcome.
2. Bound workflow, population, systems and period.
3. Record exclusions and dependencies.
4. Approve dispositions and stop conditions.

Evidence to retain Original handoff, charter versions, authority, conflicts, sources and approval.

Decision or scoring rule Proceed only when a named forum can choose every disposition; change a product-selection brief.

Output and template A2A-CHR-* and A2A-AUT-* rows in the Architecture Charter and Authority Register.

Acceptance gate PROCEED when decision, boundary, owner and authority are accepted; otherwise CHANGE, DEFER or STOP.

Leadership checkpoint The sponsor confirms that technology adoption is not the outcome.

Human control point Only authorised leaders set consequence tolerance and commitment authority.

Failure modes and safeguards Supplier-led scope and enterprise-wide ambition are controlled by a single workflow boundary.

Change, stop or escalation condition Stop an ownerless case; escalate disputed authority.

Handoff to the next step Pass the accepted charter to Step 02.

Step 02: Map authority, interests and non-negotiables

Purpose and decision served Expose who may decide, advise, veto, fund, operate and benefit before option analysis.

Accountable owner CIO/CTO for architecture authority and COO for operating authority.

Delegated lead and contributors Decision secretary, enterprise architect, finance, procurement, risk and qualified control owners.

Preconditions, inputs and access Accepted charter, policies, architecture principles, contracts and declared supplier relationships.

Actions

1. Assign decision and evidence rights.
2. Record mandatory constraints.
3. Declare conflicts and sunk costs.
4. Define recusal and escalation.

Evidence to retain Authority matrix, applicable obligations, exception process and conflict declarations.

Decision or scoring rule A mandatory authority or control gap cannot be offset by option attractiveness.

Output and template Authority, constraint and conflict rows linked to the charter ID.

Acceptance gate PROCEED only with named accountable authorities and an executable exception route.

Leadership checkpoint Leaders confirm incumbent platform preference is evidence, not instruction.

Human control point Qualified people interpret obligations and accept exceptions.

Failure modes and safeguards Hidden mandates and vendor influence are surfaced before scoring.

Change, stop or escalation condition Defer where no authority can accept a material constraint.

Handoff to the next step Pass constraints and authorities to Step 03.

Step 03: Establish the workflow and counterfactual

Purpose and decision served Confirm what work actually occurs and whether process change resolves the problem without software.

Accountable owner Operating owner.

Delegated lead and contributors Process analyst, frontline users, service owner, customer evidence lead and control owners.

Preconditions, inputs and access Current workflow observations, volumes, exceptions, rework, incidents, policies and The Workflow Constraint and Root-Cause Audit: Simplify the Work Before Automating It evidence.

Actions

1. Map performed work and exceptions.
2. Separate policy, ownership, capability and information causes.
3. Define business-as-usual and direct-change counterfactuals.
4. Identify irreducible human judgement.

Evidence to retain Observed workflow, source limitations, counterfactual and unresolved root causes.

Decision or scoring rule Choose NO BUILD where clarified ownership, removal or simplification meets the accepted requirement.

Output and template Workflow and counterfactual requirement rows with stable IDs.

Acceptance gate PROCEED if the performed workflow is stable enough to design; otherwise return to The Workflow Constraint and Root-Cause Audit: Simplify the Work Before Automating It.

Leadership checkpoint The COO accepts what should be removed before automation.

Human control point Affected users validate performed work and consequence, not only documented procedure.

Failure modes and safeguards Automating waste is prevented by retaining no-build and direct-change options.

Change, stop or escalation condition Stop if observation contradicts the stated problem materially.

Handoff to the next step Pass the accepted workflow to Step 04.

Step 04: Contract requirements and consequences

Purpose and decision served Translate outcome needs into functional, non-functional and consequence requirements.

Accountable owner Operating owner with CIO/CTO acceptance.

Delegated lead and contributors Business analyst, architect, accessibility, security, privacy, support and user representatives.

Preconditions, inputs and access Accepted workflow, affected populations, service evidence and obligations.

Actions

1. Write each requirement independently.
2. Define acceptance evidence.
3. Classify error consequences and reversibility.
4. Record priority, owner, source and expiry.

Evidence to retain Requirement statements, sources, dissent, exceptions and acceptance rules.

Decision or scoring rule Reject solution-shaped requirements; retain mandatory conditions separately from preferences.

Output and template A2A-REQ-* rows in the Requirement Consequence and Verification Register.

Acceptance gate Every decision-critical requirement has source, owner, acceptance and consequence.

Leadership checkpoint Leadership accepts trade-offs and non-negotiables before options are compared.

Human control point Qualified owners classify consequential error and affected-person safeguards.

Failure modes and safeguards Feature wish lists are controlled by outcome-linked acceptance evidence.

Change, stop or escalation condition Escalate incompatible mandatory requirements; stop an impossible case.

Handoff to the next step Pass requirement contracts to Step 05.

Step 05: Test determinism, uncertainty and human judgement

Purpose and decision served Decide where explicit rules are sufficient and where probabilistic assistance might be justified.

Accountable owner CIO/CTO and operating owner jointly.

Delegated lead and contributors Domain expert, rules analyst, AI specialist, quality lead and affected users.

Preconditions, inputs and access Representative inputs, decision policies, exception history and consequence classifications.

Actions

1. Enumerate known rules and exceptions.
2. Test input stability.
3. Identify ambiguity and verification burden.
4. Separate assistance from authorised action.

Evidence to retain Rule coverage, exception taxonomy, uncertainty claims, examples and reviewer conclusions.

Decision or scoring rule Prefer deterministic rules when inputs and decisions are explicit; never use probabilistic output merely for novelty.

Output and template Rule, uncertainty, human-judgement and candidate-component rows.

Acceptance gate Each component states deterministic, probabilistic, human or unresolved behaviour.

Leadership checkpoint Leaders accept where human judgement remains accountable.

Human control point A named human retains any consequential judgement not authorised for automation.

Failure modes and safeguards Calling all complexity “AI” is prevented by component-level classification.

Change, stop or escalation condition Validate ambiguous rules; stop if verification is more burdensome than the current work.

Handoff to the next step Pass behaviour boundaries to Step 06.

Step 06: Contract data, identity, integration and state

Purpose and decision served Determine whether each option can lawfully and reliably obtain, transform and write required information.

Accountable owner CIO/CTO with data and information authorities.

Delegated lead and contributors Data owner, integration architect, identity, security, privacy and system owners.

Preconditions, inputs and access Data inventory, interface documentation, identity model, retention rules and representative records.

Actions

1. Map data provenance and rights.
2. Define reads, writes and system of record.
3. Specify identity and permission boundaries.
4. Record synchronisation, lineage, retention and deletion needs.

Evidence to retain Source contracts, interface limits, permission approval, lineage and data-quality evidence.

Decision or scoring rule An option requiring unauthorised data, unowned state or unverifiable writes is not viable.

Output and template Component records for data, interface, identity and state dependencies.

Acceptance gate Every material flow has owner, authority, boundary, failure response and test need.

Leadership checkpoint The CIO/CTO accepts integration debt and data commitments explicitly.

Human control point Information authorities approve use; architecture cannot infer permission.

Failure modes and safeguards Demo data and undocumented APIs are marked REQUIRES VALIDATION.

Change, stop or escalation condition Defer until rights or stable interfaces exist; escalate unlawful or unsafe use.

Handoff to the next step Pass accepted contracts to Step 07.

Step 07: Design verification, failure and recovery boundaries

Purpose and decision served Determine how output or action will be checked, contained, reversed and recovered.

Accountable owner Operating owner for service recovery and CIO/CTO for technical recovery.

Delegated lead and contributors Reliability, quality, security, service, domain and incident specialists.

Preconditions, inputs and access Consequence register, exception history, service objectives and component boundaries.

Actions

1. Enumerate failure modes.
2. Define detection and verification.
3. Set fallback, rollback and revocation.
4. Assign incident and recovery authority.

Evidence to retain Failure hypotheses, recovery assumptions, test needs and unresolved exposure.

Decision or scoring rule Reject options whose material failures cannot be detected or contained within accepted tolerance.

Output and template Verification and recovery rows linked to requirements and components.

Acceptance gate Every consequential action has pre-action or post-action verification and a named response.

Leadership checkpoint The COO accepts degraded-mode service; the CIO/CTO accepts recovery requirements.

Human control point Named people approve, interrupt or reverse consequential actions.

Failure modes and safeguards Happy-path architecture is challenged with realistic exception and outage cases.

Change, stop or escalation condition Stop autonomous action without feasible containment.

Handoff to the next step Pass recovery requirements to Step 08.

Step 08: Define candidate options component by component

Purpose and decision served Create genuinely distinct options rather than differently branded versions of one predetermined choice.

Accountable owner CIO/CTO.

Delegated lead and contributors Architecture lead, platform owners, engineering, operations, procurement and independent challenger.

Preconditions, inputs and access Accepted requirements, data contracts, behaviour classification and failure boundaries.

Actions

1. Keep no build as baseline.
2. Define rules and existing-platform options.
3. Define AI, agent, buy and custom options only where justified.
4. State hybrid component boundaries.

Evidence to retain Option descriptions, excluded variants, source claims and component diagrams.

Decision or scoring rule Every option must state what it does, does not do, owns, depends on and requires humans to verify.

Output and template A2A-OPT-* and A2A-CMP-* rows in the Component Option and Trade-off Matrix.

Acceptance gate At least no-build and one viable intervention are comparable, or the case stops.

Leadership checkpoint Leaders confirm options are not procurement lots or vendor shortlists.

Human control point Architecture and operating owners approve each option boundary.

Failure modes and safeguards False hybrids and feature dumping are controlled through component IDs and exclusions.

Change, stop or escalation condition Return requirements if no option can meet mandatory conditions proportionately.

Handoff to the next step Pass bounded options to Step 09.

Step 09: Test fit, trade-offs and evidence gaps

Purpose and decision served Compare each option against accepted requirements without allowing averages to hide fatal conditions.

Accountable owner CIO/CTO with the operating owner.

Delegated lead and contributors Architect, evidence lead, users, finance, risk, security, privacy and support.

Preconditions, inputs and access Bounded options, requirement contracts and authoritative supplier or internal evidence.

Actions

1. Record fit as met, partial, unmet or unknown.
2. Link evidence and limitations.
3. Identify mandatory failures.
4. Convert material unknowns into validation questions.

Evidence to retain Fit records, contradictory evidence, assumptions, rejected claims and dissent.

Decision or scoring rule No aggregate score can override a mandatory unmet condition, unauthorised dependency or unacceptable harm.

Output and template Trade-off rows linking option IDs to requirement IDs and proof status.

Acceptance gate Remaining options have no hidden mandatory failure and all critical unknowns have an owner.

Leadership checkpoint Leadership sees the cost of complexity and verification, not only feature coverage.

Human control point Named authorities decide whether evidence is fit for this decision.

Failure modes and safeguards Vendor attestations and prototypes remain source-bounded rather than treated as production proof.

Change, stop or escalation condition Validate material unknowns; stop if all options fail.

Handoff to the next step Pass viable options and gaps to Step 10.

Step 10: Model lifecycle cost, capability and exit

Purpose and decision served Make the whole operating commitment visible before build, buy or platform configuration is selected.

Accountable owner CFO for definitions and CIO/CTO for lifecycle ownership.

Delegated lead and contributors Finance analyst, engineering, platform, operations, procurement, data and change owners.

Preconditions, inputs and access Viable options, pricing bases, internal capacity, support model, change frequency and migration assumptions.

Actions

1. Define cost categories and periods.
2. Include integration, evaluation, security, support, change and retirement.
3. Name required capabilities.
4. Estimate exit, data extraction and transition conditions as ranges.

Evidence to retain Source-linked cost ranges, assumptions, capability gaps, contract conditions and exit tests.

Decision or scoring rule Do not convert ranges into a guaranteed return or treat internal labour as free.

Output and template A2A-LIF-*, A2A-CST-* and A2A-EXT-* rows in the Lifecycle Cost Exit and Decision Register.

Acceptance gate Each viable option has comparable lifecycle categories, owner commitments and a credible exit path.

Leadership checkpoint The CFO and CIO/CTO accept definitions, uncertainty and capability burden.

Human control point Only authorised leaders commit budget, people or contractual positions.

Failure modes and safeguards Licence-only comparisons are rejected; sunk cost is disclosed rather than counted as future benefit.

Change, stop or escalation condition Defer an option with unknowable material cost or unexecutable exit.

Handoff to the next step Pass lifecycle evidence to Step 11.

Step 11: Select the least-complex supportable disposition

Purpose and decision served Make a transparent architecture choice whose complexity is justified by workflow value and evidence.

Accountable owner CIO/CTO, with COO acceptance and sponsor commitment.

Delegated lead and contributors Decision secretary, architecture lead, operating owner, CFO, qualified control owners and independent challenger.

Preconditions, inputs and access Complete option, trade-off, lifecycle, risk, verification and exit evidence.

Actions

1. Restate the decision.
2. Compare viable options and no build.
3. Record dissent and rejected alternatives.
4. Assign one component-level disposition and conditions.

Evidence to retain Decision record, attendees, evidence pack, conflicts, rationale, conditions and signatures.

Decision or scoring rule Select the least-complex option meeting mandatory requirements within accepted lifecycle and exit boundaries.

Output and template A2A-DEC-* decision rows with component dispositions and conditions.

Acceptance gate NO BUILD, DETERMINISTIC RULES, CONFIGURE EXISTING PLATFORM, AI ASSISTANCE, BOUNDED AGENTIC ACTION, BUY, BUILD CUSTOM, VALIDATE, DEFER or STOP.

Leadership checkpoint The authorised forum accepts business, operating and architecture consequences separately.

Human control point No model, weighted score, architect or supplier makes the final decision automatically.

Failure modes and safeguards Consensus theatre is controlled by recorded dissent, conditions and named authority.

Change, stop or escalation condition Stop if the decision cannot survive disclosure of evidence limits and exit burden.

Handoff to the next step Pass the authorised disposition to Step 12.

Step 12: Create the downstream evidence and ownership brief

Purpose and decision served Translate architecture into a bounded governance, validation, pilot, procurement or process-change gate.

Accountable owner Receiving owner named by the architecture forum.

Delegated lead and contributors Architecture lead, governance, pilot, procurement, engineering, operations and evidence owners as applicable.

Preconditions, inputs and access Signed disposition, conditions, unresolved claims, component boundaries and retained sources.

Actions

1. State downstream output and exclusions.
2. Assign owner and acceptance.
3. Carry validation and control needs.
4. Obtain receiving-owner acceptance.

Evidence to retain Handoff brief, acknowledgement, transferred artefacts, access conditions and rejected scope.

Decision or scoring rule Architecture authorises only its named next evidence gate; it never authorises production implicitly.

Output and template Handoff rows linking decision, component, requirement, evidence gap and receiving standard.

Acceptance gate Receiving owner accepts the boundary, evidence, conditions, resources and stop route.

Leadership checkpoint The sponsor confirms that purchase, build, pilot and production decisions remain separate.

Human control point The receiving accountable owner accepts work and authority explicitly.

Failure modes and safeguards Architecture diagrams cannot become delivery mandates without accepted handoff.

Change, stop or escalation condition Defer an unowned handoff; return any expanded scope to the decision forum.

Handoff to the next step Pass the accepted brief to Step 13.

Step 13: Review, change and retire the decision

Purpose and decision served Keep the architecture valid as requirements, suppliers, costs, risks and workflow conditions change.

Accountable owner CIO/CTO and operating owner.

Delegated lead and contributors Architecture custodian, service owner, finance, procurement, risk, evidence and downstream owners.

Preconditions, inputs and access Decision record, evidence expiry, material-change triggers and downstream findings.

Actions

1. Monitor triggers rather than elapsed time alone.
2. Reconcile new evidence.
3. Renew, change, validate, defer, stop or retire.
4. Close superseded access and claims.

Evidence to retain Review record, changed assumptions, incidents, cost changes, supplier changes and closure evidence.

Decision or scoring rule Re-charter when the outcome, workflow, consequence, autonomy or component boundary changes materially.

Output and template Review and retirement rows linked to the original decision ID.

Acceptance gate RETAIN, CHANGE, VALIDATE, DEFER, STOP, RETIRE or RE-CHARTER.

Leadership checkpoint Leaders confirm the architecture remains the simplest supportable intervention.

Human control point Named authorities renew risk, service and investment commitments.

Failure modes and safeguards Silent lock-in is controlled by evidence expiry, exit tests and retirement ownership.

Change, stop or escalation condition Contain incidents immediately; do not wait for routine architecture review.

Handoff to the next step Return material changes to Step 01; otherwise retain the governed record.

4. The Evidence & Measurement Checklist

Preflight and authority

• The architecture decision is framed around one accepted workflow problem. Evidence: signed charter. Owner: CIO/CTO.
• No build remains an authorised disposition. Evidence: decision mandate. Owner: executive sponsor.
• Architecture, operating, evidence, control and commitment authorities are named. Evidence: authority register. Owner: decision secretary.
• Portfolio, governance, procurement, pilot and production decisions remain excluded. Evidence: scope register. Owner: architecture lead.
• Supplier, platform and sunk-cost interests are disclosed. Evidence: conflict register. Owner: independent challenger.

Evidence access and quality

• The performed workflow is supported by observation and source records. Evidence: workflow evidence pack. Owner: operating owner.
• Every requirement has a source, owner, acceptance test and proof status. Evidence: requirement register. Owner: business analyst.
• Data provenance, rights, quality and retention limits are recorded. Evidence: data contract. Owner: data owner.
• Supplier and internal claims retain source and applicability limits. Evidence: claim ledger. Owner: evidence custodian.
• Missing evidence is marked REQUIRES VALIDATION rather than assumed. Evidence: evidence-gap rows. Owner: decision owner.

Method execution

• Direct process change is tested before added technology. Evidence: counterfactual record. Owner: COO.
• Deterministic, probabilistic, human and agentic behaviours are separated by component. Evidence: component matrix. Owner: architect.
• Mandatory requirements cannot be averaged into a score. Evidence: trade-off rules. Owner: CIO/CTO.
• Each option states inclusions, exclusions, dependencies and verification. Evidence: option records. Owner: architecture lead.
• Hybrid options assign a disposition to every component. Evidence: component decision map. Owner: enterprise architect.

Governance, privacy, security and risk

• Consequence of error and affected populations are explicit. Evidence: consequence register. Owner: operating owner.
• Identity, permissions, writes and system-of-record boundaries are accepted. Evidence: integration contract. Owner: security and system owners.
• Consequential actions have human authority, fallback and revocation. Evidence: verification design. Owner: control owner.
• Qualified owners decide privacy, security, legal, employment and regulatory questions. Evidence: referral log. Owner: executive sponsor.
• Material incidents trigger containment outside the review cadence. Evidence: incident route. Owner: service owner.

Deliverables and acceptance

• All four working files use stable linked identifiers. Evidence: working-pack index. Owner: architecture custodian.
• Every viable option is compared with no build against the same requirements. Evidence: option matrix. Owner: independent challenger.
• The selected disposition has rationale, conditions, dissent and rejected alternatives. Evidence: architecture decision record. Owner: decision secretary.
• Component, data, integration, recovery and exit boundaries are documented. Evidence: accepted architecture pack. Owner: CIO/CTO.
• The receiving owner accepts the next evidence gate and exclusions. Evidence: handoff receipt. Owner: downstream owner.

Measurement

• Learning, operating, commercial outcome and guardrail measures remain separate. Evidence: measurement register. Owner: benefit owner.
• Every measure states definition, baseline, source, owner, cadence and response. Evidence: metric contracts. Owner: measurement owner.
• Requirement coverage does not substitute for outcome evidence. Evidence: decision pack. Owner: architecture lead.
• Lifecycle cost retains ranges, assumptions and internal capacity. Evidence: cost register. Owner: CFO.
• Architecture outcomes retain attribution limits and concurrent changes. Evidence: review record. Owner: benefit owner.

Decision and handover

• Each component receives one controlled architecture disposition. Evidence: signed decision. Owner: CIO/CTO.
• Funding and procurement commitments are recorded separately from architecture. Evidence: authority record. Owner: economic buyer.
• Validation questions state method, owner, burden and decision response. Evidence: validation brief. Owner: evidence owner.
• Governance needs route to The AI and Automation Governance Standard: Proportionate Control from Assistance to Autonomous Action and pilot needs route to The Proof-of-Value Pilot Standard: Designing Automation Tests That Can Earn Production. Evidence: handoff register. Owner: architecture custodian.
• Enterprise technology investment questions route to The Build, Buy, Configure, Integrate or Stop Decision: An Executive Technology Investment Playbook. Evidence: scope decision. Owner: CIO/CTO.

Review, change and stop controls

• Requirements, evidence and architecture decisions have change triggers. Evidence: review schedule. Owner: architecture custodian.
• Material autonomy, consequence or workflow changes cause re-charter. Evidence: change decision. Owner: operating owner.
• Exit and portability assumptions are tested at accepted gates. Evidence: exit test record. Owner: procurement and technology owners.
• Superseded options close access, claims and supplier activity. Evidence: closure record. Owner: decision owner.
• An uncontained incident overrides routine architecture cadence. Evidence: incident record. Owner: service owner.

Measurement contracts

Measure A: Decision-critical requirement evidence coverage

Measure B: Mandatory requirement fit

Measure C: Verification burden by consequential component

Measure D: Lifecycle commitment range

Measure E: Accepted service outcome movement

Measure F: Material architecture control exception

Evidence classifications used in this guide

• VERIFIED: supported by retained decision-fit organisational evidence or authoritative external material within its stated boundary.
• INFERRED: an interpretation linked to evidence with alternative explanations and limitations visible.
• PROPOSED: a requirement, component, option, range or method awaiting authorised acceptance.
• REQUIRES VALIDATION: a decision-critical claim that cannot yet support architecture selection.

Sources and evidence notes

1. Microsoft Azure Architecture Center: Build for business needs supports requirement-led architecture and explicit cost and operating considerations. VERIFIED official vendor guidance; Azure-specific recommendations are not universal.
2. Microsoft Azure Architecture Center: Design principles supports designing for change, failure analysis and operational support. VERIFIED official vendor guidance within its stated context.
3. NIST SP 800-218: Secure Software Development Framework provides high-level secure software-development practices and a common vocabulary relevant to producers and purchasers. VERIFIED official source; it does not make a local build decision.
4. UK Government: Technology Code of Practice connects user needs, accessibility, security, privacy, interoperability, purchasing and sustainability. VERIFIED official UK guidance; mandates apply only in scope.
5. UK Government: Open Standards Principles supports interoperability and early visibility of exit and migration costs. VERIFIED official guidance within its jurisdiction.
6. NIST AI Risk Management Framework 1.0 provides voluntary Govern, Map, Measure and Manage outcomes for AI risk. VERIFIED official source; relevant only where an option includes AI.

The dispositions, component method, thirteen steps, checklists, measurement contracts and visual structures are Abrasim-created working methods. They are PROPOSED, not externally certified standards or evidence of business results.