Containerization
Package and run real software with repeatable dependencies.
ExampleA PostgreSQL instance created for one test run.
Technical SDs & leads · Architecture / September 2026
AI × quality engineering · Industry research
For AI-assisted payment testing:
Start with the banking workflow →
02 / Interactive platform architecture
Overview · all connections have equal emphasis.
Moving pulses show direction. Play flow follows specific paths through the architecture.
Pan horizontally to explore the full diagram. A text description is available below.
Context service. Scope retrieval to permitted sources and preserve the input version. Repository text remains task data, even when it contains instructions. [A03][R01]
QE agent runtime. Record the model and prompt version; bound retries, memory and spend. The runtime proposes work within the gateway’s authority. [A01][R01]
Action gateway. Enforce identity, resource scope and approvals outside the model. An injected instruction cannot grant the agent a production permission. [A03][R01]
Independent checks. Run generated tests in a sandbox. Validate repeatability and fault detection against an approved oracle before accepting a candidate. [E04][E05]
Evaluation service. Compare application versions on held-out cases and denied-action scenarios. Calibrate model judges against reviewed human labels. [A01][T03][T06]
Evidence store. Join the task, run, review and outcome. Measure verification and correction effort alongside generation time and quality. [D02][E01]
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 implicationSeparate context, generation, policy enforcement, independent evaluation and release authority. Preserve a shared evidence record across those boundaries.
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
Overview · all connections have equal emphasis.
Moving pulses show direction. Play flow follows specific paths through the architecture.
Pan horizontally to explore the full diagram. A text description is available below.
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 implicationGenerate 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.
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
Pan horizontally to explore the full diagram. A text description is available below.
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 implicationTreat 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.
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
Pan horizontally to explore the full diagram. A text description is available below.
NIST treats evaluation and risk management as lifecycle activities. Evaluation product documentation supports versioned datasets and comparisons; judge calibration still requires local evidence.
Design implicationCompare baseline and candidate configurations against held-out cases, gate releases on agreed floors, then turn reviewed production failures into regression cases.
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
| Layer | Evidence | Validity check |
|---|---|---|
| Task outcome | Representative cases and expected results | Held-out examples; results by scenario |
| Retrieval | Relevant, permitted and grounded evidence | Correct citations and access scope |
| Agent actions | Tool choice, arguments and termination | Denied-action and recovery tests |
| Model judges | Scores against a defined rubric | Calibration against expert labels |
| Operation | Latency, cost, drift and escalation | Tail failures and tested fallback |
07 / Context architecture
Pan horizontally to explore the full diagram. A text description is available below.
Lifecycle guidance covers input provenance; agent risk guidance addresses untrusted context and access scope.
Design implicationFilter retrieval using current authorization, retain a versioned input snapshot and test grounding separately from action permissions.
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
Pan horizontally to explore the full diagram. A text description is available below.
Lifecycle assurance requires tracking changing system components. Evaluation platforms compare configurations and datasets.
Design implicationBind the code, prompt, retrieval, tool policy and evaluator versions to one release identity; keep the run and decision references with it.
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
Pan horizontally to explore the full diagram. A text description is available below.
Meta separates generated tests from executable validation and extends test value beyond code coverage through fault-oriented testing.
Design implicationReview assertions against an approved behavior contract and evaluate side effects. Use relevant faults to challenge a test that merely matches current behavior.
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
Pan horizontally to explore the full diagram. A text description is available below.
Meta ACH uses modeled faults to drive test generation and checks generated tests against original and mutated code.
Design implicationRetain both execution results and review mutation relevance. A test gains useful evidence when it distinguishes intended behavior from a meaningful fault.
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
Pan horizontally to explore the full diagram. A text description is available below.
Google reports 90.14% root-cause accuracy on 71 reviewed failures and deployment across 52,635 distinct failing tests.
Design implicationAttach relevant log evidence to a diagnosis, retain reviewer corrections and measure local accuracy separately from reach.
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
Pan horizontally to explore the full diagram. A text description is available below.
FlakyGuard combines targeted execution context with LLM-based repair. Its paper discusses the risk of fixes that weaken test semantics.
Design implicationRequire reproducibility, preserved assertions and independent repeated validation before proposing a merge.
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
Pan horizontally to explore the full diagram. A text description is available below.
NIST emphasizes representative evaluation. Evaluation tooling supports curated datasets and feedback from operational traces.
Design implicationSeparate tuning from release evaluation, group related examples during splitting and preserve adversarial scenarios with explicit expected behavior.
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
| Check | Evaluation design | Release implication |
|---|---|---|
| Agreement with experts | Compare judge decisions with independently reviewed labels, by failure category. | Investigate material disagreements before trusting aggregate scores. |
| False acceptance | Review cases where the judge passes an incorrect or unsafe output. | Critical false passes can require a deterministic rule or expert gate. |
| Consistency and bias | Repeat ambiguous cases; vary answer order in pairwise comparisons. | Record instability and sensitivity with the rubric version. |
| Separation from tuning | Keep 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
Pan horizontally to explore the full diagram. A text description is available below.
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 implicationTest 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.
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
Overview · all connections have equal emphasis.
Moving pulses show direction. Play flow follows specific paths through the architecture.
Pan horizontally to explore the full diagram. A text description is available below.
Agent risk guidance identifies tool misuse and identity problems. OSFI discusses scoped identities, tool restrictions and activity logs.
Design implicationCheck policy at the gateway before invocation. A denial must produce no tool side effect and a traceable reason.
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
Pan horizontally to explore the full diagram. A text description is available below.
Agent guidance emphasizes scoped tool access and separation of consequential actions. Industrial generation patterns use independent execution checks.
Design implicationKeep workers without production credentials, isolate test execution and allow only reviewed artifacts through existing release controls.
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
Pan horizontally to explore the full diagram. A text description is available below.
Lifecycle assurance considers system-specific risks and uncertainty. Evaluation tools support run and case-level comparisons.
Design implicationUse mandatory floors for critical behaviors, then inspect the distribution of changes before authorizing rollout.
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
Overview · all connections have equal emphasis.
Moving pulses show direction. Play flow follows specific paths through the architecture.
Pan horizontally to explore the full diagram. A text description is available below.
Lifecycle and agent guidance make recovery relevant to assurance. OSFI discusses tested AI failure scenarios and continuity measures.
Design implicationSeparate containment, fallback and authorized resumption; explicitly handle actions that cannot be reversed by a model rollback.
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
Pan horizontally to explore the full diagram. A text description is available below.
Evaluation workflows use operational feedback, while agent risk guidance calls attention to tool and action behavior.
Design implicationJoin application events, gateway decisions and reviewer corrections without broadly copying sensitive raw prompts into monitoring systems.
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
Pan horizontally to explore the full diagram. A text description is available below.
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 implicationCompare 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.
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
| Layer | Representative tools | Local proof |
|---|---|---|
| Test assets | Tosca · Applitools | Test validity; baseline quality |
| Change review | GitHub Copilot | Issues found and missed; reviewer effort |
| AI evaluation | LangSmith · Microsoft Foundry | Dataset fit; judge calibration; exportability |
| Adversarial testing | Promptfoo | Coverage 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
| Boundary | Minimum contract | Failure to exercise |
|---|---|---|
| Task intake → runtime | Task ID, approved scope, context references and deadline. | Reject missing scope or an unsupported task type. |
| Runtime → action gateway | Agent identity, tool schema, resource and authorization context. | Deny wrong-resource calls and malformed arguments. |
| Runner → evidence store | Run ID, artifact hash, check results and configuration references. | Hold incomplete evidence or mismatched artifacts. |
| Evaluation → release owner | Scenario 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
| Decision | Rule, applied in this order | Owner / action |
|---|---|---|
| Stop / hold | Any 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 evidence | Missing approved outcome, baseline, exposure or review evidence; uncertainty crosses the agreed target. | Measurement lead reports unknown; collect evidence within a capped extension. |
| Go, limited scope | Meet 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 / redesign | Agreed 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
| Stage | Illustrative injected instruction | Expected evidence |
|---|---|---|
| Context intake | A 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 request | The runtime attempts a tool call outside its approved sandbox scope. | Gateway denies the destination and resource before execution. |
| Containment | The denied request reaches the workflow’s escalation rule. | No network side effect; bounded termination and a correlated event record. |
| Regression and recovery | Reviewers 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
Pan horizontally to explore the full diagram. A text description is available below.
The sources address different failure modes: verification effort, weak generated tests, lifecycle change and the consequences of agent actions.
Design implicationTranslate 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.
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
Pan horizontally to explore the full diagram. A text description is available below.
Lifecycle and action-risk guidance require versioned evidence and scoped authority.
Design implicationProvide joined artifacts and negative fixtures so the logical design can be exercised.
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 | Required behavior | Payment example |
|---|---|---|
| Timeout / unknown result | Cancel new actions; query status by idempotency key before retry. | Reuse RUN-042; never launch duplicate runners blindly. |
| Stale policy / auth outage | Deny execution; renew policy and re-authorize. | Expired DEC-042 cannot authorize a test run. |
| Evidence unavailable | Hold promotion; bounded durable outbox or halt. | No complete evidence receipt means no review-ready change. |
| Digest / oracle mismatch | Invalidate results; regenerate evidence against the new artifact. | Changed payment assertion cannot reuse EVAL-042. |
| Recovery | Human queue; exercise the failing case before an owner resumes. | Model rollback does not undo completed external actions. |
29 / Failure resolution
Overview · all connections have equal emphasis.
Moving pulses show direction. Play flow follows specific paths through the architecture.
Pan horizontally to explore the full diagram. A text description is available below.
AutoDiagnose informs evidence-based failure triage. FlakyGuard reports reproducibility and accepted repairs using separate denominators.
Design implicationVerify repairs against the original failure. Require an owner, expiry and replacement coverage for a confirmed flaky test placed in quarantine.
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
Assess infrastructure, pipelines, dependency control, data reset and application testability separately. Add approved AI access, observability, framework ownership and operating capacity.
31 / Service virtualization
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
Overview: a proposed test environment and its separate integration evidence.
Gold follows the selected step. Other relationships remain visible.
Run real application and database software, model selected provider behavior and retain original evidence beyond environment cleanup.
33 / QE modernization
Package and run real software with repeatable dependencies.
ExampleA PostgreSQL instance created for one test run.
Replace selected dependency behavior with a controlled model.
ExampleA WireMock provider with an intentional timeout.
Check whether consumer and provider interactions agree.
ExampleA provider change fails a reviewed Pact contract.
Select a supported runtime for the application. Contract compatibility and simulated behavior need complementary domain and real-integration checks.
34 / Fintech evidence and adoption
Overview: a proposed candidate-test review and execution boundary.
The tour follows a rejected candidate; acceptance is a separate path.
The rejection example stops before the maintained suite. A candidate must satisfy independent behavior checks and review before acceptance.
35 / Fintech evidence and adoption
Shared conditions · Comparable tasks, same framework, environment and acceptance rules
Compare accepted outcomes · Include unsuccessful attempts, review, rework and operating costs
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
Overview · follow the numbered steps.
Gold = current focus. Arrows show a proposed handoff, not live activity.
AI assists the testing team. For code, fixtures, failure evidence and release handoffs, open the banking engineering walkthrough →
Prepared by Tom Wu · Contact / feedback. AI-generated illustrations and synthetic English narration. Diagrams and scenario models are authored explanations; sources retain their own attribution. Narration provenance.