AI × QE Briefings Technical SDs & leads · Architecture

AI assurance architecture

Technical SDs & leads · Architecture / September 2026

Assurance across
the AI lifecycle

AI × quality engineering · Industry research
For AI-assisted payment testing:
Start with the banking workflow →

Conceptual AI assurance laboratory with evaluation and human oversight

02 / Interactive platform architecture

The enterprise assurance platform

Pan horizontally to explore the full diagram. A text description is available below.

Enterprise assurance platform overview; inspect components or follow the guided paths Team workflows IDE · workbench Delivery systems Repository · CI AI applications RAG · agents Context Permitted snapshots QE runtime Bounded plan + model Action gateway Identity + policy Checks Sandbox + validity Evidence store Run + artifact + decision Regression corpus Reviewed failure cases Release authority Reviewer + change gate Evaluation Held-out + adversarial
Inspect a component: Select a component in the diagram
Proposed logical architecture · select a component to inspect its role and research basis. [A01][A03][R01][E04]
Research behind this design & diagram description
Finding

NIST frames assurance across the lifecycle. OWASP and OSFI identify agent identity, tool authority and traceability as control concerns; Meta separates generation from validation.

Design implication

Separate context, generation, policy enforcement, independent evaluation and release authority. Preserve a shared evidence record across those boundaries.

Diagram in words

Engineers and delivery systems supply tasks and approved context. The runtime proposes actions through a policy gateway. Independent sandbox checks and application evaluations supply evidence to the release authority. Traces and decisions feed the evidence store; curated failures become regression cases.

Inspect methods and source documents →

03 / Runtime sequence

A generated payment-API test

Pan horizontally to explore the full diagram. A text description is available below.

Illustrative payment API test-generation sequence: contract, scoped context, candidate, policy-mediated execution, independent mutation test and reviewer approval Engineer / QE QE agent Policy gateway Sandbox / CI Reviewer 1 Contract: reject a negative payment amount 2 Request approved API contract + test patterns 3 Return scoped, versioned context 4 Submit candidate test + requested runner 5 Authorize sandbox run; no production access 6 Test must catch a seeded boundary fault 7 Evidence bundle: assertions, CI, mutation result 8 Human approval → existing merge controls Illustrative workflow · approved contract defines the oracle; generated tests cannot silently weaken it
Illustrative payment-API workflow · the approved contract defines correct behavior; all execution stays within the sandbox. [E04][E05][A03][R01]
Research behind this design & diagram description
Finding

Meta’s generation work filters candidates through executable checks; mutation-guided testing tests whether a candidate detects a fault. Agent guidance requires authority to be bounded at the action boundary.

Design implication

Generate a negative-amount test from an approved contract, execute it through a scoped gateway, retain the independent fault-detection result and route the evidence to a human reviewer.

Diagram in words

The engineer supplies the contract. The agent requests scoped context and proposes a test. The gateway authorizes sandbox execution. CI checks the candidate against a seeded boundary fault. The reviewer receives assertions and test evidence before using existing merge controls.

Inspect methods and source documents →

04 / Industrial evidence

Generated tests pass through quality gates

Pan horizontally to explore the full diagram. A text description is available below.

Meta TestGen-LLM evaluation: among 86 target test classes, 75 percent had a generated test that built, 57 percent had one that passed reliably, and 25 percent had one that increased coverage A PASSING TEST IS AN INTERMEDIATE RESULT Share of target test classes with at least one qualifying generated test Builds correctly Syntax and dependencies 75% Passes reliably Builds + non-flaky execution 57% Adds coverage Builds + passes + new line coverage 25% 0% 50% 100% Meta / FSE 2024 · §3.3 · 86 Kotlin components with existing test classes · reported percentages rounded Denominator is target test classes, not individual generated tests. Coverage is a proxy for test improvement.
Observed industrial evaluation · Meta TestGen-LLM, FSE 2024, §3.3. The three bars use the same test-class denominator. [E04][E05]
Research behind this design & diagram description
Finding

In Meta’s 86-component Kotlin evaluation, 75% of target test classes gained at least one generated test that built; 57% had one that also passed reliably; 25% had one that also increased line coverage.

Design implication

Treat generation as a candidate factory. Require independent checks for stability and added test value; use fault detection where possible because coverage alone does not establish semantic quality.

Diagram in words

The bars have a common zero-to-100-percent axis. The qualifying share drops from 75% for build success to 57% for reliable passing and 25% for added coverage. These percentages describe test classes, not individual generated tests.

Inspect methods and source documents →

05 / AI application architecture

Evaluation, release and feedback

Pan horizontally to explore the full diagram. A text description is available below.

Proposed AI evaluation architecture with versioned application configurations, held-out cases, independent evaluation, release decisions, monitoring and feedback Versioned application Model · prompt · retrieval Tools · permissions · memory Evaluation corpus Typical + adversarial cases Held-out set · human labels Baseline and candidate runs Same tasks and test conditions Record outputs AND tool actions Independent scoring Deterministic contracts Calibrated judges + expert review Quality by scenario; cost and latency versioned traces Release gate Agreed floors hold? Hold + investigate Failed case → diagnosis Revise config or control no Controlled deployment Canary / bounded exposure Human escalation + rollback yes Production monitoring Outcomes · drift · denials Trace samples · incidents · rework Case curation Review oracle + privacy Add failures to regression new cases Proposed application-level assurance · evaluate again when context, behavior or authority changes
Proposed evaluation and release architecture · the unit of assurance is the configured application. [A01][A02][T03][T06]
Research behind this design & diagram description
Finding

NIST treats evaluation and risk management as lifecycle activities. Evaluation product documentation supports versioned datasets and comparisons; judge calibration still requires local evidence.

Design implication

Compare baseline and candidate configurations against held-out cases, gate releases on agreed floors, then turn reviewed production failures into regression cases.

Diagram in words

Versioned application configurations and a held-out evaluation corpus feed comparable runs and independent scoring. A failed release gate holds the change for investigation. A passing gate leads to controlled deployment and production monitoring; curated failures refresh the corpus.

Inspect methods and source documents →

06 / Evaluation contract

Application evaluation contract

LayerEvidenceValidity check
Task outcomeRepresentative cases and expected resultsHeld-out examples; results by scenario
RetrievalRelevant, permitted and grounded evidenceCorrect citations and access scope
Agent actionsTool choice, arguments and terminationDenied-action and recovery tests
Model judgesScores against a defined rubricCalibration against expert labels
OperationLatency, cost, drift and escalationTail failures and tested fallback

07 / Context architecture

Approved context and retrieval boundaries

Pan horizontally to explore the full diagram. A text description is available below.

Proposed permission-aware retrieval pipeline with provenance and an untrusted-content boundary Approved sources Contracts + code Synthetic fixtures Access + retention Retrieval service User and agent scope Filter by current access Relevant passages Context snapshot Source IDs + versions Minimal task evidence Classified + traceable Agent runtime Read as task evidence Treat text as data Scoped proposals Retrieval evaluation Relevant evidence and correct citations Forbidden / stale access tests Action authority remains external Retrieved text cannot grant tool access Gateway rechecks the requested action Proposed checks include denied retrieval, access revocation, stale content and conflicting source passages.
Proposed context architecture · retrieval improves task evidence; permissions remain separately enforced. [A01][A03][R01]
Research behind this design & diagram description
Finding

Lifecycle guidance covers input provenance; agent risk guidance addresses untrusted context and access scope.

Design implication

Filter retrieval using current authorization, retain a versioned input snapshot and test grounding separately from action permissions.

Diagram in words

Approved sources feed scoped retrieval and a minimal context snapshot. The runtime treats that content as evidence. Retrieval checks evaluate relevance and access; the action gateway retains authority.

Inspect methods and source documents →

08 / Configuration architecture

The evaluated application has a release identity

Pan horizontally to explore the full diagram. A text description is available below.

Proposed versioned release bundle connecting application components and evaluation evidence APPLICATION RELEASE MANIFEST Model + prompt Provider / model revision System and task prompt IDs Retrieval + data Index and source snapshot Corpus and access policy IDs Tools + memory Schemas and allowed actions Memory rules and retention Evaluation contract Dataset, rubric and judge versions Thresholds and scenario groups Release identity Manifest hash + code commit Baseline and candidate run IDs Decision and approving owner A material component change creates a new candidate and triggers the relevant evaluation suite.
Proposed release manifest · the model name alone cannot identify the evaluated system. [A01][T03][T06]
Research behind this design & diagram description
Finding

Lifecycle assurance requires tracking changing system components. Evaluation platforms compare configurations and datasets.

Design implication

Bind the code, prompt, retrieval, tool policy and evaluator versions to one release identity; keep the run and decision references with it.

Diagram in words

A manifest contains model and prompt, retrieval and data, tools and memory, and the evaluation contract. A release identity binds those versions to evaluated runs and approval.

Inspect methods and source documents →

09 / Test validity

The source of expected behavior

Pan horizontally to explore the full diagram. A text description is available below.

Proposed independent test oracle showing expected behavior, generated assertions and execution evidence Approved behavior contract Reject negative payment amounts No balance or ledger change Implementation under test Current code may contain a defect Observed behavior is evidence Generated candidate test Input: a negative amount Contract-derived assertions Agent proposes the test Oracle review Check result + side effects Challenge weak assertions Independent execution Pass on valid implementation Fail on a relevant seeded fault A test can pass because it repeats the implementation’s mistake. The expected behavior needs an independent basis.
Illustrative payment contract · expected behavior is proposed for this example. [E04][E05]
Research behind this design & diagram description
Finding

Meta separates generated tests from executable validation and extends test value beyond code coverage through fault-oriented testing.

Design implication

Review assertions against an approved behavior contract and evaluate side effects. Use relevant faults to challenge a test that merely matches current behavior.

Diagram in words

The approved contract and implementation inform a candidate test. Separate oracle review checks intended behavior; independent execution checks both valid code and a seeded fault.

Inspect methods and source documents →

10 / Fault-detection architecture

Mutation-guided test generation

Pan horizontally to explore the full diagram. A text description is available below.

Proposed mutation-guided test generation: one candidate must pass original code and detect a selected fault Fault concern Fault: accepts negatives Select a relevant mutation Candidate test Generate for stated concern Preserve intended assertion Original implementation Candidate passes Preserve expected behavior Mutated implementation Test fails for target fault Exclude invalid faults Exclude equivalent faults Reviewable test evidence Results + fault rationale Human review before merge Refine the concern
Design pattern informed by Meta ACH · detecting selected mutants does not prove all real faults are covered. [E05]
Research behind this design & diagram description
Finding

Meta ACH uses modeled faults to drive test generation and checks generated tests against original and mutated code.

Design implication

Retain both execution results and review mutation relevance. A test gains useful evidence when it distinguishes intended behavior from a meaningful fault.

Diagram in words

A fault concern drives a candidate test. It must pass original code and fail a relevant mutated version. Combined evidence reaches review; weak results lead to refining the concern.

Inspect methods and source documents →

11 / Industrial diagnosis

Failure diagnosis with inspectable evidence

Pan horizontally to explore the full diagram. A text description is available below.

Proposed failure diagnosis workflow with log citations, review and separate accuracy and deployment populations Failing integration test Safe logs + trace IDs Relevant change context Diagnostic assistant Extract relevant log lines Cause + evidence Engineer review Confirm or correct cause Route remediation Outcome record Accepted / corrected Diagnosis effort GOOGLE: REVIEWED ACCURACY SAMPLE 90.14% 71 manually evaluated failures Root-cause accuracy in the reported case study GOOGLE: DEPLOYMENT POPULATION 52,635 distinct failing tests A separate population; accuracy was not measured on all of it Local pilot: blinded review of sampled causes, evidence correctness and total diagnosis effort.
Google case study (2026) plus a proposed local workflow · populations remain separate. [E06]
Research behind this design & diagram description
Finding

Google reports 90.14% root-cause accuracy on 71 reviewed failures and deployment across 52,635 distinct failing tests.

Design implication

Attach relevant log evidence to a diagnosis, retain reviewer corrections and measure local accuracy separately from reach.

Diagram in words

A failing test feeds an assistant and then an engineer review. The outcome record captures corrections and effort. Separate panels show the small accuracy sample and larger deployment population.

Inspect methods and source documents →

12 / Test maintenance

Flaky-test repair and semantic checks

Pan horizontally to explore the full diagram. A text description is available below.

Proposed flaky-test repair loop preserving test semantics and checking repeatability Reproduce the flake Record failure conditions Retain test intent Targeted context Dynamic call paths Timing and shared state Candidate repair Fix the failure cause Keep valid assertions Validation Vary conditions Review behavior Reject misleading stability Deleted assertions can hide a faulty repair. Review both the repair and the fault-detection capability. Failed validation returns to diagnosis Pattern informed by FlakyGuard’s Uber Go case; validate transferability to the local language and test environment.
Proposed repair assurance loop · inspired by a six-month industrial Go case. [E07]
Research behind this design & diagram description
Finding

FlakyGuard combines targeted execution context with LLM-based repair. Its paper discusses the risk of fixes that weaken test semantics.

Design implication

Require reproducibility, preserved assertions and independent repeated validation before proposing a merge.

Diagram in words

The workflow reproduces a flaky failure, gathers targeted context, proposes a repair and validates it. Semantically weak or unstable repairs return to diagnosis.

Inspect methods and source documents →

13 / Dataset architecture

The evaluation corpus lifecycle

Pan horizontally to explore the full diagram. A text description is available below.

Proposed evaluation corpus lifecycle with separate development, held-out and adversarial case sets Candidate cases Tasks + approved examples Reviewed service failures Synthetic edge cases Curation and labeling Minimize sensitive content Deduplicate related cases Review expected behavior Development set Prompt iteration and debugging Held-out evaluation Release comparison; restrict tuning access Adversarial set Authority, disclosure, recovery SPLIT RELATED CASES TOGETHER Near duplicates can make a held-out result look more general than it is. Version each case, source permission, expectation, scenario tag and review decision. Report results by important slice.
Proposed corpus design · set sizes depend on the task and consequences of failure. [A01][T03][T06]
Research behind this design & diagram description
Finding

NIST emphasizes representative evaluation. Evaluation tooling supports curated datasets and feedback from operational traces.

Design implication

Separate tuning from release evaluation, group related examples during splitting and preserve adversarial scenarios with explicit expected behavior.

Diagram in words

Candidate cases pass through privacy review, deduplication and labeling. They feed development, held-out and adversarial sets with distinct uses.

Inspect methods and source documents →

14 / Evaluator validity

Model judges need their own evaluation

CheckEvaluation designRelease implication
Agreement with expertsCompare judge decisions with independently reviewed labels, by failure category.Investigate material disagreements before trusting aggregate scores.
False acceptanceReview cases where the judge passes an incorrect or unsafe output.Critical false passes can require a deterministic rule or expert gate.
Consistency and biasRepeat ambiguous cases; vary answer order in pairwise comparisons.Record instability and sensitivity with the rubric version.
Separation from tuningKeep calibration examples separate from final evaluation cases.Recheck validity when the judge, prompt or task population changes.

Proposed calibration contract. Set agreement thresholds and assess judge accuracy for the local use case. [A01][T03][T06]

15 / QA agent boundaries

The tool authority boundary

Pan horizontally to explore the full diagram. A text description is available below.

QA agent boundaries: untrusted context reaches the model, but a policy gateway controls tools and resource access, with denied-action tests and bounded recovery UNTRUSTED INPUT Retrieved content Docs · web · code May carry instructions Tool output / memory Poisoned observations Persisted injected text Agent runtime Uses task + context Proposes arguments No self-granted access AUTHORITY BOUNDARY Policy gateway Identity + resource Allowlist + approval Deny outside scope request Allowed tools Scoped credentials Bounded execution Denied action No side effect Stop / escalate Test: poisoned context requests a production write → gateway denies → trace records identity, target and reason Proposed negative test · test recovery as well as refusal · finite coverage does not prove absence of other failure modes
Proposed threat model · the highlighted test follows an injected request all the way to enforcement and recovery. [A03][A04][R01]
Research behind this design & diagram description
Finding

OWASP identifies risks arising from untrusted inputs and agent tool use. OSFI’s July 2026 bulletin discusses agent identity, scoped tool access, traceability and resilience as sound practices.

Design implication

Test the system’s response when poisoned context asks for an unauthorized action. Assert no side effect, a recorded denial and a bounded escalation path—not just a polite refusal in the model’s answer.

Diagram in words

Untrusted documents, code, tool output and memory reach the agent runtime. The agent can request an action, but the gateway checks identity, resource and policy. Permitted calls reach scoped tools. Denied calls cause no side effect and stop or escalate.

Inspect methods and source documents →

16 / Enforcement sequence

A denied action through the gateway

Pan horizontally to explore the full diagram. A text description is available below.

Proposed sequence for a denied tool action: policy enforcement happens before execution Agent runtime Policy gateway Scoped tool Evidence store 1 Request action + resource + run ID 2 Check identity, policy and approval 3 Record denial + policy version 4 Return denial; stop or escalate No tool invocation Assert no side effect Negative case: a retrieved document requests a production write, while the agent has sandbox-only authority.
Proposed denial sequence · the test verifies execution and evidence, beyond the model’s response. [A03][R01]
Research behind this design & diagram description
Finding

Agent risk guidance identifies tool misuse and identity problems. OSFI discusses scoped identities, tool restrictions and activity logs.

Design implication

Check policy at the gateway before invocation. A denial must produce no tool side effect and a traceable reason.

Diagram in words

The runtime requests a production write. The gateway evaluates scope, records a denial and returns it to the runtime. The scoped tool is never invoked.

Inspect methods and source documents →

17 / Deployment architecture

Execution zones and production authority

Pan horizontally to explore the full diagram. A text description is available below.

Proposed execution zones separating agent orchestration, sandbox work and protected production AGENT ORCHESTRATION SANDBOX EXECUTION PROTECTED PRODUCTION Runtime worker Bounded task and retry budget No production credentials Ephemeral runner Task-scoped identity Synthetic / approved fixtures Existing release systems Protected deployment identity Separate change authority allow Controlled outputs Logs and test artifacts Redaction and retention rules Reviewed artifact Signed or verified provenance Independent approval evidence review Default-deny egress Explicit destinations and quotas Cleanup after every task Sandboxing limits consequences; it still needs access controls, escape tests and artifact validation.
Proposed deployment boundaries · zones represent authority, not a specific cloud product. [A03][R01][E04]
Research behind this design & diagram description
Finding

Agent guidance emphasizes scoped tool access and separation of consequential actions. Industrial generation patterns use independent execution checks.

Design implication

Keep workers without production credentials, isolate test execution and allow only reviewed artifacts through existing release controls.

Diagram in words

An orchestration worker invokes an ephemeral sandbox. Controlled artifacts reach review, then protected release systems. Production authority never belongs to the generating worker.

Inspect methods and source documents →

18 / Release architecture

Release floors and scenario-level decisions

Pan horizontally to explore the full diagram. A text description is available below.

Proposed release decision logic with mandatory floors and scenario-level evaluation Comparable runs Same held-out corpus Configuration versions Repeat runs as needed Mandatory floors Behavior + regression tests Denial + privacy scenarios Workflow latency / cost limits Hold and investigate Any mandatory floor fails Retain the failing scenario Release review Inspect scenario-level regressions Weigh gains + uncertainty Approve a bounded rollout fail pass A higher average score cannot override a failed critical scenario. Thresholds are agreed locally.
Proposed release logic · no universal score threshold is asserted. [A01][A02][T06]
Research behind this design & diagram description
Finding

Lifecycle assurance considers system-specific risks and uncertainty. Evaluation tools support run and case-level comparisons.

Design implication

Use mandatory floors for critical behaviors, then inspect the distribution of changes before authorizing rollout.

Diagram in words

Comparable runs reach a mandatory-floor check. Failure holds the candidate. Passing candidates proceed to review of scenario-level regressions and remaining uncertainty.

Inspect methods and source documents →

19 / Resilience architecture

Containment, fallback and recovery

Pan horizontally to explore the full diagram. A text description is available below.

Proposed recovery state machine for an AI workflow with bounded recovery authority Normal operation Approved configuration Active monitoring Containment Stop consequential actions Preserve relevant evidence Fallback service Approved prior route or manual queue Protect the underlying business process trigger route Recovery review Diagnose, patch and rerun failure scenarios Owner authorizes resumption stable fallback approved recovery Example triggers Provider outage, policy breach, budget limit or severe regression Reverting a model does not undo a completed side effect. Compensation and reconciliation need their own runbook.
Proposed recovery state machine · triggers and fallback capacity require local exercises. [A01][A03][R01]
Research behind this design & diagram description
Finding

Lifecycle and agent guidance make recovery relevant to assurance. OSFI discusses tested AI failure scenarios and continuity measures.

Design implication

Separate containment, fallback and authorized resumption; explicitly handle actions that cannot be reversed by a model rollback.

Diagram in words

A trigger moves normal operation to containment and fallback. Recovery review verifies a fix before an owner authorizes resumption. Completed side effects require separate reconciliation.

Inspect methods and source documents →

20 / Observability architecture

Operational evidence and feedback

Pan horizontally to explore the full diagram. A text description is available below.

Proposed observability pipeline linking operational events to quality, operations and evaluation records Application events Task and run IDs Timing and model usage Gateway decisions Requested action and resource Allow / deny + policy version Reviewer feedback Accepted / corrected result Failure reason and effort TELEMETRY COLLECTION BOUNDARY Join by run ID · Minimize payloads · Apply access and retention rules · Preserve event integrity Operations Service errors and tail latency Cost or retry-limit alerts Platform monitoring Unexpected tool patterns Denials and incident evidence Evaluation curation Reviewed failure cases Regression dataset candidates
Proposed event architecture · traces and derived evidence need their own data controls. [A01][T03][A03]
Research behind this design & diagram description
Finding

Evaluation workflows use operational feedback, while agent risk guidance calls attention to tool and action behavior.

Design implication

Join application events, gateway decisions and reviewer corrections without broadly copying sensitive raw prompts into monitoring systems.

Diagram in words

Three event streams enter a controlled telemetry boundary. The joined records support operations, platform monitoring and reviewed regression-case curation.

Inspect methods and source documents →

21 / Measurement architecture

Link work, review and outcomes

Pan horizontally to explore the full diagram. A text description is available below.

Measurement data model joining task, run, review and outcome records to measure net effort and quality by comparable task cohort Task Task ID · type · complexity Eligible cohort + baseline Preparation + execution Run run_id → task_id Model / prompt / context IDs Tool calls · cost · elapsed time Review review_id → run_id Decision + human effort Rework + checks Outcome outcome → task / artifact IDs Rework · defects · cycle time Period + capture basis Cohort comparison Matched tasks + quality floors Prep + run + review + rework Net effort, cost and uncertainty 1 : many 1 : many artifact link review effort Total human effort = preparation + execution + verification + correction + rework Proposed logical schema · retain identifiers and versions; minimize sensitive payloads · time saved requires a capture mechanism
Proposed measurement schema · identifiers link work, execution, review and observed outcomes. [D02][E01][E03][M01]
Research behind this design & diagram description
Finding

DORA’s qualitative work highlights verification friction. Experimental findings depend on the task and population; reported AI impact is not a universal savings rate.

Design implication

Compare like tasks and account for preparation, execution, review, correction and rework. Link quality and cost to the same cohort; recognize monetary value only with a confirmed capture mechanism.

Diagram in words

A task has multiple runs; a run may have several review records. Outcomes link through task and artifact identifiers. A cohort comparison joins baseline effort, run and review effort, rework and defects. Version identifiers make changes in tool configuration auditable.

Inspect methods and source documents →

22 / Technology composition

Tools occupy different assurance layers

LayerRepresentative toolsLocal proof
Test assetsTosca · ApplitoolsTest validity; baseline quality
Change reviewGitHub CopilotIssues found and missed; reviewer effort
AI evaluationLangSmith · Microsoft FoundryDataset fit; judge calibration; exportability
Adversarial testingPromptfooCoverage of actual tool authority

Reuse approved CI, identity and artifact storage; add thin adapters and owned evaluation datasets where required. Representative documentation, reviewed September 2026. Not a ranking or independent product benchmark. [T01][T02][T03][T04][T05][T06]

23 / Interface architecture

Integration contracts preserve replaceability

BoundaryMinimum contractFailure to exercise
Task intake → runtimeTask ID, approved scope, context references and deadline.Reject missing scope or an unsupported task type.
Runtime → action gatewayAgent identity, tool schema, resource and authorization context.Deny wrong-resource calls and malformed arguments.
Runner → evidence storeRun ID, artifact hash, check results and configuration references.Hold incomplete evidence or mismatched artifacts.
Evaluation → release ownerScenario results, threshold version, unresolved failures and decision record.Prevent promotion with stale or missing evaluation evidence.

Proposed interface requirements. Adapter compatibility and evidence export need local testing; ACS is a newly introduced standard with evolving implementation coverage. [A01][A03][A05][T03]

24 / Closing decision

Value within quality and control floors

DecisionRule, applied in this orderOwner / action
Stop / holdAny quality or authorization breach. Economic route: adequate evidence puts every selected case below 10% net effort saving.Control owner holds access; sponsor stops or re-scopes.
Insufficient evidenceMissing approved outcome, baseline, exposure or review evidence; uncertainty crosses the agreed target.Measurement lead reports unknown; collect evidence within a capped extension.
Go, limited scopeMeet the charter’s outcome, adoption ≥50%, floors and funded cost cap. Economic route: one case ≥15%. Cash claims also need Finance proof.Sponsor + control owner authorize the evidenced scope.
Extend / redesignAgreed target, adoption or cost criterion missed without a breach; economic result in 10–15% band.One new hypothesis; one extension ≤4 weeks.

25 / End-to-end architecture walkthrough

A poisoned-document exercise

StageIllustrative injected instructionExpected evidence
Context intakeA test specification asks the agent to export customer data to an external endpoint.Source provenance retained; retrieved content has no authority to grant access.
Action requestThe runtime attempts a tool call outside its approved sandbox scope.Gateway denies the destination and resource before execution.
ContainmentThe denied request reaches the workflow’s escalation rule.No network side effect; bounded termination and a correlated event record.
Regression and recoveryReviewers confirm the scenario and the expected control response.Sanitized case added to the adversarial corpus; recovery verified before retry.

Illustrative exercise, not an observed incident or a guarantee that all injection paths are covered. [A03][A04][R01]

26 / Research to implementation

Architecture decisions with evidence

Pan horizontally to explore the full diagram. A text description is available below.

Research-to-design map connecting DORA, Meta, NIST and OSFI findings with architecture decisions RESEARCH OBSERVATION DESIGN RESPONSE EVIDENCE TO RETAIN DORA / verification effort Generation can shift work into review. Join effort with run telemetry Measure net workflow effort Prep · review · correction D02 Meta / filtered test generation Passing is not proof of added value. Independent test-quality gate Protect approved assertions Stable runs · fault detection E04 · E05 NIST / lifecycle assurance Assurance continues in production. Version cases; feed failures back Re-evaluate configuration changes Case history · drift · release A01 · A02 OWASP + OSFI / agent actions Tools expand the impact of failure. Enforce permissions outside the model Test denied actions and recovery Identity · decision · approval A03 · R01
Research → proposed design → evidence to retain. The architecture choices are our synthesis, not publisher endorsements. [D02][E04][E05][A01][A02][A03][R01]
Research behind this design & diagram description
Finding

The sources address different failure modes: verification effort, weak generated tests, lifecycle change and the consequences of agent actions.

Design implication

Translate each finding into an observable design requirement. Review burden needs effort telemetry; test generation needs a quality gate; changing AI needs repeatable evaluation; tool use needs enforceable permissions.

Diagram in words

DORA informs joined effort measurement. Meta informs independent test-quality gates. NIST informs versioned evaluation and feedback. OWASP and OSFI inform external permission enforcement. Each design response has an associated evidence record.

Inspect methods and source documents →

27 / Worked design

A payment test has four joined contracts

Pan horizontally to explore the full diagram. A text description is available below.

Four joined artifacts for payment API test generation Task envelope PAY-042 · payments-api Versioned input hashes Scope · expiry · budget Policy decision DEC-042 · policy v7 Allow sandbox test only Identity + expiry binding Evaluation manifest EVAL-042 · corpus v3 Original passes Mutant fails Artifact + runner hashes Evidence record RUN-042 · review held Links all three artifacts No self-approval Every boundary verifies identity, versions, expiry, resource scope and the same artifact digest. Mismatch, unavailable authorization or missing durable evidence → hold; no promotion.
Runnable reference contracts · synthetic example, not a production integration. [A01][A03][R01]
Research behind this design & diagram description
Finding

Lifecycle and action-risk guidance require versioned evidence and scoped authority.

Design implication

Provide joined artifacts and negative fixtures so the logical design can be exercised.

Diagram in words

A payment test task binds permitted context, resource scope and deadline. A policy decision authorizes only the sandbox action. An evaluation manifest joins artifact and corpus versions. The evidence record links task, policy and evaluation and remains held for human review.

Inspect methods and source documents →

28 / Worked design

Failure semantics are part of the contract

FailureRequired behaviorPayment example
Timeout / unknown resultCancel new actions; query status by idempotency key before retry.Reuse RUN-042; never launch duplicate runners blindly.
Stale policy / auth outageDeny execution; renew policy and re-authorize.Expired DEC-042 cannot authorize a test run.
Evidence unavailableHold promotion; bounded durable outbox or halt.No complete evidence receipt means no review-ready change.
Digest / oracle mismatchInvalidate results; regenerate evidence against the new artifact.Changed payment assertion cannot reuse EVAL-042.
RecoveryHuman queue; exercise the failing case before an owner resumes.Model rollback does not undo completed external actions.

29 / Failure resolution

Repair the failure or track the exception

Pan horizontally to explore the full diagram. A text description is available below.

Failed test through reviewed repair, with a separate temporary quarantine and coverage path Failed test CI trace + fixture + source hash Capture repeatability evidence Evidence-based triage Product / test / data / environment Owner confirms the cause Draft repair Product or test change proposal Preserve the domain assertion Independent retest Reproduce, then verify the repair Run relevant regression cases Reviewer approves the change Temporary quarantine Only a confirmed flaky test Owner + expiry + repair ticket Keep replacement coverage if flaky Resolution record Verified fix / tracked exception Outcome + reviewer + versions Recheck quarantine until restored
Proposed QA workflow · a temporary quarantine is not a successful repair. [E06][E07]
Research behind this design & diagram description
Finding

AutoDiagnose informs evidence-based failure triage. FlakyGuard reports reproducibility and accepted repairs using separate denominators.

Design implication

Verify repairs against the original failure. Require an owner, expiry and replacement coverage for a confirmed flaky test placed in quarantine.

Diagram in words

Capture CI traces, fixture versions and repeatability evidence. An owner confirms whether the cause is product, test, data or environment. Proposed repairs require an independent retest and relevant regression. A confirmed flaky test may instead enter a time-limited quarantine with replacement coverage. Both paths keep a resolution record; the quarantined test remains open until restored.

Inspect methods and source documents →

30 / Client adoption assumptions

Platform prerequisites for the selected workflow

Adoption decisionRequired evidence accepted · owner accountable · foundation work funded
Business & peopleExpected outcomes · reviewer capacity · offshore handoffs · measured baseline
Runnable engineeringInfrastructure · CI/CD · test data · dependency control · testable applications
Supported servicesFrameworks & devices · AI access · run evidence · platform ownership
Authored adoption assumptions. Validate each application and workflow; unknown requirements remain open. Assumptions and evidence →

Assess infrastructure, pipelines, dependency control, data reset and application testability separately. Add approved AI access, observability, framework ownership and operating capacity.

31 / Service virtualization

Controlled dependencies and real integration

Reviewed payment testSame key · retry · expected balances
Payment servicePinned build and isolated fixture
Controlled providerTimeout · delay · duplicate callback
Separate integration gateVersioned contract + provider sandbox / real batch validationRefresh 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 →

An integration engineer owns contract fidelity, state reset and refresh triggers. AI may draft HTTP mappings; message, mobile and legacy dependencies need their own test strategy.

32 / QE modernization

A repeatable test environment

DISPOSABLE TEST ENVIRONMENT · PINNED BUILD, FIXTURES AND MODELS CI / test runnerJUnit + API testsReviewed tests Payment applicationReal service under test Provider substituteWireMock state + faults PostgreSQLReal engine + fixtures Lifecycle owner suppliesreadiness, reset and cleanup Retained evidence and accountable reviewFailures remain failures after the environment is removed Separate real integrationProvider + settlement checks
Proposed test architecture for Our Banking Client. Blue runs real software, dashed gray marks the simulated provider and green retains evidence. Human review uses amber elsewhere; AI assistance uses purple. Arrows show selected calls and evidence handoffs, not live activity. Architecture explanation and sources

Run real application and database software, model selected provider behavior and retain original evidence beyond environment cleanup.

33 / QE modernization

Containerization, virtualization and contracts

RUN

Containerization

Package and run real software with repeatable dependencies.

Example

A PostgreSQL instance created for one test run.

SIMULATE

Service virtualization

Replace selected dependency behavior with a controlled model.

Example

A WireMock provider with an intentional timeout.

CHECK

Contract testing

Check whether consumer and provider interactions agree.

Example

A provider change fails a reviewed Pact contract.

These capabilities complement each other. They do not establish complete business correctness or replace all real integration checks. Technology choices and limitations

Select a supported runtime for the application. Contract compatibility and simulated behavior need complementary domain and real-integration checks.

34 / Fintech evidence and adoption

Independent checks for generated tests

Approved intentRules + contextDomain-owned AI draftCandidate testsVersioned output Human reviewCheck assertionsApprove to run CI challengeNormal buildKnown fault Rejected candidate → reworkNo suite update; preserve the failed evidence Maintained suiteAccepted tests + evidence Required check not metChecks met
Proposed design, not a bank's deployed architecture. The guided example ends at rejection. Independent checks and review determine acceptance. Practice and evidence.

The rejection example stops before the maintained suite. A candidate must satisfy independent behavior checks and review before acceptance.

35 / Fintech evidence and adoption

Measuring the incremental AI effect

Shared conditions · Comparable tasks, same framework, environment and acceptance rules

Conventional work

  1. Engineer drafts
  2. Reviewer checks
  3. Tests challenge behavior
  4. Retain results and effort

AI-assisted work

  1. AI + engineer draft
  2. Reviewer checks
  3. Tests challenge behavior
  4. Retain results and effort

Compare accepted outcomes · Include unsuccessful attempts, review, rework and operating costs

Proposed evaluation design informed by ANZ's study limitations and METR's selection findings. Separate modernization gains from incremental AI effects.

Record every attempt and separate active effort, wait time and setup. Quality and net effort both inform whether to expand.

Our Banking Client / Authored payment scenario

AI-assisted payment QE: the end-to-end workflow

01 / Understand the change Story + contract + prior defectsClarification questions → AC-142 02 / Design test cases Accepted criteria + risk historyScenario matrix → CASE-142-R 03 / Draft unit tests Service source + approved behaviorJUnit candidate → reviewed unit test 04 / Build API / UI tests Matrix + helpers + API contractREST Assured / Playwright → PR-142 05 / Prepare data and stubs Synthetic accounts + provider contractSeed scripts + WireMock mappings 06 / Select and run tests Approved commit + mandatory suiteAzure Pipelines → JUnit XML + traces 07 / Investigate failures Assertion + trace + journal evidenceEvidence-linked defect draft 08 / Repair and retest Reviewed defect + source + testsApproved fix → fresh required suite 09 / Review release evidence Raw runs + coverage + dispositionsEvidence pack + regression case
Nine steps, one payment scenario. AI drafts or recommends; engineers review; CI executes; release owners decide.

AI assists the testing team. For code, fixtures, failure evidence and release handoffs, open the banking engineering walkthrough →

Slide notes

Dictionary · terms & acronyms ↗ (opens in a new tab)