The training programme was exemplary on paper. Staff attended role-based sessions, passed knowledge checks and received polished launch communications. On the first live day, advisers copied generated text into the system of record, rebuilt missing evidence by hand and sent ambiguous cases to a shared mailbox with no service owner.

Completion statistics rose while work became harder. Reviewers could reject a suggestion, yet their productivity target rewarded fast acceptance. The interface displayed confidence and a rationale, but did not show which evidence was absent or how to reverse an action. Experienced advisers learned that safe abstention lowered their performance score.

This is the point at which change management becomes architecture. Successful use depends on what the operating system permits, requires, records and rewards during real work. Communication can establish intent, and coaching can build understanding. Neither can create decision authority, enter evidence into the record, staff a recovery path or remove a contradictory target.

The design objective is calibrated participation rather than maximum use. The system should make the intended human–AI configuration executable and make unsafe configurations difficult. Adoption then appears as evidence from a workable socio-technical arrangement, including occasions when a skilled person modifies, abstains, overrides or escalates.

Socio-technical boundaryChange moves inside the product when behaviour depends on system conditions

Socio-technical research showed early that social and technical arrangements should be designed jointly rather than optimised in isolation.[1] In human–AI work, the joint system includes model behaviour, interface, evidence, roles, queues, service levels, performance management, staffing and consequences. Treating the model as the product and people as a rollout audience leaves most of the operating design unspecified.

Implementation research distinguishes the strength of an intervention from the organisational climate that supports its use.[2] A technically capable assistant can still fail when expected use conflicts with workload, reward, professional identity or local support. Architecture gives that climate executable form through defaults, permissions, capacity, feedback and visible ownership.

The rival argument deserves attention. Embedding every change concern into an early product can create bureaucracy and delay learning. Progressive delivery is the answer: begin with the smallest safe role, protected shadow mode and an evidence loop. Avoid building remote future states. Do not postpone role authority, support, recovery or workload design when the experiment already changes consequential work.

A mechanism belongs in architecture when its absence cannot be repaired by information alone. If an adviser understands abstention but the interface requires acceptance to finish a case, the problem is architectural. If escalation is taught but no team owns the queue, the problem is operating capacity. If an override is permitted but harms a target, incentive design has disabled the control.

Practice also changes the technology’s meaning over time. A practice lens treats use as recurrent action that both draws on and reshapes structures.[4] Runtime evidence therefore needs to inform coaching, product design, policy and capacity. A launch configuration cannot be assumed to remain valid as roles and routines adapt.

Original synthesisThe eight-mechanism change-bearing architecture

The change-bearing architecture is this article’s synthesis. It wraps one decision episode with eight embedded mechanisms. For each mechanism, the design record names user cohort, intended behaviour, prohibited shortcut, evidence event, owner, capacity requirement and failure response. The record is role- and consequence-specific.

These are not eight launch documents. They are behaviours the operating path can demonstrate. A point-of-work role declaration controls available actions. A proficiency state changes access. An abstention records evidence and routes work. A support contract governs a queue. Outcome feedback creates a review event. Workforce effects alter staffing and transition decisions.

The architecture also separates three authorities. Operator proficiency concerns completing assigned human–AI work safely. Overseer proficiency concerns monitoring populations, drift, incidents and control effectiveness. Business decision authority concerns accepting the customer, financial, legal or operational consequence. One person may hold more than one role, but one course completion does not prove all three.

Every mechanism has a prohibited shortcut. Role declaration cannot be replaced by “human in the loop”. Progressive access cannot rely on self-attestation. Evidence display cannot become a confidence decoration. Discretion cannot hide override behind extra steps. Shadow practice cannot expose customers. Support cannot be a mailbox. Feedback cannot end as unused telemetry. Transition cannot hide displaced work.

Graduated competenceBuild authority from observed performance, not course completion

Generic literacy is a foundation, not an authority grant. A regulated adviser needs to interpret evidence, recognise model limits, distinguish recommendation from policy, document modification and know when abstention protects the customer. An overseer needs population monitoring, sampling, incident, drift and intervention skills. The business authority needs the mandate and competence to accept consequential trade-offs.

Progressive authority begins with realistic rehearsal. In protected shadow practice, the person sees cases and system output without changing the live record. They form an independent view, compare it with the suggestion, explain disagreement and practise escalation. Evidence comes from performance across representative and difficult cases, not a self-rating.

The next stage permits assisted preparation while a qualified decision owner retains action. A bounded-action stage can then allow defined cohorts, values or consequences, with overrides and outcomes reviewed. Expansion follows demonstrated proficiency, support capacity and stable operating evidence. Material policy, model, interface or cohort changes can step authority back.

Psychological safety matters because learning requires speaking about mistakes, uncertainty and dissent without interpersonal penalty.[3] The architecture reinforces this through protected rehearsal, non-punitive reporting and visible review of overrides. A culture statement is fragile when the performance system still treats disagreement as delay.

Proficiency has an expiry. Long gaps in practice, a changed model, revised policy, an incident or a new decision consequence can require refresh. The refresh is targeted to the changed mechanism rather than replaying a generic course. Evidence identifies where coaching, interface repair or authority restriction is needed.

The counter-case uses a regulated advice workflow. New advisers first assess synthetic and historical cases in shadow mode. Qualified reviewers compare reasoning, evidence use and escalation. Bounded authority follows for lower-consequence cohorts. High-consequence advice retains a different decision owner and stronger review. Outcome and complaint evidence determines expansion.

Meaningful human actionDesign acceptance, modification, abstention, override and escalation as real paths

Automation research distinguishes appropriate use from misuse, disuse and abuse.[5] Levels of automation also shape who selects, decides and acts.[6] A human–AI allocation must therefore specify the action each role can take, the information available, the time and capacity to act, and what happens after intervention.

Acceptance is meaningful only when the person can inspect decision-relevant evidence and bears appropriate authority. Modification should preserve the system proposal, human change, reason and eventual outcome. Abstention should be a rational response when evidence is inadequate, the case is outside competence or consequence exceeds authority. It must not be counted automatically as resistance.

Override punishment is an architectural defect. A reviewer may be nominally allowed to reject output while an acceptance-rate target, speed metric or extra documentation burden discourages it. The control panel records time and friction across all paths, then the incentive review checks whether one safe action creates a personal penalty.

Explanation theatre occurs when rationale and confidence are visible but operational limits are not. People need to know relevant provenance, missing inputs, known failure conditions, policy constraints and reversal options. Human–AI interaction guidance emphasises setting expectations, communicating uncertainty, supporting correction and learning from user behaviour.[7]

The interface does not need to display every technical detail. It needs contextual evidence sufficient for the assigned decision. An operator may require source excerpts and missing-document flags. An overseer may require population error, override and drift patterns. A decision owner may require consequence, policy and recourse evidence.

Each action route emits a change event: role, case, evidence state, system version, action, reason, destination, elapsed time and outcome link. Monitoring uses those events to discover confusing evidence, inappropriate reliance, avoidance, queue burden and proficiency gaps. It does not turn individual judgement into covert productivity surveillance.

Operating capacityAn escalation route is a service, not an interface ornament

An abstention button is safe only if the destination has an owner, competence, capacity, service expectation and recovery route. Otherwise the interface moves responsibility into a dark queue. Staff soon learn to accept questionable output, work around the system or send private messages to someone they trust.

Capacity design begins with arrival and handling assumptions by cohort and consequence. It includes expected abstention, override, evidence failure, incident and recovery demand. The support owner defines triage, authority, priority and return state. Backlog age and tail response matter more than the existence of a mailbox.

The unstaffed-escalation negative control uses a visible link that routes every exception to a general operations queue. No one owns model-specific evidence, and service targets cover only ordinary enquiries. The UI test passes, yet high-consequence cases wait beyond their decision window. A safe design limits rollout to the volume and consequence the service can absorb.

Support is not limited to a help desk. Some exceptions need a domain specialist, some an engineering correction, some a control decision and some customer recourse. The routing contract preserves the case, system version, evidence state, attempted action and decision deadline. Ownership changes explicitly rather than leaving the operator responsible for chasing.

Recovery capacity is tested before consequential expansion. The system can enter a safe manual or restricted mode, reconcile partially completed actions and return cases without duplicating or losing decisions. People rehearse the fallback under realistic workload. A recovery document without staffing or access is not an operating capability.

Support evidence changes the product. Recurrent escalation reasons can expose missing evidence, poor role allocation, an unsuitable cohort, weak proficiency or policy ambiguity. The learning owner decides whether to coach, redesign, change authority, add capacity or narrow the configuration. Closing tickets without changing the cause converts exception work into permanent hidden labour.

Contradiction testingAlign workload, targets and roles with the behaviour the control expects

Leaders often ask for critical judgement while rewarding throughput, acceptance and low escalation. Staff resolve the contradiction rationally. Some rely on the system to protect speed; others avoid it to preserve professional quality. Both behaviours can be mislabelled as attitude when the operating targets made them predictable.

An incentive contradiction map starts with the intended behaviour and traces every formal and informal consequence. What happens to queue position, case time, performance rating, customer ownership, overtime and peer burden when a person modifies, abstains or escalates? The map includes managers because their delivery targets shape local pressure.

Raw acceptance is especially dangerous as a performance target. High acceptance may reflect good fit, but it can also reflect automation bias, weak authority, fear of delay or difficult override steps. Low acceptance may indicate poor output, expert discernment, bad cohort selection or a target conflict. Outcome, reason and consequence are required for interpretation.

Workload must include the new work, not only the automated task. Evidence checking, exception documentation, outcome review, customer explanation, incident response and model feedback consume capacity. Removing one preparation step can add review or coordination elsewhere. Workforce plans follow the full task system rather than subtracting nominal minutes from headcount.

Transition is an architectural obligation when roles materially change. The design states which tasks shrink, grow or move; which skills and authorities are needed; how people can practise and qualify; where capacity will be redeployed; and how consultation and employee governance occur. Hidden transition creates distrust and deprives the design of operational knowledge.

Monitoring has a boundary. Event data needed for safety, product learning and outcome review should have a declared purpose, access, retention and contest route. Individual-level telemetry should not become covert performance surveillance or a proxy for professional worth. Aggregate patterns may guide system repair while case review remains proportionate and accountable.

AI literacy and human oversight obligations in the EU AI Act make competence and operating authority relevant for systems within its scope.[12] The architecture treats those duties as role-specific, continuing capabilities. It does not imply that compliance alone makes a configuration valuable or that one generic course satisfies all contexts.

Runtime change receiptsReturn outcomes to coaching, product, policy and workforce decisions

Change evidence becomes a runtime signal when it can alter the system. An action event links later outcome, customer response, override result, incident or appeal to the responsible configuration. The learning loop classifies the mechanism implicated and sends the evidence to an owner with authority to respond.

Coaching is appropriate when the role and interface are sound but demonstrated practice is weak. Product repair is appropriate when evidence or actions are confusing. Policy change is appropriate when the rule creates recurrent contradiction. Capacity change is appropriate when safe demand exceeds the staffed route. Cohort restriction is appropriate when the allocation fails for a population.

NIST’s human–AI interaction material highlights clear roles and responsibilities, human oversight and the effects of interaction on risk.[8] The AI RMF Core and Framework connect governance, context, measurement and management in an iterative system.[9][10] Runtime change receipts make these relationships concrete for one operating path.

Feedback needs outcome visibility at the right delay. Some advice results appear quickly through correction or abandonment. Other consequences emerge through complaints, losses, audit findings or later customer outcomes. The design maintains the link and states when early behavioural evidence expires if no outcome signal arrives.

Override review should look for system patterns, not punish dissenters. A cluster can reveal missing source data, a policy edge, skill distribution or interface ambiguity. Review samples accepted actions too, because unchallenged reliance may hide more risk than recorded disagreement. The owner publishes what changed and what remains unresolved.

A worked regulated-adviser configuration

A financial-advice team begins with one bounded decision: preparing, but not issuing, a recommendation for an established customer whose evidence meets a declared standard. The adviser owns evidence relevance and can modify or abstain. A qualified reviewer owns approval. The practice director owns suitability outcomes and the authority boundary. The assistant cannot communicate with the customer or alter the record of advice.

Before live preparation, advisers work through representative, rare and deliberately incomplete cases. They make an independent assessment before seeing the suggestion, identify missing evidence and practise each discretion route. Reviewers assess reasoning and safe escalation separately from writing fluency. The exercise reveals that new advisers need source-comparison support while experienced advisers need clearer product-limit evidence.

The interface brings cited customer and policy evidence into the record. It marks absent inputs and gives modification, abstention and escalation the same completion status as acceptance. An adviser who abstains because a life change invalidates the bounded cohort is credited with a safe decision. The case reaches a staffed specialist service with a response time inside the customer commitment.

Performance design changes before the pilot. Managers remove an acceptance target and include evidence quality, appropriate intervention and customer outcome in review. Case capacity includes checking and feedback work. Monitoring is limited to safety, learning and service purposes with declared access, retention and challenge. Adviser representatives review task movement, workload and the transition path.

Shadow comparison links proposed actions to qualified review and later outcomes. Repeated source omissions trigger a product repair. A cluster of abstentions around one policy rule triggers clarification rather than coaching. Support backlog triggers cohort reduction. Only after these mechanisms hold does the director permit bounded preparation in live work, and any material model or policy change returns the affected cohort to shadow evidence.

The example shows why explanation alone is insufficient. A plausible rationale did not create authority, complete the customer record, protect dissent or staff an exception. The useful explanation was one component inside a configuration that could pause, recover and learn. Its success was judged by appropriate decisions and operating outcomes, including cases where no recommendation should proceed.

Firm-level adoption evidence emphasises complementary skills, management practices and organisational conditions.[11] Current model-risk guidance also stresses proportionate governance, validation and monitoring for models within its scope.[13] A management-system standard such as ISO/IEC 42001 reinforces continuing objectives, roles, risk treatment and improvement.[14]

The feedback loop closes only when evidence changes coaching, product, policy, capacity, access or the allocation itself. A dashboard that reports overrides without an owner and decision is observation, not learning. The change record names the action taken, the population affected, the evidence expected and the date at which the repair will be reassessed.

Interactive instrumentChange-Bearing Architecture Designer

The designer selects one repair route, missing mechanism and accountable owner. It does not total a readiness score. A severe authority, recovery or employee-governance failure can stop a high-consequence configuration even when training and interface evidence look favourable.

Use one decision and one role cohort at a time. The same product may require protected shadow practice for new advisers, bounded action for qualified advisers and a different oversight design for control staff. Rational abstention is tested as a safe action, not treated as a negative adoption signal.

ConclusionMake the safe human–AI configuration the operable one

Change management becomes architecture when desired behaviour depends on the work system. Role clarity belongs beside the decision. Proficiency changes access. Evidence and limits appear in context. Discretion includes modification, abstention, override and escalation. Support and recovery carry real capacity. Outcomes alter the configuration.

This does not eliminate communication, training, leadership or local sense-making. It gives them an operating surface. Coaching can address an observed proficiency gap. Leaders can resolve a target contradiction. Teams can rehearse with representative cases. Workforce consultation can influence task and role design before harmful assumptions harden.

The architecture is progressive. The smallest safe role enters protected practice first. Authority expands through evidence and can contract after a model, policy, cohort or incident change. A low-consequence experiment need not carry the apparatus of a high-consequence decision, but every live configuration needs adequate authority, support, recovery and monitoring boundaries.

Calibrated adoption is an outcome of fit. A person who safely abstains on an out-of-boundary case may demonstrate more competence than one who accepts every suggestion. An override cluster may reveal product or policy failure rather than workforce resistance. The design preserves those signals and gives an owner power to respond.

When courses finish but rekeying, punished dissent and abandoned queues remain, the enterprise has not encountered a communication problem. It has specified an unworkable operating path. Repair the workflow, stage competence, realign incentives, practise safely or stop the configuration. The architecture should carry the change that the announcement cannot.

Evidence spineReferences

1. Trist, E. L. and Bamforth, K. W. (1951), ‘Some Social and Psychological Consequences of the Longwall Method of Coal-Getting’, Human Relations, 4(1), 3–38. doi:10.1177/001872675100400101.
2. Klein, K. J. and Sorra, J. S. (1996), ‘The Challenge of Innovation Implementation’, Academy of Management Review, 21(4), 1055–1080. doi:10.5465/amr.1996.9704071863.
3. Edmondson, A. (1999), ‘Psychological Safety and Learning Behavior in Work Teams’, Administrative Science Quarterly, 44(2), 350–383. doi:10.2307/2666999.
4. Orlikowski, W. J. (2000), ‘Using Technology and Constituting Structures: A Practice Lens for Studying Technology in Organizations’, Organization Science, 11(4), 404–428. doi:10.1287/orsc.11.4.404.14600.
5. Parasuraman, R. and Riley, V. (1997), ‘Humans and Automation: Use, Misuse, Disuse, Abuse’, Human Factors, 39(2), 230–253. doi:10.1518/001872097778543886.
6. Parasuraman, R., Sheridan, T. B. and Wickens, C. D. (2000), ‘A Model for Types and Levels of Human Interaction with Automation’, IEEE Transactions on Systems, Man, and Cybernetics, Part A, 30(3), 286–297. doi:10.1109/3468.844354.
7. Amershi, S. et al. (2019), ‘Guidelines for Human-AI Interaction’, Proceedings of CHI 2019. doi:10.1145/3290605.3300233.
8. National Institute of Standards and Technology (2023), ‘AI Risk Management and Human-AI Interaction’, AI RMF Appendix C. NIST AIRC.
9. National Institute of Standards and Technology (2023), ‘AI Risk Management Framework: Core’. NIST AIRC Core.
10. National Institute of Standards and Technology (2023), Artificial Intelligence Risk Management Framework 1.0, NIST AI 100-1. doi:10.6028/NIST.AI.100-1.
11. OECD, Boston Consulting Group and INSEAD (2025), The Adoption of Artificial Intelligence in Firms: New Evidence for Policymaking. OECD Publishing.
12. European Union (2024), ‘Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence’, Articles 4 and 14. EUR-Lex.
13. Board of Governors of the Federal Reserve System, Office of the Comptroller of the Currency and Federal Deposit Insurance Corporation (2026), ‘Revised Guidance on Model Risk Management’, SR 26-2. Federal Reserve letter.
14. International Organization for Standardization and International Electrotechnical Commission (2023), ‘ISO/IEC 42001:2023, Information technology, Artificial intelligence, Management system’. ISO standard record.