Choose an application and a workflow before proposing a pilot. Infrastructure, delivery practices and people determine what can be adopted, what needs remediation and what the proposal must fund.
Authored adoption assumptions for discovery, not a certified maturity model or an assessed client. Technology names are examples. Unknown prerequisites remain gaps; no average score can override a missing requirement.
01 / The adoption architecture
Every assisted workflow rests on shared foundations
The three layers work together. Select a dependency to inspect the assumption and evidence behind it.
Use the controls to explore a discussion scenario, then inspect the required assumptions below. Assess each application separately; a usable API does not establish mobile, legacy or batch readiness.
Validate prerequisites before committing to adoption
Unknown prerequisites remain open. The register below identifies what to inspect; a named owner must review the evidence before pilot execution or benefit claims.
Levels are self-assessed discussion inputs. “Ready for owner review” is not approval or an independent assessment. Required capabilities must reach level 2; rollout also needs level 3 for shared platform ownership, people and evidence. Second-team validation is a bounded pilot extension: assess the second application, its owner and its support plan at pilot scope. Record the resulting reuse evidence before selecting supported rollout. The thresholds are an authored discovery method, not an industry certification.
JSON worksheet includes all inputs and gaps. Notes stay in this page until downloaded; reloading clears custom entries.
03 / The client adoption contract
Twelve assumptions to validate
For every required dependency, record evidence, an accountable person, an action and a review date. A plan or tool purchase is level 1; level 2 requires a repeatable demonstration in the selected application. Level 3 requires supported reuse by another team.
01
Define the work
Requirements & expected outcomes
Review applicability
Assumption. Approved requirements, representative defects and independent expected results are available for the selected journey.
Evidence to collect
A versioned scenario with source links, accepted edge cases and a named reviewer; a deliberately incorrect result is rejected.
Owner and first action
Product owner + domain QA. Resolve ambiguous payment rules and record the test oracle before generating assertions.
Example stack
Azure Boards, Test Plans and a reviewed scenario catalog
Our Banking Client case assumption
PAY-142 exists; product owners must confirm retry, concurrency and journal rules.
02
Run the work
Infrastructure & environments
Review applicability
Assumption. A permitted cloud or on-premises environment can run the application and tests with sufficient capacity, network routes, credentials and isolation.
Evidence to collect
Another engineer provisions or restores the pinned build, completes health checks and records reset time and runner capacity.
Owner and first action
Infrastructure / environment lead. Resolve runner access, image or package access, deployment drift and environment booking before execution.
Example stack
Existing Azure environment and pipeline agents; infrastructure as code where supported
Our Banking Client case assumption
Few shared test environments and shared data constrain the QA teams. Vendor-owned test environment capacity caps parallel integration runs; independent reset is not established.
03
Run the work
DevOps & delivery pipelines
Review applicability
Assumption. Builds, tests, deployments and configuration are versioned and can be repeated without undocumented manual steps.
Evidence to collect
A run links the commit, build, deployment, test and configuration revisions; a failed required test stops promotion.
Owner and first action
DevOps lead + application developer. Create a reproducible pipeline and retain mandatory suites before AI recommends test selection.
Example stack
Azure Pipelines or GitHub Actions; existing repositories and artifact stores
Our Banking Client case assumption
CI is available; deployment remains partly manual and artifact links need integration.
04
Run the work
Service virtualization & dependencies
Review applicability
Assumption. External APIs, callbacks, messages and legacy or batch dependencies have an explicit test strategy: controlled substitutes where suitable and scheduled real integration checks.
Evidence to collect
Versioned contracts and scenarios reproduce success, timeout, duplicate and delayed responses; a provider check detects drift from the real integration.
Owner and first action
Integration lead + dependency owner. Inventory protocols and owners, agree stub fidelity and refresh triggers, and book a sandbox or batch window for what cannot be simulated.
Example stack
WireMock for HTTP behavior; Pact where applicable for contracts; protocol-specific simulators for messages or legacy systems
Our Banking Client case assumption
Backend services are not virtualized at baseline. Versioned provider substitutes are proposed work; limited vendor test environments and the shared settlement batch still need reserved real-integration windows.
05
Run the work
Test data & reset
Review applicability
Assumption. Permitted synthetic or appropriately controlled data preserves business relationships and can be isolated and reset per run.
Evidence to collect
Two runs start from known balances and relationships without interfering; data use, cleanup and reset duration are recorded.
Owner and first action
Test-data lead + application owner. Create deterministic fixtures and unique test accounts. Review data handling before model or runner access.
Example stack
PostgreSQL seed fixtures; Testcontainers for bounded service tests with a compatible runtime
Our Banking Client case assumption
Synthetic account fixtures and scripted reset are backlog items; shared records cannot establish repeatability.
06
Run the work
Application & integration testability
Review applicability
Assumption. The chosen application exposes controllable interfaces and observable outcomes; web, mobile and legacy constraints are assessed separately.
Evidence to collect
A retry can be injected and its transfer identity, journal count and balances inspected; batch and asynchronous completion are observable.
Owner and first action
Application architect + developer. Add test hooks, stable interfaces and outcome access, or narrow the pilot to an independently testable component.
Example stack
Java payment APIs, React web, existing mobile app and a separately scheduled settlement batch
Our Banking Client case assumption
Payment APIs are the candidate surface. UI reliability and batch independence require separate readiness checks.
07
Run the work
Frameworks, runners & devices
Review applicability
Assumption. Owned test suites provide meaningful assertions, dependable fixtures and the required API, web, mobile and nonfunctional coverage.
Evidence to collect
Tests catch an injected defect, reruns expose flakiness, and the selected browsers, devices and operating systems are available.
Owner and first action
Automation lead + application QA. Stabilize seed tests and ownership; retain required coverage while evaluating generated tests and maintenance suggestions.
Example stack
JUnit / REST Assured, Playwright, existing Selenium and Appium; current performance tooling
Our Banking Client case assumption
Some Java tests are usable; noisy UI tests and device scheduling require their own readiness decisions.
08
Operate the work
Observability & release evidence
Review applicability
Assumption. Runner results, logs, traces, defects and release records are accessible, correlated and retained for the intended review.
Evidence to collect
A failure can be traced from requirement and build to the original assertion, environment state, defect decision and fresh retest.
Owner and first action
QA lead + observability / release owner. Connect run IDs and artifacts; distinguish product, environment and test faults before AI triage is trusted.
Example stack
Pipeline artifacts, Playwright traces, OpenTelemetry signals and Azure Boards
Our Banking Client case assumption
Evidence is spread across tools; a joined run manifest and retention rules must be demonstrated.
09
Operate the work
AI access, data rules & evaluation
Review applicability
Assumption. The model and connectors are approved for the intended inputs, identities, locations and actions, with usable limits and human review.
Evidence to collect
Approved input boundaries, an access test, representative evaluation cases, model/prompt versions, spend limits and a safe disable path.
Owner and first action
AI platform owner + data owner. Confirm endpoint availability, permitted context, residency/retention requirements, licensing and action scope before connecting client assets.
Example stack
The client's approved model endpoint or coding assistant; selected versioned context before retrieval expansion
Our Banking Client case assumption
An approved endpoint and permission to use repository context are assumptions to validate, not installed capabilities.
10
Define the work
People, skills & offshore handoffs
Review applicability
Assumption. Domain reviewers, developers and platform engineers have allocated time, access and skills; supplier incentives support reuse and quality.
Evidence to collect
An offshore engineer submits a reviewable artifact and the named next owner accepts it within an agreed review window.
Owner and first action
QA delivery director + supplier lead. Provide repository and environment access, pair coaching, escalation paths and funded review time across time zones.
Example stack
A pilot pod drawn from the 75-person QA team in this scenario, with additional product, development and platform support
Our Banking Client case assumption
75 QA staff include 45 manual/domain testers; automation skills and working-hour overlap are uneven. Support effort is additional to the eight QA pilot roles.
11
Operate the work
Shared platform ownership & service capacity
Review applicability
Assumption. Reusable connectors, templates, data and runner services have an owner, support model, version policy and capacity for onboarding teams.
Evidence to collect
For a pilot, demonstrate an owned service with usable capacity and reviewed versions. For scale, a second team onboards without the pilot authors; support, upgrade, license and concurrency limits are tested and budgeted.
Owner and first action
QA platform product owner. Name the service owner and first support boundary; sequence adoption by capacity rather than enabling every team at once.
Example stack
A supported QA service catalog over the existing stack; Kubernetes and a vector database are optional design choices
Our Banking Client case assumption
A shared QA service is proposed. Cross-team reuse and support coverage have not been demonstrated.
12
Define the work
Baseline, funding & adoption evidence
Review applicability
Assumption. Comparable baseline work, foundation effort, recurring costs and intended use of released capacity are agreed before benefits are claimed.
Evidence to collect
A sampled release pack separates active work, waiting, review, rework, setup, platform operation and license/model costs.
Owner and first action
Sponsor + delivery measurement lead. Fund and schedule dependency remediation. Re-estimate the pilot when prerequisites change; separate automation gains from AI contribution.
Example stack
The effort model for Our Banking Client is illustrative; no client savings rate or fixed adoption date is inferred
Our Banking Client case assumption
The 300-hour baseline, 480-hour setup and 12-hour operating allowance are unverified planning assumptions, not a readiness budget.
04 / A dependency is more than an endpoint
Virtualize deliberately. Validate against reality.
For the payment retry pilot, a controllable provider substitute lets the team exercise timeout, delayed callback and duplicate-event behavior. Passing a stub test establishes behavior against that model; a separate real-integration check is still needed.
Separate integration gateVersioned contract + provider sandbox / real batch validation↔Refresh the substitute when the real dependency changes
Proposed payment test architecture. A passing substitute is evidence about the modeled behavior, not proof of compatibility with every real dependency. Dependency strategy and sources →
Protocol fit: WireMock is an HTTP example. Message brokers, mainframes, files and settlement batches may need different simulators, test harnesses or reserved integration windows.
Fidelity ownership: name the dependency owner, contract revision, data rules, state reset, fault scenarios, refresh trigger and sandbox comparison. Contract checks do not prove end-to-end financial correctness.
AI assistance: draft mappings and suggest edge cases from approved specifications. An integration engineer reviews them; deterministic tests verify behavior and a domain owner confirms the expected financial outcome.
05 / Make the assumptions part of the proposal
A funded path to adoption
Discover the actual constraintObserve one release. Record work, waits, application boundaries and dependency owners; collect evidence before selecting a maturity level.
Commission foundation workAgree a remediation backlog, support capacity, costs and review dates. Start with reviewed scenario drafts only when their own prerequisites are satisfied.
Demonstrate a bounded pilotRepeat the run with pinned build, test, data and dependency versions. Keep mandatory coverage; measure review and rework alongside AI contribution.
Prove reuse before rolloutA second team must onboard and operate the pattern. Verify platform support, licenses, runner capacity and ownership before widening adoption.
Commercial assumption: the 480 setup hours and 12 operating hours per release pack for Our Banking Client are illustrative allowances. They do not price this dependency backlog. Infrastructure work, service virtualization, data preparation, coaching, model/license spend and support must be estimated for the client; unresolved dependencies can change both cost and elapsed time.
Decision boundary: readiness permits a pilot review. It does not authorize a release, establish positive value or replace the quality and measurement gates.
Primary documentation reviewed 2026-09-07. These sources support engineering practices and technology capabilities; the dependency register, maturity thresholds and Our Banking Client assumptions are our authored proposal.
DORA: Test automation — Fast, reliable suites and shared developer/tester responsibility inform the framework and ownership assumptions.
DORA: Loosely coupled teams — Independent testing, dependency control and explicit service contracts inform the infrastructure and integration design.
WireMock: Service virtualization — HTTP stubs can model state, delay and faults. The fidelity checks and real-integration gate here are authored requirements.
OpenTelemetry: Signals — Telemetry signals inform the evidence integration design; instrumentation alone does not establish a correct financial outcome.
Pact: Introduction to contract testing — Consumer and provider interaction checks support compatibility; they do not replace end-to-end business-outcome tests.