Gold = current focus. Arrows show a proposed handoff, not live activity.
+
+
+
+
+
+ {% if include.name == "qe-three-states" %}
{% for node in journey.nodes %}
{{ node.measure }}{{ node.measure_detail }}
{% endfor %}
{% endif %}
+ {{ journey.caption }}
+
diff --git a/_includes/head_custom.html b/_includes/head_custom.html
index 38c1b2e..4a00f22 100644
--- a/_includes/head_custom.html
+++ b/_includes/head_custom.html
@@ -34,6 +34,7 @@
{% if page.fintech_evidence %}{% endif %}
+
{% unless page.readiness %}{% endunless %}
diff --git a/_layouts/deck.html b/_layouts/deck.html
index e9aff67..5b754aa 100644
--- a/_layouts/deck.html
+++ b/_layouts/deck.html
@@ -28,6 +28,7 @@
+
{% if page.fintech and page.case_audience == "technical" %}{% endif %}
{% if page.fintech %}{% endif %}
diff --git a/assets/audio/banking-journey-v1.22.0/evp/slide-20.mp3 b/assets/audio/banking-journey-v1.22.0/evp/slide-20.mp3
new file mode 100644
index 0000000..e6ff417
Binary files /dev/null and b/assets/audio/banking-journey-v1.22.0/evp/slide-20.mp3 differ
diff --git a/assets/audio/banking-journey-v1.22.0/evp/slide-20.vtt b/assets/audio/banking-journey-v1.22.0/evp/slide-20.vtt
new file mode 100644
index 0000000..385d6b9
--- /dev/null
+++ b/assets/audio/banking-journey-v1.22.0/evp/slide-20.vtt
@@ -0,0 +1,120 @@
+WEBVTT
+
+00:00:00.000 --> 00:00:03.120
+Let's follow what AI contributes
+to one banking release.
+
+00:00:03.320 --> 00:00:06.960
+Our example is a payment that
+times out after acceptance.
+
+00:00:07.080 --> 00:00:12.080
+The customer retries, and the team
+must prove that the money moves once.
+
+00:00:12.160 --> 00:00:14.560
+First, AI helps clarify the requirement.
+
+00:00:14.720 --> 00:00:17.640
+The product owner confirms
+the expected behavior.
+
+00:00:17.829 --> 00:00:22.400
+Second, AI drafts the test
+scenarios: normal payment,
+
+00:00:22.460 --> 00:00:27.600
+timeout, repeated callback, concurrent
+retry, and a conflicting request.
+
+00:00:27.760 --> 00:00:31.440
+Domain testers review the coverage
+and expected outcomes.
+
+00:00:31.953 --> 00:00:36.720
+Third, AI helps developers write unit
+tests for retry and duplicate-request
+
+00:00:36.787 --> 00:00:40.400
+logic. These are fast
+checks of code behavior;
+
+00:00:40.432 --> 00:00:42.641
+they do not replace
+payment integration tests.
+
+00:00:42.937 --> 00:00:46.480
+Fourth, AI turns accepted
+cases into candidate
+
+00:00:46.700 --> 00:00:49.800
+API and user-interface tests.
+
+00:00:49.886 --> 00:00:52.400
+Reviewers require
+money-movement assertions,
+
+00:00:52.460 --> 00:00:54.280
+not just a successful response.
+
+00:00:54.480 --> 00:00:57.760
+Fifth, AI helps draft synthetic data
+
+00:00:57.780 --> 00:01:00.880
+and provider simulations.
+Engineers validate them.
+
+00:01:01.200 --> 00:01:05.760
+Isolated environments and service
+virtualization make the work repeatable.
+
+00:01:06.647 --> 00:01:12.000
+Sixth, AI recommends relevant tests
+or requests an authorized pipeline run.
+
+00:01:12.180 --> 00:01:14.880
+The delivery pipeline executes the tests.
+
+00:01:14.984 --> 00:01:17.840
+Mandatory payment coverage stays in place.
+
+00:01:18.060 --> 00:01:21.200
+Seventh, AI connects failed assertions
+
+00:01:21.232 --> 00:01:24.560
+with logs and traces,
+and drafts a diagnosis.
+
+00:01:24.740 --> 00:01:28.720
+The team checks the evidence
+before accepting the explanation.
+
+00:01:29.177 --> 00:01:32.080
+Eighth, AI can propose a repair.
+
+00:01:32.280 --> 00:01:37.360
+A developer reviews the change, and the
+pipeline reruns the tests with fresh data.
+
+00:01:37.540 --> 00:01:40.400
+The expected payment behavior stays fixed.
+
+00:01:41.107 --> 00:01:45.520
+Ninth, AI assembles a linked release
+summary and suggests reviewed
+
+00:01:45.582 --> 00:01:50.000
+failures for the regression suite. People
+decide whether the evidence is sufficient.
+
+00:01:50.144 --> 00:01:55.120
+That is the end-to-end opportunity: less
+repetitive preparation and investigation,
+
+00:01:55.160 --> 00:01:58.960
+supported by dependable
+execution and accountable review.
+
+00:01:59.056 --> 00:02:02.240
+This is a proposed workflow
+to validate in a pilot.
diff --git a/assets/audio/banking-journey-v1.22.0/evp/slide-21.mp3 b/assets/audio/banking-journey-v1.22.0/evp/slide-21.mp3
new file mode 100644
index 0000000..524b861
Binary files /dev/null and b/assets/audio/banking-journey-v1.22.0/evp/slide-21.mp3 differ
diff --git a/assets/audio/banking-journey-v1.22.0/evp/slide-21.vtt b/assets/audio/banking-journey-v1.22.0/evp/slide-21.vtt
new file mode 100644
index 0000000..c6b2256
--- /dev/null
+++ b/assets/audio/banking-journey-v1.22.0/evp/slide-21.vtt
@@ -0,0 +1,83 @@
+WEBVTT
+
+00:00:00.000 --> 00:00:03.040
+Follow the same payment
+test through six handoffs.
+
+00:00:03.240 --> 00:00:06.480
+The approved requirement says
+a retry with the same key
+
+00:00:06.560 --> 00:00:09.840
+returns the original transfer
+and creates no second posting.
+
+00:00:10.060 --> 00:00:13.440
+The reviewed test matrix
+carries that intent forward.
+
+00:00:14.187 --> 00:00:16.240
+AI drafts a candidate test.
+
+00:00:16.440 --> 00:00:20.880
+A response-status check alone is too weak,
+so the reviewer requires the original
+
+00:00:20.924 --> 00:00:25.280
+transfer identifier, one journal,
+and independently agreed balances.
+
+00:00:25.440 --> 00:00:28.800
+That reviewed test becomes
+the change we can inspect.
+
+00:00:29.250 --> 00:00:32.720
+Now challenge the test
+with a deliberately faulty build.
+
+00:00:32.940 --> 00:00:36.880
+Our illustrative run finds two
+journals where one was expected.
+
+00:00:36.920 --> 00:00:40.320
+The test fails, and the original
+failure evidence is retained.
+
+00:00:40.960 --> 00:00:44.880
+AI links the failed assertion
+to the journal and trace evidence,
+
+00:00:44.920 --> 00:00:47.600
+and proposes
+a duplicate-posting diagnosis.
+
+00:00:47.813 --> 00:00:51.520
+An engineer confirms the cause
+and reviews the proposed fix.
+
+00:00:51.740 --> 00:00:54.400
+The pipeline performs a fresh retest.
+
+00:00:54.540 --> 00:00:58.880
+The corrected build must pass, while
+the deliberately faulty variant must still
+
+00:00:58.960 --> 00:01:04.400
+fail. Changing the test simply to accept
+two debits would invalidate the result.
+
+00:01:04.985 --> 00:01:10.000
+Finally, the release pack links the
+requirement, reviewed test, failed run,
+
+00:01:10.080 --> 00:01:14.560
+fix and retest. The release owner checks
+remaining coverage and real-provider
+
+00:01:14.607 --> 00:01:19.440
+integration evidence. A passing
+retest is an input to that decision,
+
+00:01:19.500 --> 00:01:24.080
+not automatic approval. All identifiers
+and results here are authored examples.
diff --git a/assets/audio/banking-journey-v1.22.0/evp/slide-6.mp3 b/assets/audio/banking-journey-v1.22.0/evp/slide-6.mp3
new file mode 100644
index 0000000..d330389
Binary files /dev/null and b/assets/audio/banking-journey-v1.22.0/evp/slide-6.mp3 differ
diff --git a/assets/audio/banking-journey-v1.22.0/evp/slide-6.vtt b/assets/audio/banking-journey-v1.22.0/evp/slide-6.vtt
new file mode 100644
index 0000000..5ed1af3
--- /dev/null
+++ b/assets/audio/banking-journey-v1.22.0/evp/slide-6.vtt
@@ -0,0 +1,59 @@
+WEBVTT
+
+00:00:00.000 --> 00:00:04.720
+Start with today's manual workflow. People
+copy cases, prepare shared accounts,
+
+00:00:04.768 --> 00:00:08.240
+wait for a vendor test slot,
+and reconcile screenshots and logs.
+
+00:00:08.411 --> 00:00:12.840
+Seventy-five testers still face
+the same environment bottleneck.
+
+00:00:13.040 --> 00:00:15.360
+Now separate the modernization step.
+
+00:00:15.456 --> 00:00:18.560
+Engineers create reviewed automated tests,
+
+00:00:18.622 --> 00:00:22.440
+isolated data, and validated
+simulations of the payment provider.
+
+00:00:22.570 --> 00:00:26.880
+The delivery pipeline runs those
+tests and retains the evidence.
+
+00:00:26.976 --> 00:00:29.760
+That repeatability is
+valuable even without AI.
+
+00:00:29.952 --> 00:00:33.040
+Real-provider checks still
+need vendor capacity.
+
+00:00:33.568 --> 00:00:38.960
+Then add AI assistance. It helps
+draft cases, test code and fixtures,
+
+00:00:39.004 --> 00:00:43.200
+recommends relevant coverage, and helps
+explain failures and summarize proof.
+
+00:00:43.328 --> 00:00:48.240
+Engineers review the outputs,
+existing runners execute, and people make
+
+00:00:48.280 --> 00:00:53.200
+release decisions. Compare equivalent
+payment packs at all three stages.
+
+00:00:53.310 --> 00:00:58.080
+Measure waiting and reliability
+separately from AI drafting, review
+
+00:00:58.200 --> 00:01:03.440
+and rework. These are proposed states,
+not measured client improvements.
diff --git a/assets/audio/banking-journey-v1.22.0/industry-technical/slide-1.mp3 b/assets/audio/banking-journey-v1.22.0/industry-technical/slide-1.mp3
new file mode 100644
index 0000000..7a935ff
Binary files /dev/null and b/assets/audio/banking-journey-v1.22.0/industry-technical/slide-1.mp3 differ
diff --git a/assets/audio/banking-journey-v1.22.0/industry-technical/slide-1.vtt b/assets/audio/banking-journey-v1.22.0/industry-technical/slide-1.vtt
new file mode 100644
index 0000000..c9e4bad
--- /dev/null
+++ b/assets/audio/banking-journey-v1.22.0/industry-technical/slide-1.vtt
@@ -0,0 +1,43 @@
+WEBVTT
+
+00:00:00.000 --> 00:00:04.960
+This industry briefing explains assurance
+across the AI lifecycle: context,
+
+00:00:05.024 --> 00:00:10.080
+generated tests, independent evaluation,
+action controls and release evidence.
+
+00:00:10.320 --> 00:00:15.200
+It includes testing AI applications as
+well as using AI in quality engineering.
+
+00:00:15.440 --> 00:00:20.400
+If your immediate question is how AI
+helps an existing banking QA team,
+
+00:00:20.457 --> 00:00:22.960
+follow the banking workflow
+link on this slide.
+
+00:00:23.024 --> 00:00:27.440
+That engineering walkthrough traces one
+payment requirement through unit tests,
+
+00:00:27.540 --> 00:00:31.120
+API tests, fixtures, execution,
+
+00:00:31.192 --> 00:00:34.080
+diagnosis, repair and release evidence.
+
+00:00:34.300 --> 00:00:38.400
+The final slide here also
+provides that nine-step overview.
+
+00:00:38.446 --> 00:00:41.600
+Choose the banking route
+for concrete delivery handoffs,
+
+00:00:41.640 --> 00:00:44.640
+and this industry route
+for the wider assurance architecture.
diff --git a/assets/audio/banking-journey-v1.22.0/technical/slide-31.mp3 b/assets/audio/banking-journey-v1.22.0/technical/slide-31.mp3
new file mode 100644
index 0000000..e69baa5
Binary files /dev/null and b/assets/audio/banking-journey-v1.22.0/technical/slide-31.mp3 differ
diff --git a/assets/audio/banking-journey-v1.22.0/technical/slide-31.vtt b/assets/audio/banking-journey-v1.22.0/technical/slide-31.vtt
new file mode 100644
index 0000000..df97da3
--- /dev/null
+++ b/assets/audio/banking-journey-v1.22.0/technical/slide-31.vtt
@@ -0,0 +1,194 @@
+WEBVTT
+
+00:00:00.000 --> 00:00:02.360
+Trace one release through nine handoffs.
+
+00:00:02.448 --> 00:00:05.920
+This is AI assistance to an existing
+payments testing team,
+
+00:00:05.973 --> 00:00:08.480
+distinct from evaluating
+an AI application.
+
+00:00:08.667 --> 00:00:13.280
+Start with approved context:
+the payment story, API contract
+
+00:00:13.360 --> 00:00:17.440
+and relevant defects.
+AI drafts clarification questions.
+
+00:00:17.580 --> 00:00:21.760
+Product and domain QA approve
+the rule that a same-key,
+
+00:00:21.824 --> 00:00:26.853
+same-payload retry returns the original
+transfer without a second posting.
+
+00:00:27.301 --> 00:00:30.240
+Next, test design produces
+a reviewed matrix.
+
+00:00:30.560 --> 00:00:33.920
+AI proposes timeout, duplicate callback,
+
+00:00:33.987 --> 00:00:37.080
+concurrency and conflicting-payload cases.
+
+00:00:37.154 --> 00:00:42.200
+Domain QA supplies the expected behavior
+independently of the implementation.
+
+00:00:42.420 --> 00:00:46.480
+A written case is an input to executable
+test code, not the code itself.
+
+00:00:46.880 --> 00:00:51.280
+The developer unit-test step uses
+the handler source and accepted behavior.
+
+00:00:51.520 --> 00:00:56.720
+Copilot can draft JUnit candidates for key
+validation and duplicate-request logic.
+
+00:00:56.900 --> 00:01:00.400
+The developer checks the fake
+repository and verifies
+
+00:01:00.460 --> 00:01:04.080
+one insertion for repeated
+calls. A passing unit test
+
+00:01:04.176 --> 00:01:07.733
+does not establish correctness across
+the real database and provider.
+
+00:01:08.100 --> 00:01:12.720
+The API and user-interface step turns
+the reviewed matrix into a pull request.
+
+00:01:12.880 --> 00:01:16.480
+REST Assured tests exercise
+the payment service;
+
+00:01:16.533 --> 00:01:21.000
+selected Playwright checks cover the
+customer's pending state and retry action.
+
+00:01:21.074 --> 00:01:24.960
+Reviewers require the original
+transfer identifier, one journal,
+
+00:01:24.980 --> 00:01:28.560
+and balances of ninety thousand
+and ten thousand minor units.
+
+00:01:28.760 --> 00:01:30.880
+A status-only assertion is rejected.
+
+00:01:31.552 --> 00:01:34.560
+Data and provider behavior
+are versioned inputs.
+
+00:01:34.880 --> 00:01:40.160
+AI can draft synthetic seed scripts and
+WireMock mappings for acceptance followed
+
+00:01:40.187 --> 00:01:44.640
+by a timeout. Engineers validate those
+mappings against the provider contract.
+
+00:01:44.768 --> 00:01:48.880
+Testcontainers and the delivery
+pipeline supply repeatable resources.
+
+00:01:49.072 --> 00:01:52.680
+Real-provider and settlement checks
+remain separate requirements.
+
+00:01:52.900 --> 00:01:57.840
+For execution, AI may recommend
+affected tests or request an authorized
+
+00:01:57.893 --> 00:02:02.560
+pipeline job. Azure Pipelines runs
+the approved suite and publishes raw
+
+00:02:02.760 --> 00:02:08.160
+JUnit results and traces. The mandatory
+payment suite cannot be silently omitted.
+
+00:02:08.286 --> 00:02:10.880
+Record the build, test commit,
+
+00:02:10.960 --> 00:02:14.480
+fixture and stub versions
+under the run identifier.
+
+00:02:14.846 --> 00:02:19.800
+During investigation, AI reads
+retained evidence and proposes a cause.
+
+00:02:19.947 --> 00:02:24.400
+In our injected-defect example, the
+assertion expects one journal but observes
+
+00:02:24.480 --> 00:02:28.280
+two. The defect draft
+must link that evidence.
+
+00:02:28.460 --> 00:02:30.480
+A reviewer confirms the diagnosis,
+
+00:02:30.500 --> 00:02:33.280
+and the original failing
+verdict remains unchanged.
+
+00:02:33.481 --> 00:02:37.961
+For repair, AI may propose a source
+change for developer review.
+
+00:02:38.049 --> 00:02:40.321
+Keep the accepted
+payment assertions fixed.
+
+00:02:40.481 --> 00:02:45.601
+The pipeline uses a fresh run identifier
+and isolated data for the retest.
+
+00:02:45.821 --> 00:02:48.481
+The corrected build must pass,
+
+00:02:48.521 --> 00:02:51.801
+and the deliberate duplicate-posting
+variant must still fail.
+
+00:02:52.041 --> 00:02:55.601
+For release evidence,
+AI drafts a summary of coverage,
+
+00:02:55.641 --> 00:02:59.481
+run results, reviewed
+dispositions and missing checks.
+
+00:02:59.591 --> 00:03:04.081
+The release owner reviews the linked pack,
+including required real-provider evidence.
+
+00:03:04.205 --> 00:03:08.441
+Accepted defects can become
+reviewed regression cases.
+
+00:03:08.531 --> 00:03:11.361
+The shared platform
+provides context access,
+
+00:03:11.405 --> 00:03:15.041
+artifact versions, scoped
+pipeline access and evidence
+
+00:03:15.097 --> 00:03:18.961
+retention across these steps;
+it does not replace the named owners.
diff --git a/assets/audio/banking-journey-v1.22.0/technical/slide-32.mp3 b/assets/audio/banking-journey-v1.22.0/technical/slide-32.mp3
new file mode 100644
index 0000000..79e43f3
Binary files /dev/null and b/assets/audio/banking-journey-v1.22.0/technical/slide-32.mp3 differ
diff --git a/assets/audio/banking-journey-v1.22.0/technical/slide-32.vtt b/assets/audio/banking-journey-v1.22.0/technical/slide-32.vtt
new file mode 100644
index 0000000..d10827c
--- /dev/null
+++ b/assets/audio/banking-journey-v1.22.0/technical/slide-32.vtt
@@ -0,0 +1,112 @@
+WEBVTT
+
+00:00:00.000 --> 00:00:03.520
+Begin with the approved requirement
+and its test-case reference.
+
+00:00:03.660 --> 00:00:08.080
+The same idempotency key and payload
+must return the original transfer.
+
+00:00:08.280 --> 00:00:13.160
+The test matrix carries that criterion
+into the unit and API layers.
+
+00:00:13.250 --> 00:00:16.321
+The identifiers in this diagram
+are authored trace examples.
+
+00:00:16.600 --> 00:00:19.680
+The AI candidate becomes
+a reviewed pull request.
+
+00:00:19.820 --> 00:00:23.360
+The unit test checks one insertion
+through a fake repository.
+
+00:00:23.540 --> 00:00:27.520
+The API test independently
+checks the original transfer ID,
+
+00:00:27.580 --> 00:00:32.240
+one balanced journal, payer balance
+ninety thousand, and recipient balance
+
+00:00:32.320 --> 00:00:36.561
+ten thousand minor units.
+A response-status check alone is rejected.
+
+00:00:36.820 --> 00:00:40.320
+The first run pins the fixture
+and provider-model revisions.
+
+00:00:40.450 --> 00:00:45.280
+Execute the deliberate duplicate-posting
+variant: one journal is expected,
+
+00:00:45.380 --> 00:00:48.720
+but two are observed.
+JUnit reports a failure.
+
+00:00:48.940 --> 00:00:53.240
+Retain the assertion, trace
+and journal identifiers before cleanup.
+
+00:00:53.312 --> 00:00:57.120
+This is a designed challenge,
+not a reported banking incident.
+
+00:00:57.340 --> 00:00:59.840
+The defect record links that failed run.
+
+00:01:00.133 --> 00:01:05.040
+AI proposes duplicate posting as
+a hypothesis, with evidence references.
+
+00:01:05.227 --> 00:01:08.720
+An engineer confirms the cause
+and reviews a production-code repair.
+
+00:01:08.850 --> 00:01:11.760
+Neither the AI summary
+nor the repair process
+
+00:01:11.900 --> 00:01:14.640
+may turn the original
+failed run into a pass.
+
+00:01:15.080 --> 00:01:19.680
+A fresh retest uses a new
+run identifier and unchanged
+
+00:01:19.720 --> 00:01:23.360
+payment expectations.
+The corrected build should pass,
+
+00:01:23.373 --> 00:01:25.920
+while the deliberately faulty
+variant must still fail.
+
+00:01:26.112 --> 00:01:30.920
+Link the source change and both results so
+the reviewer can inspect the difference.
+
+00:01:31.120 --> 00:01:35.920
+The release pack includes the approved
+requirement, test commit, fixture and stub
+
+00:01:35.984 --> 00:01:40.960
+revisions, failed run,
+reviewed defect, repair and retest.
+
+00:01:41.107 --> 00:01:44.720
+Check required coverage and real-provider
+evidence before deciding.
+
+00:01:44.853 --> 00:01:48.320
+If integration proof is absent,
+the pack records that gap;
+
+00:01:48.460 --> 00:01:50.880
+the diagram does not
+grant release approval.
diff --git a/assets/audio/banking-journey-v1.22.0/technical/slide-33.mp3 b/assets/audio/banking-journey-v1.22.0/technical/slide-33.mp3
new file mode 100644
index 0000000..ee4896a
Binary files /dev/null and b/assets/audio/banking-journey-v1.22.0/technical/slide-33.mp3 differ
diff --git a/assets/audio/banking-journey-v1.22.0/technical/slide-33.vtt b/assets/audio/banking-journey-v1.22.0/technical/slide-33.vtt
new file mode 100644
index 0000000..9d2025b
--- /dev/null
+++ b/assets/audio/banking-journey-v1.22.0/technical/slide-33.vtt
@@ -0,0 +1,69 @@
+WEBVTT
+
+00:00:00.000 --> 00:00:03.440
+The starting state has manual
+API requests and spreadsheets,
+
+00:00:03.474 --> 00:00:06.560
+shared environments, and no
+virtualized provider backend.
+
+00:00:06.720 --> 00:00:09.280
+QA engineers collect
+and reconcile evidence.
+
+00:00:09.394 --> 00:00:12.960
+Vendor test-slot availability
+constrains parallel execution.
+
+00:00:13.360 --> 00:00:18.400
+The modernized state introduces
+reviewed REST Assured and JUnit tests,
+
+00:00:18.444 --> 00:00:23.200
+delivery-pipeline execution, isolated
+fixtures and a validated WireMock provider
+
+00:00:23.253 --> 00:00:28.160
+model. Testcontainers supports
+repeatable service-test resources.
+
+00:00:28.320 --> 00:00:32.320
+Raw assertions, traces and run
+identifiers survive cleanup.
+
+00:00:32.480 --> 00:00:35.960
+This foundation creates repeatability
+without depending on AI.
+
+00:00:36.140 --> 00:00:40.080
+The AI-assisted state adds
+approved context, candidate
+
+00:00:40.136 --> 00:00:44.240
+artifacts and evidence-based assistance
+around that same execution path.
+
+00:00:44.560 --> 00:00:50.240
+AI drafts tests and fixtures, proposes
+relevant scope and diagnoses failures.
+
+00:00:50.366 --> 00:00:55.040
+Reviewers approve changes before
+existing runners execute them.
+
+00:00:55.110 --> 00:00:58.640
+Compare equivalent payment packs
+to distinguish modernization
+
+00:00:58.693 --> 00:01:02.400
+gains from incremental AI
+benefit. Include review,
+
+00:01:02.451 --> 00:01:06.081
+correction, platform overhead
+and real-provider checks.
+
+00:01:06.293 --> 00:01:08.800
+No measured improvement is
+claimed in this scenario.
diff --git a/assets/audio/banking-journey-v1.22.0/technical/slide-9.mp3 b/assets/audio/banking-journey-v1.22.0/technical/slide-9.mp3
new file mode 100644
index 0000000..7a83016
Binary files /dev/null and b/assets/audio/banking-journey-v1.22.0/technical/slide-9.mp3 differ
diff --git a/assets/audio/banking-journey-v1.22.0/technical/slide-9.vtt b/assets/audio/banking-journey-v1.22.0/technical/slide-9.vtt
new file mode 100644
index 0000000..a4d83b4
--- /dev/null
+++ b/assets/audio/banking-journey-v1.22.0/technical/slide-9.vtt
@@ -0,0 +1,52 @@
+WEBVTT
+
+00:00:00.000 --> 00:00:02.640
+Choose the test layer
+for the behavior you need to prove.
+
+00:00:02.773 --> 00:00:06.800
+Start with developer unit tests
+for idempotency-key validation
+
+00:00:06.900 --> 00:00:11.920
+and duplicate-request logic.
+Copilot can draft JUnit candidates,
+
+00:00:11.940 --> 00:00:14.560
+but developers review
+the assertions and test doubles.
+
+00:00:14.960 --> 00:00:18.560
+A fake repository cannot establish
+real payment integration.
+
+00:00:18.853 --> 00:00:23.920
+At the service and API layer,
+REST Assured and JUnit cover retry,
+
+00:00:23.973 --> 00:00:26.880
+concurrency, conflicts
+and journal outcomes.
+
+00:00:27.093 --> 00:00:30.560
+At the web layer, Playwright
+checks the pending state,
+
+00:00:30.640 --> 00:00:33.720
+retry action and final customer message.
+
+00:00:33.808 --> 00:00:37.920
+Keep the owned Selenium and Appium
+coverage for existing browser and mobile
+
+00:00:37.982 --> 00:00:42.800
+journeys. Batch settlement reconciliation
+and real-provider sandbox checks
+
+00:00:42.891 --> 00:00:47.920
+remain separate requirements. Generate
+tests within the appropriate layer;
+
+00:00:47.954 --> 00:00:51.760
+adding a browser framework does not
+resolve a scarce settlement environment.
diff --git a/assets/css/qe-journey.css b/assets/css/qe-journey.css
new file mode 100644
index 0000000..5d07c11
--- /dev/null
+++ b/assets/css/qe-journey.css
@@ -0,0 +1,29 @@
+/* The same authored handoffs are used by the reading page and narrated decks. */
+.qe-journey-figure .node-title { font-size:20px; }
+.qe-journey-figure .node-text { font-size:18px; }
+.qe-journey-details { display:grid; grid-template-columns:repeat(2,minmax(0,1fr)); gap:14px; margin:20px 0; }
+.qe-journey-details > details { border:1px solid #bdcfca; border-radius:8px; padding:14px 18px; background:#fff; }
+.qe-journey-details summary { cursor:pointer; color:#173744; font-weight:650; }
+.qe-journey-details dl { margin:12px 0 0; }
+.qe-journey-details dt { text-align:left; color:#096d69; margin-top:12px; font-weight:650; }
+.qe-journey-details dd { margin:4px 0 0; }
+.qe-journey-details code { white-space:normal; }
+.qe-journey-boundary { padding:14px 18px; background:#eef5f2; border-left:4px solid #096d69; }
+.qe-journey-links { display:flex; flex-wrap:wrap; gap:10px 20px; margin:16px 0; }
+.ft-slide:has(.qe-journey-figure) .slide-content { gap:8px; }
+.ft-slide:has(.qe-journey-figure) .ft-note { margin-top:6px; }
+.ft-slide:has([data-diagram="qe-journey"]) .qe-journey-figure .research-diagram { max-height:48cqw; }
+@media(max-width:700px) { .qe-journey-details { grid-template-columns:1fr; } }
+@media print {
+ .qe-journey-figure .diagram-view-controls,.qe-journey-figure .diagram-tour,.qe-journey-figure .diagram-overview { display:none!important; }
+ .qe-journey-figure .diagram-shell { display:block!important; }
+}
+
+.qe-state-measures { display:grid; grid-template-columns:repeat(3,minmax(0,1fr)); gap:18px; margin:18px 0; }
+.qe-state-measures > div { padding:14px 16px; border-top:3px solid #68a99c; background:#eef5f2; }
+.qe-state-measures strong,.qe-state-measures span { display:block; }
+.qe-state-measures span { margin-top:8px; color:#425f6d; }
+.deck-page .qe-state-measures { margin:1.3cqw 0; gap:1.5cqw; font-size:1.6cqw; line-height:1.35; }
+.deck-page .qe-state-measures > div { padding:1.2cqw; }
+.qe-cover-route { display:block; margin-top:12px; font-size:.85em; line-height:1.4; }
+@media(max-width:700px) { .qe-state-measures { grid-template-columns:1fr; }.deck-page .qe-state-measures { font-size:16px; } }
diff --git a/assets/data/narration-flows.json b/assets/data/narration-flows.json
index 6aa143a..b1c6b0b 100644
--- a/assets/data/narration-flows.json
+++ b/assets/data/narration-flows.json
@@ -968,6 +968,632 @@
"routes": []
}
]
+ },
+ {
+ "diagram": "qe-three-states",
+ "clip": "evp/slide-6",
+ "cues": [
+ {
+ "caption": 0,
+ "text": "Start with today's manual workflow. People copy cases, prepare shared accounts,",
+ "title": "01 / Manual QE",
+ "nodes": [
+ "manual"
+ ],
+ "routes": []
+ },
+ {
+ "caption": 3,
+ "text": "Now separate the modernization step.",
+ "title": "02 / Modernized QE",
+ "nodes": [
+ "modernized"
+ ],
+ "routes": [
+ "manual:modernized"
+ ]
+ },
+ {
+ "caption": 9,
+ "text": "Then add AI assistance. It helps draft cases, test code and fixtures,",
+ "title": "03 / AI-assisted QE",
+ "nodes": [
+ "assisted"
+ ],
+ "routes": [
+ "modernized:assisted"
+ ]
+ }
+ ]
+ },
+ {
+ "diagram": "qe-journey",
+ "clip": "evp/slide-20",
+ "cues": [
+ {
+ "caption": 0,
+ "text": "Let's follow what AI contributes to one banking release.",
+ "title": "01 / Understand the change",
+ "nodes": [
+ "intent"
+ ],
+ "routes": []
+ },
+ {
+ "caption": 5,
+ "text": "Second, AI drafts the test scenarios: normal payment,",
+ "title": "02 / Design test cases",
+ "nodes": [
+ "design"
+ ],
+ "routes": [
+ "intent:design"
+ ]
+ },
+ {
+ "caption": 8,
+ "text": "Third, AI helps developers write unit tests for retry and duplicate-request",
+ "title": "03 / Draft unit tests",
+ "nodes": [
+ "unit"
+ ],
+ "routes": [
+ "design:unit"
+ ]
+ },
+ {
+ "caption": 11,
+ "text": "Fourth, AI turns accepted cases into candidate",
+ "title": "04 / Build API / UI tests",
+ "nodes": [
+ "code"
+ ],
+ "routes": [
+ "unit:code"
+ ]
+ },
+ {
+ "caption": 15,
+ "text": "Fifth, AI helps draft synthetic data",
+ "title": "05 / Prepare data and stubs",
+ "nodes": [
+ "fixtures"
+ ],
+ "routes": [
+ "code:fixtures"
+ ]
+ },
+ {
+ "caption": 18,
+ "text": "Sixth, AI recommends relevant tests or requests an authorized pipeline run.",
+ "title": "06 / Select and run tests",
+ "nodes": [
+ "run"
+ ],
+ "routes": [
+ "fixtures:run"
+ ]
+ },
+ {
+ "caption": 21,
+ "text": "Seventh, AI connects failed assertions",
+ "title": "07 / Investigate failures",
+ "nodes": [
+ "triage"
+ ],
+ "routes": [
+ "run:triage"
+ ]
+ },
+ {
+ "caption": 24,
+ "text": "Eighth, AI can propose a repair.",
+ "title": "08 / Repair and retest",
+ "nodes": [
+ "repair"
+ ],
+ "routes": [
+ "triage:repair"
+ ]
+ },
+ {
+ "caption": 27,
+ "text": "Ninth, AI assembles a linked release summary and suggests reviewed",
+ "title": "09 / Review release evidence",
+ "nodes": [
+ "evidence"
+ ],
+ "routes": [
+ "repair:evidence"
+ ]
+ }
+ ]
+ },
+ {
+ "diagram": "qe-artifact-trace",
+ "clip": "evp/slide-21",
+ "cues": [
+ {
+ "caption": 0,
+ "text": "Follow the same payment test through six handoffs.",
+ "title": "01 / Approved intent",
+ "nodes": [
+ "criteria"
+ ],
+ "routes": []
+ },
+ {
+ "caption": 4,
+ "text": "AI drafts a candidate test.",
+ "title": "02 / AI candidate",
+ "nodes": [
+ "candidate"
+ ],
+ "routes": [
+ "criteria:candidate"
+ ]
+ },
+ {
+ "caption": 8,
+ "text": "Now challenge the test with a deliberately faulty build.",
+ "title": "03 / Challenge the test",
+ "nodes": [
+ "failed"
+ ],
+ "routes": [
+ "candidate:failed"
+ ]
+ },
+ {
+ "caption": 11,
+ "text": "AI links the failed assertion to the journal and trace evidence,",
+ "title": "04 / Investigate and repair",
+ "nodes": [
+ "diagnosis"
+ ],
+ "routes": [
+ "failed:diagnosis"
+ ]
+ },
+ {
+ "caption": 14,
+ "text": "The pipeline performs a fresh retest.",
+ "title": "05 / Fresh retest",
+ "nodes": [
+ "retest"
+ ],
+ "routes": [
+ "diagnosis:retest"
+ ]
+ },
+ {
+ "caption": 17,
+ "text": "Finally, the release pack links the requirement, reviewed test, failed run,",
+ "title": "06 / Release review",
+ "nodes": [
+ "decision"
+ ],
+ "routes": [
+ "retest:decision"
+ ]
+ }
+ ]
+ },
+ {
+ "diagram": "qe-journey",
+ "clip": "technical/slide-31",
+ "cues": [
+ {
+ "caption": 0,
+ "text": "Trace one release through nine handoffs.",
+ "title": "01 / Understand the change",
+ "nodes": [
+ "intent"
+ ],
+ "routes": []
+ },
+ {
+ "caption": 7,
+ "text": "Next, test design produces a reviewed matrix.",
+ "title": "02 / Design test cases",
+ "nodes": [
+ "design"
+ ],
+ "routes": [
+ "intent:design"
+ ]
+ },
+ {
+ "caption": 12,
+ "text": "The developer unit-test step uses the handler source and accepted behavior.",
+ "title": "03 / Draft unit tests",
+ "nodes": [
+ "unit"
+ ],
+ "routes": [
+ "design:unit"
+ ]
+ },
+ {
+ "caption": 17,
+ "text": "The API and user-interface step turns the reviewed matrix into a pull request.",
+ "title": "04 / Build API / UI tests",
+ "nodes": [
+ "code"
+ ],
+ "routes": [
+ "unit:code"
+ ]
+ },
+ {
+ "caption": 23,
+ "text": "Data and provider behavior are versioned inputs.",
+ "title": "05 / Prepare data and stubs",
+ "nodes": [
+ "fixtures"
+ ],
+ "routes": [
+ "code:fixtures"
+ ]
+ },
+ {
+ "caption": 28,
+ "text": "For execution, AI may recommend affected tests or request an authorized",
+ "title": "06 / Select and run tests",
+ "nodes": [
+ "run"
+ ],
+ "routes": [
+ "fixtures:run"
+ ]
+ },
+ {
+ "caption": 33,
+ "text": "During investigation, AI reads retained evidence and proposes a cause.",
+ "title": "07 / Investigate failures",
+ "nodes": [
+ "triage"
+ ],
+ "routes": [
+ "run:triage"
+ ]
+ },
+ {
+ "caption": 38,
+ "text": "For repair, AI may propose a source change for developer review.",
+ "title": "08 / Repair and retest",
+ "nodes": [
+ "repair"
+ ],
+ "routes": [
+ "triage:repair"
+ ]
+ },
+ {
+ "caption": 43,
+ "text": "For release evidence, AI drafts a summary of coverage,",
+ "title": "09 / Review release evidence",
+ "nodes": [
+ "evidence"
+ ],
+ "routes": [
+ "repair:evidence"
+ ]
+ }
+ ]
+ },
+ {
+ "diagram": "qe-artifact-trace",
+ "clip": "technical/slide-32",
+ "cues": [
+ {
+ "caption": 0,
+ "text": "Begin with the approved requirement and its test-case reference.",
+ "title": "01 / Approved intent",
+ "nodes": [
+ "criteria"
+ ],
+ "routes": []
+ },
+ {
+ "caption": 4,
+ "text": "The AI candidate becomes a reviewed pull request.",
+ "title": "02 / AI candidate",
+ "nodes": [
+ "candidate"
+ ],
+ "routes": [
+ "criteria:candidate"
+ ]
+ },
+ {
+ "caption": 9,
+ "text": "The first run pins the fixture and provider-model revisions.",
+ "title": "03 / Challenge the test",
+ "nodes": [
+ "failed"
+ ],
+ "routes": [
+ "candidate:failed"
+ ]
+ },
+ {
+ "caption": 14,
+ "text": "The defect record links that failed run.",
+ "title": "04 / Investigate and repair",
+ "nodes": [
+ "diagnosis"
+ ],
+ "routes": [
+ "failed:diagnosis"
+ ]
+ },
+ {
+ "caption": 19,
+ "text": "A fresh retest uses a new run identifier and unchanged",
+ "title": "05 / Fresh retest",
+ "nodes": [
+ "retest"
+ ],
+ "routes": [
+ "diagnosis:retest"
+ ]
+ },
+ {
+ "caption": 23,
+ "text": "The release pack includes the approved requirement, test commit, fixture and stub",
+ "title": "06 / Release review",
+ "nodes": [
+ "decision"
+ ],
+ "routes": [
+ "retest:decision"
+ ]
+ }
+ ]
+ },
+ {
+ "diagram": "qe-three-states",
+ "clip": "technical/slide-33",
+ "cues": [
+ {
+ "caption": 0,
+ "text": "The starting state has manual API requests and spreadsheets,",
+ "title": "01 / Manual QE",
+ "nodes": [
+ "manual"
+ ],
+ "routes": []
+ },
+ {
+ "caption": 4,
+ "text": "The modernized state introduces reviewed REST Assured and JUnit tests,",
+ "title": "02 / Modernized QE",
+ "nodes": [
+ "modernized"
+ ],
+ "routes": [
+ "manual:modernized"
+ ]
+ },
+ {
+ "caption": 9,
+ "text": "The AI-assisted state adds approved context, candidate",
+ "title": "03 / AI-assisted QE",
+ "nodes": [
+ "assisted"
+ ],
+ "routes": [
+ "modernized:assisted"
+ ]
+ }
+ ]
+ },
+ {
+ "diagram": "qe-journey",
+ "clip": "industry-evp/slide-26",
+ "cues": [
+ {
+ "caption": 0,
+ "text": "Let's follow what AI contributes to one banking release.",
+ "title": "01 / Understand the change",
+ "nodes": [
+ "intent"
+ ],
+ "routes": []
+ },
+ {
+ "caption": 5,
+ "text": "Second, AI drafts the test scenarios: normal payment,",
+ "title": "02 / Design test cases",
+ "nodes": [
+ "design"
+ ],
+ "routes": [
+ "intent:design"
+ ]
+ },
+ {
+ "caption": 8,
+ "text": "Third, AI helps developers write unit tests for retry and duplicate-request",
+ "title": "03 / Draft unit tests",
+ "nodes": [
+ "unit"
+ ],
+ "routes": [
+ "design:unit"
+ ]
+ },
+ {
+ "caption": 11,
+ "text": "Fourth, AI turns accepted cases into candidate",
+ "title": "04 / Build API / UI tests",
+ "nodes": [
+ "code"
+ ],
+ "routes": [
+ "unit:code"
+ ]
+ },
+ {
+ "caption": 15,
+ "text": "Fifth, AI helps draft synthetic data",
+ "title": "05 / Prepare data and stubs",
+ "nodes": [
+ "fixtures"
+ ],
+ "routes": [
+ "code:fixtures"
+ ]
+ },
+ {
+ "caption": 18,
+ "text": "Sixth, AI recommends relevant tests or requests an authorized pipeline run.",
+ "title": "06 / Select and run tests",
+ "nodes": [
+ "run"
+ ],
+ "routes": [
+ "fixtures:run"
+ ]
+ },
+ {
+ "caption": 21,
+ "text": "Seventh, AI connects failed assertions",
+ "title": "07 / Investigate failures",
+ "nodes": [
+ "triage"
+ ],
+ "routes": [
+ "run:triage"
+ ]
+ },
+ {
+ "caption": 24,
+ "text": "Eighth, AI can propose a repair.",
+ "title": "08 / Repair and retest",
+ "nodes": [
+ "repair"
+ ],
+ "routes": [
+ "triage:repair"
+ ]
+ },
+ {
+ "caption": 27,
+ "text": "Ninth, AI assembles a linked release summary and suggests reviewed",
+ "title": "09 / Review release evidence",
+ "nodes": [
+ "evidence"
+ ],
+ "routes": [
+ "repair:evidence"
+ ]
+ }
+ ]
+ },
+ {
+ "diagram": "qe-journey",
+ "clip": "industry-technical/slide-36",
+ "cues": [
+ {
+ "caption": 0,
+ "text": "Trace one release through nine handoffs.",
+ "title": "01 / Understand the change",
+ "nodes": [
+ "intent"
+ ],
+ "routes": []
+ },
+ {
+ "caption": 7,
+ "text": "Next, test design produces a reviewed matrix.",
+ "title": "02 / Design test cases",
+ "nodes": [
+ "design"
+ ],
+ "routes": [
+ "intent:design"
+ ]
+ },
+ {
+ "caption": 12,
+ "text": "The developer unit-test step uses the handler source and accepted behavior.",
+ "title": "03 / Draft unit tests",
+ "nodes": [
+ "unit"
+ ],
+ "routes": [
+ "design:unit"
+ ]
+ },
+ {
+ "caption": 17,
+ "text": "The API and user-interface step turns the reviewed matrix into a pull request.",
+ "title": "04 / Build API / UI tests",
+ "nodes": [
+ "code"
+ ],
+ "routes": [
+ "unit:code"
+ ]
+ },
+ {
+ "caption": 23,
+ "text": "Data and provider behavior are versioned inputs.",
+ "title": "05 / Prepare data and stubs",
+ "nodes": [
+ "fixtures"
+ ],
+ "routes": [
+ "code:fixtures"
+ ]
+ },
+ {
+ "caption": 28,
+ "text": "For execution, AI may recommend affected tests or request an authorized",
+ "title": "06 / Select and run tests",
+ "nodes": [
+ "run"
+ ],
+ "routes": [
+ "fixtures:run"
+ ]
+ },
+ {
+ "caption": 33,
+ "text": "During investigation, AI reads retained evidence and proposes a cause.",
+ "title": "07 / Investigate failures",
+ "nodes": [
+ "triage"
+ ],
+ "routes": [
+ "run:triage"
+ ]
+ },
+ {
+ "caption": 38,
+ "text": "For repair, AI may propose a source change for developer review.",
+ "title": "08 / Repair and retest",
+ "nodes": [
+ "repair"
+ ],
+ "routes": [
+ "triage:repair"
+ ]
+ },
+ {
+ "caption": 43,
+ "text": "For release evidence, AI drafts a summary of coverage,",
+ "title": "09 / Review release evidence",
+ "nodes": [
+ "evidence"
+ ],
+ "routes": [
+ "repair:evidence"
+ ]
+ }
+ ]
}
]
}
diff --git a/assets/data/narration-guides.json b/assets/data/narration-guides.json
index eb686d9..ed2bc59 100644
--- a/assets/data/narration-guides.json
+++ b/assets/data/narration-guides.json
@@ -216,7 +216,7 @@
"selector": "figure.ft-before-after",
"deck": "evp",
"slide": "slide-6",
- "guide": "Compare the two lanes from left to right. Point out the new environment and evidence capabilities before discussing AI assistance."
+ "guide": "Compare manual QE, modernized QE and AI-assisted QE for the same payment scope. Separate repeatability and environment capacity from incremental AI drafting and investigation. Each state follows the spoken explanation."
},
{
"selector": "figure.ft-pilot-time",
@@ -411,6 +411,20 @@
"slide": "slide-4",
"guide": "Read the estimates with their confidence intervals and study populations. The overview explains why different task-level results cannot be pooled into a bank-wide saving.",
"baseline": true
+ },
+ {
+ "selector": "figure[data-diagram=\"qe-journey\"]",
+ "deck": "technical",
+ "slide": "slide-31",
+ "guide": "Follow nine caption-timed steps from approved intent through unit and API test candidates, fixtures, CI execution, diagnosis, repair and release evidence. AI outputs require review; the runner preserves its own verdict. The numbered path tells one proposed delivery story, not a mandatory order for every team.",
+ "format": "Full workflow walkthrough"
+ },
+ {
+ "selector": "figure[data-diagram=\"qe-artifact-trace\"]",
+ "deck": "technical",
+ "slide": "slide-32",
+ "guide": "Follow the same PAY-142 references through approved intent, rejected and repaired candidate assertions, injected-defect failure, reviewed diagnosis, fresh retest and release review. The original failure stays in the evidence pack.",
+ "format": "Artifact walkthrough"
}
],
"demo": {
diff --git a/assets/data/narration-scripts.json b/assets/data/narration-scripts.json
index 490ce02..8265f40 100644
--- a/assets/data/narration-scripts.json
+++ b/assets/data/narration-scripts.json
@@ -34,9 +34,9 @@
"speakText": "The platform investment makes useful capabilities available to every squad. Versioned context explains what should happen. Fixtures and controlled dependencies make tests repeatable. Existing frameworks and pipelines run approved changes, and an evidence service preserves the original results. AI helps prepare tests and interpret failures. Application teams still own payment behavior, code review and release decisions. The value comes from connecting these capabilities into the team's existing work."
},
"slide-6": {
- "title": "Before / after: the API testing workflow",
- "text": "Compare the two workflows. Today, engineers interpret requirements, prepare cases and data, wait for a shared environment, then collect evidence manually. The target adds approved context, repeatable execution and retained results. AI can propose a test or draft a diagnostic explanation at the appropriate stage. A human reviews the result before it progresses. This is a pilot target: foundation work, review effort and rework must be measured alongside any faster drafting.",
- "speakText": "Compare the two workflows. Today, engineers interpret requirements, prepare cases and data, wait for a shared environment, then collect evidence manually. The target adds approved context, repeatable execution and retained results. AI can propose a test or draft a diagnostic explanation at the appropriate stage. A human reviews the result before it progresses. This is a pilot target: foundation work, review effort and rework must be measured alongside any faster drafting."
+ "title": "Before / after: separate modernization from AI",
+ "text": "Start with today's manual workflow. People copy cases, prepare shared accounts, wait for a vendor test slot, and reconcile screenshots and logs. Seventy-five testers still face the same environment bottleneck.\n\nNow separate the modernization step. Engineers create reviewed automated tests, isolated data, and validated simulations of the payment provider. The delivery pipeline runs those tests and retains the evidence. That repeatability is valuable even without AI. Real-provider checks still need vendor capacity.\n\nThen add AI assistance. It helps draft cases, test code and fixtures, recommends relevant coverage, and helps explain failures and summarize proof. Engineers review the outputs, existing runners execute, and people make release decisions. Compare equivalent payment packs at all three stages. Measure waiting and reliability separately from AI drafting, review and rework. These are proposed states, not measured client improvements.",
+ "speakText": "Start with today's manual workflow. People copy cases, prepare shared accounts, wait for a vendor test slot, and reconcile screenshots and logs. Seventy-five testers still face the same environment bottleneck.\n\nNow separate the modernization step. Engineers create reviewed automated tests, isolated data, and validated simulations of the payment provider. The delivery pipeline runs those tests and retains the evidence. That repeatability is valuable even without AI. Real-provider checks still need vendor capacity.\n\nThen add AI assistance. It helps draft cases, test code and fixtures, recommends relevant coverage, and helps explain failures and summarize proof. Engineers review the outputs, existing runners execute, and people make release decisions. Compare equivalent payment packs at all three stages. Measure waiting and reliability separately from AI drafting, review and rework. These are proposed states, not measured client improvements."
},
"slide-7": {
"title": "Delivery maturity changes the first move",
@@ -102,6 +102,16 @@
"title": "Outcomes beyond hours",
"text": "Success needs evidence beyond hours saved. We propose three primary measures for the banking pilot.\n\nFirst, detect every approved critical payment fault that we deliberately introduce. Second, exercise every critical scenario with reviewed assertions and a valid result. Third, make each release decision traceable to its requirements, build, test data and raw results.\n\nThen check the foundation: can the team repeat runs reliably, validate agreed behaviors against the real provider, and help a second squad run independently?\n\nThese measures have no recorded baseline or after result yet. We will compare today's workflow, modernized quality engineering, and AI assistance on that foundation. Fewer escaped defects and emergency fixes are business aims to validate across releases. A complete evidence pack can still recommend stopping a release.",
"speakText": "Success needs evidence beyond hours saved. We propose three primary measures for the banking pilot.\n\nFirst, detect every approved critical payment fault that we deliberately introduce. Second, exercise every critical scenario with reviewed assertions and a valid result. Third, make each release decision traceable to its requirements, build, test data and raw results.\n\nThen check the foundation: can the team repeat runs reliably, validate agreed behaviors against the real provider, and help a second squad run independently?\n\nThese measures have no recorded baseline or after result yet. We will compare today's workflow, modernized quality engineering, and AI assistance on that foundation. Fewer escaped defects and emergency fixes are business aims to validate across releases. A complete evidence pack can still recommend stopping a release."
+ },
+ "slide-20": {
+ "title": "What AI contributes, from requirement to release",
+ "text": "Let's follow what AI contributes to one banking release. Our example is a payment that times out after acceptance. The customer retries, and the team must prove that the money moves once. First, AI helps clarify the requirement. The product owner confirms the expected behavior.\n\nSecond, AI drafts the test scenarios: normal payment, timeout, repeated callback, concurrent retry, and a conflicting request. Domain testers review the coverage and expected outcomes.\n\nThird, AI helps developers write unit tests for retry and duplicate-request logic. These are fast checks of code behavior; they do not replace payment integration tests.\n\nFourth, AI turns accepted cases into candidate API and user-interface tests. Reviewers require money-movement assertions, not just a successful response.\n\nFifth, AI helps draft synthetic data and provider simulations. Engineers validate them. Isolated environments and service virtualization make the work repeatable.\n\nSixth, AI recommends relevant tests or requests an authorized pipeline run. The delivery pipeline executes the tests. Mandatory payment coverage stays in place.\n\nSeventh, AI connects failed assertions with logs and traces, and drafts a diagnosis. The team checks the evidence before accepting the explanation.\n\nEighth, AI can propose a repair. A developer reviews the change, and the pipeline reruns the tests with fresh data. The expected payment behavior stays fixed.\n\nNinth, AI assembles a linked release summary and suggests reviewed failures for the regression suite. People decide whether the evidence is sufficient. That is the end-to-end opportunity: less repetitive preparation and investigation, supported by dependable execution and accountable review. This is a proposed workflow to validate in a pilot.",
+ "speakText": "Let's follow what AI contributes to one banking release. Our example is a payment that times out after acceptance. The customer retries, and the team must prove that the money moves once. First, AI helps clarify the requirement. The product owner confirms the expected behavior.\n\nSecond, AI drafts the test scenarios: normal payment, timeout, repeated callback, concurrent retry, and a conflicting request. Domain testers review the coverage and expected outcomes.\n\nThird, AI helps developers write unit tests for retry and duplicate-request logic. These are fast checks of code behavior; they do not replace payment integration tests.\n\nFourth, AI turns accepted cases into candidate API and user-interface tests. Reviewers require money-movement assertions, not just a successful response.\n\nFifth, AI helps draft synthetic data and provider simulations. Engineers validate them. Isolated environments and service virtualization make the work repeatable.\n\nSixth, AI recommends relevant tests or requests an authorized pipeline run. The delivery pipeline executes the tests. Mandatory payment coverage stays in place.\n\nSeventh, AI connects failed assertions with logs and traces, and drafts a diagnosis. The team checks the evidence before accepting the explanation.\n\nEighth, AI can propose a repair. A developer reviews the change, and the pipeline reruns the tests with fresh data. The expected payment behavior stays fixed.\n\nNinth, AI assembles a linked release summary and suggests reviewed failures for the regression suite. People decide whether the evidence is sufficient. That is the end-to-end opportunity: less repetitive preparation and investigation, supported by dependable execution and accountable review. This is a proposed workflow to validate in a pilot."
+ },
+ "slide-21": {
+ "title": "Follow one payment test through the handoffs",
+ "text": "Follow the same payment test through six handoffs. The approved requirement says a retry with the same key returns the original transfer and creates no second posting. The reviewed test matrix carries that intent forward.\n\nAI drafts a candidate test. A response-status check alone is too weak, so the reviewer requires the original transfer identifier, one journal, and independently agreed balances. That reviewed test becomes the change we can inspect.\n\nNow challenge the test with a deliberately faulty build. Our illustrative run finds two journals where one was expected. The test fails, and the original failure evidence is retained.\n\nAI links the failed assertion to the journal and trace evidence, and proposes a duplicate-posting diagnosis. An engineer confirms the cause and reviews the proposed fix.\n\nThe pipeline performs a fresh retest. The corrected build must pass, while the deliberately faulty variant must still fail. Changing the test simply to accept two debits would invalidate the result.\n\nFinally, the release pack links the requirement, reviewed test, failed run, fix and retest. The release owner checks remaining coverage and real-provider integration evidence. A passing retest is an input to that decision, not automatic approval. All identifiers and results here are authored examples.",
+ "speakText": "Follow the same payment test through six handoffs. The approved requirement says a retry with the same key returns the original transfer and creates no second posting. The reviewed test matrix carries that intent forward.\n\nAI drafts a candidate test. A response-status check alone is too weak, so the reviewer requires the original transfer identifier, one journal, and independently agreed balances. That reviewed test becomes the change we can inspect.\n\nNow challenge the test with a deliberately faulty build. Our illustrative run finds two journals where one was expected. The test fails, and the original failure evidence is retained.\n\nAI links the failed assertion to the journal and trace evidence, and proposes a duplicate-posting diagnosis. An engineer confirms the cause and reviews the proposed fix.\n\nThe pipeline performs a fresh retest. The corrected build must pass, while the deliberately faulty variant must still fail. Changing the test simply to accept two debits would invalidate the result.\n\nFinally, the release pack links the requirement, reviewed test, failed run, fix and retest. The release owner checks remaining coverage and real-provider integration evidence. A passing retest is an input to that decision, not automatic approval. All identifiers and results here are authored examples."
}
},
"technical": {
@@ -147,8 +157,8 @@
},
"slide-9": {
"title": "The appropriate test layer",
- "text": "Choose the test layer that exposes the behavior. Service tests can check idempotency, concurrency and journal outcomes directly. A browser journey checks pending states, the retry action and the final message. Existing Selenium and Appium suites remain where they are owned and useful. Settlement reconciliation and provider checks stay scheduled separately. Replacing the browser framework does not create another settlement environment or remove a vendor access constraint.",
- "speakText": "Choose the test layer that exposes the behavior. Service tests can check idempotency, concurrency and journal outcomes directly. A browser journey checks pending states, the retry action and the final message. Existing Selenium and Appium suites remain where they are owned and useful. Settlement reconciliation and provider checks stay scheduled separately. Replacing the browser framework does not create another settlement environment or remove a vendor access constraint."
+ "text": "Choose the test layer for the behavior you need to prove. Start with developer unit tests for idempotency-key validation and duplicate-request logic. Copilot can draft JUnit candidates, but developers review the assertions and test doubles. A fake repository cannot establish real payment integration. At the service and API layer, REST Assured and JUnit cover retry, concurrency, conflicts and journal outcomes. At the web layer, Playwright checks the pending state, retry action and final customer message. Keep the owned Selenium and Appium coverage for existing browser and mobile journeys. Batch settlement reconciliation and real-provider sandbox checks remain separate requirements. Generate tests within the appropriate layer; adding a browser framework does not resolve a scarce settlement environment.",
+ "speakText": "Choose the test layer for the behavior you need to prove. Start with developer unit tests for idempotency-key validation and duplicate-request logic. Copilot can draft JUnit candidates, but developers review the assertions and test doubles. A fake repository cannot establish real payment integration. At the service and API layer, REST Assured and JUnit cover retry, concurrency, conflicts and journal outcomes. At the web layer, Playwright checks the pending state, retry action and final customer message. Keep the owned Selenium and Appium coverage for existing browser and mobile journeys. Batch settlement reconciliation and real-provider sandbox checks remain separate requirements. Generate tests within the appropriate layer; adding a browser framework does not resolve a scarce settlement environment."
},
"slide-10": {
"title": "Publish raw CI results before AI interpretation",
@@ -254,6 +264,21 @@
"title": "Prove reliability, integration and reuse",
"text": "The last checks are reliability, integration and reuse. Repeat unchanged configurations and report unstable results without erasing the original failure. Verify agreed behavior against the real provider and report simulated outcomes separately. Ask a second squad to configure, run and evidence the assigned journeys independently, recording help from the pilot authors. Freeze definitions before comparing results. These checks show whether the capability is dependable enough to extend beyond its first team.",
"speakText": "The last checks are reliability, integration and reuse. Repeat unchanged configurations and report unstable results without erasing the original failure. Verify agreed behavior against the real provider and report simulated outcomes separately. Ask a second squad to configure, run and evidence the assigned journeys independently, recording help from the pilot authors. Freeze definitions before comparing results. These checks show whether the capability is dependable enough to extend beyond its first team."
+ },
+ "slide-31": {
+ "title": "Nine AI-assisted steps, with explicit handoffs",
+ "text": "Trace one release through nine handoffs. This is AI assistance to an existing payments testing team, distinct from evaluating an AI application. Start with approved context: the payment story, API contract and relevant defects. AI drafts clarification questions. Product and domain QA approve the rule that a same-key, same-payload retry returns the original transfer without a second posting.\n\nNext, test design produces a reviewed matrix. AI proposes timeout, duplicate callback, concurrency and conflicting-payload cases. Domain QA supplies the expected behavior independently of the implementation. A written case is an input to executable test code, not the code itself.\n\nThe developer unit-test step uses the handler source and accepted behavior. Copilot can draft JUnit candidates for key validation and duplicate-request logic. The developer checks the fake repository and verifies one insertion for repeated calls. A passing unit test does not establish correctness across the real database and provider.\n\nThe API and user-interface step turns the reviewed matrix into a pull request. REST Assured tests exercise the payment service; selected Playwright checks cover the customer's pending state and retry action. Reviewers require the original transfer identifier, one journal, and balances of ninety thousand and ten thousand minor units. A status-only assertion is rejected.\n\nData and provider behavior are versioned inputs. AI can draft synthetic seed scripts and WireMock mappings for acceptance followed by a timeout. Engineers validate those mappings against the provider contract. Testcontainers and the delivery pipeline supply repeatable resources. Real-provider and settlement checks remain separate requirements.\n\nFor execution, AI may recommend affected tests or request an authorized pipeline job. Azure Pipelines runs the approved suite and publishes raw JUnit results and traces. The mandatory payment suite cannot be silently omitted. Record the build, test commit, fixture and stub versions under the run identifier.\n\nDuring investigation, AI reads retained evidence and proposes a cause. In our injected-defect example, the assertion expects one journal but observes two. The defect draft must link that evidence. A reviewer confirms the diagnosis, and the original failing verdict remains unchanged.\n\nFor repair, AI may propose a source change for developer review. Keep the accepted payment assertions fixed. The pipeline uses a fresh run identifier and isolated data for the retest. The corrected build must pass, and the deliberate duplicate-posting variant must still fail.\n\nFor release evidence, AI drafts a summary of coverage, run results, reviewed dispositions and missing checks. The release owner reviews the linked pack, including required real-provider evidence. Accepted defects can become reviewed regression cases. The shared platform provides context access, artifact versions, scoped pipeline access and evidence retention across these steps; it does not replace the named owners.",
+ "speakText": "Trace one release through nine handoffs. This is AI assistance to an existing payments testing team, distinct from evaluating an AI application. Start with approved context: the payment story, API contract and relevant defects. AI drafts clarification questions. Product and domain QA approve the rule that a same-key, same-payload retry returns the original transfer without a second posting.\n\nNext, test design produces a reviewed matrix. AI proposes timeout, duplicate callback, concurrency and conflicting-payload cases. Domain QA supplies the expected behavior independently of the implementation. A written case is an input to executable test code, not the code itself.\n\nThe developer unit-test step uses the handler source and accepted behavior. Copilot can draft JUnit candidates for key validation and duplicate-request logic. The developer checks the fake repository and verifies one insertion for repeated calls. A passing unit test does not establish correctness across the real database and provider.\n\nThe API and user-interface step turns the reviewed matrix into a pull request. REST Assured tests exercise the payment service; selected Playwright checks cover the customer's pending state and retry action. Reviewers require the original transfer identifier, one journal, and balances of ninety thousand and ten thousand minor units. A status-only assertion is rejected.\n\nData and provider behavior are versioned inputs. AI can draft synthetic seed scripts and WireMock mappings for acceptance followed by a timeout. Engineers validate those mappings against the provider contract. Testcontainers and the delivery pipeline supply repeatable resources. Real-provider and settlement checks remain separate requirements.\n\nFor execution, AI may recommend affected tests or request an authorized pipeline job. Azure Pipelines runs the approved suite and publishes raw JUnit results and traces. The mandatory payment suite cannot be silently omitted. Record the build, test commit, fixture and stub versions under the run identifier.\n\nDuring investigation, AI reads retained evidence and proposes a cause. In our injected-defect example, the assertion expects one journal but observes two. The defect draft must link that evidence. A reviewer confirms the diagnosis, and the original failing verdict remains unchanged.\n\nFor repair, AI may propose a source change for developer review. Keep the accepted payment assertions fixed. The pipeline uses a fresh run identifier and isolated data for the retest. The corrected build must pass, and the deliberate duplicate-posting variant must still fail.\n\nFor release evidence, AI drafts a summary of coverage, run results, reviewed dispositions and missing checks. The release owner reviews the linked pack, including required real-provider evidence. Accepted defects can become reviewed regression cases. The shared platform provides context access, artifact versions, scoped pipeline access and evidence retention across these steps; it does not replace the named owners."
+ },
+ "slide-32": {
+ "title": "PAY-142: requirement, test, failure, fix and proof",
+ "text": "Begin with the approved requirement and its test-case reference. The same idempotency key and payload must return the original transfer. The test matrix carries that criterion into the unit and API layers. The identifiers in this diagram are authored trace examples.\n\nThe AI candidate becomes a reviewed pull request. The unit test checks one insertion through a fake repository. The API test independently checks the original transfer ID, one balanced journal, payer balance ninety thousand, and recipient balance ten thousand minor units. A response-status check alone is rejected.\n\nThe first run pins the fixture and provider-model revisions. Execute the deliberate duplicate-posting variant: one journal is expected, but two are observed. JUnit reports a failure. Retain the assertion, trace and journal identifiers before cleanup. This is a designed challenge, not a reported banking incident.\n\nThe defect record links that failed run. AI proposes duplicate posting as a hypothesis, with evidence references. An engineer confirms the cause and reviews a production-code repair. Neither the AI summary nor the repair process may turn the original failed run into a pass.\n\nA fresh retest uses a new run identifier and unchanged payment expectations. The corrected build should pass, while the deliberately faulty variant must still fail. Link the source change and both results so the reviewer can inspect the difference.\n\nThe release pack includes the approved requirement, test commit, fixture and stub revisions, failed run, reviewed defect, repair and retest. Check required coverage and real-provider evidence before deciding. If integration proof is absent, the pack records that gap; the diagram does not grant release approval.",
+ "speakText": "Begin with the approved requirement and its test-case reference. The same idempotency key and payload must return the original transfer. The test matrix carries that criterion into the unit and API layers. The identifiers in this diagram are authored trace examples.\n\nThe AI candidate becomes a reviewed pull request. The unit test checks one insertion through a fake repository. The API test independently checks the original transfer ID, one balanced journal, payer balance ninety thousand, and recipient balance ten thousand minor units. A response-status check alone is rejected.\n\nThe first run pins the fixture and provider-model revisions. Execute the deliberate duplicate-posting variant: one journal is expected, but two are observed. JUnit reports a failure. Retain the assertion, trace and journal identifiers before cleanup. This is a designed challenge, not a reported banking incident.\n\nThe defect record links that failed run. AI proposes duplicate posting as a hypothesis, with evidence references. An engineer confirms the cause and reviews a production-code repair. Neither the AI summary nor the repair process may turn the original failed run into a pass.\n\nA fresh retest uses a new run identifier and unchanged payment expectations. The corrected build should pass, while the deliberately faulty variant must still fail. Link the source change and both results so the reviewer can inspect the difference.\n\nThe release pack includes the approved requirement, test commit, fixture and stub revisions, failed run, reviewed defect, repair and retest. Check required coverage and real-provider evidence before deciding. If integration proof is absent, the pack records that gap; the diagram does not grant release approval."
+ },
+ "slide-33": {
+ "title": "Three states: isolate the incremental AI contribution",
+ "text": "The starting state has manual API requests and spreadsheets, shared environments, and no virtualized provider backend. QA engineers collect and reconcile evidence. Vendor test-slot availability constrains parallel execution.\n\nThe modernized state introduces reviewed REST Assured and JUnit tests, delivery-pipeline execution, isolated fixtures and a validated WireMock provider model. Testcontainers supports repeatable service-test resources. Raw assertions, traces and run identifiers survive cleanup. This foundation creates repeatability without depending on AI.\n\nThe AI-assisted state adds approved context, candidate artifacts and evidence-based assistance around that same execution path. AI drafts tests and fixtures, proposes relevant scope and diagnoses failures. Reviewers approve changes before existing runners execute them. Compare equivalent payment packs to distinguish modernization gains from incremental AI benefit. Include review, correction, platform overhead and real-provider checks. No measured improvement is claimed in this scenario.",
+ "speakText": "The starting state has manual API requests and spreadsheets, shared environments, and no virtualized provider backend. QA engineers collect and reconcile evidence. Vendor test-slot availability constrains parallel execution.\n\nThe modernized state introduces reviewed REST Assured and JUnit tests, delivery-pipeline execution, isolated fixtures and a validated WireMock provider model. Testcontainers supports repeatable service-test resources. Raw assertions, traces and run identifiers survive cleanup. This foundation creates repeatability without depending on AI.\n\nThe AI-assisted state adds approved context, candidate artifacts and evidence-based assistance around that same execution path. AI drafts tests and fixtures, proposes relevant scope and diagnoses failures. Reviewers approve changes before existing runners execute them. Compare equivalent payment packs to distinguish modernization gains from incremental AI benefit. Include review, correction, platform overhead and real-provider checks. No measured improvement is claimed in this scenario."
}
},
"industry-evp": {
@@ -381,13 +406,18 @@
"title": "A focused first engagement",
"text": "Choose one focused entry point. Requirements-ready teams can trial reviewed scenario design. Teams with repeatable execution can test generated API candidates. Teams with useful diagnostics can assess evidence-linked failure triage. Define the output, reviewer and acceptance evidence before starting. Build reusable assets as the work progresses. The result should support a specific next adoption decision, with quality, effort and prerequisites visible together.",
"speakText": "Choose one focused entry point. Requirements-ready teams can trial reviewed scenario design. Teams with repeatable execution can test generated API candidates. Teams with useful diagnostics can assess evidence-linked failure triage. Define the output, reviewer and acceptance evidence before starting. Build reusable assets as the work progresses. The result should support a specific next adoption decision, with quality, effort and prerequisites visible together."
+ },
+ "slide-26": {
+ "title": "What AI contributes, from requirement to release",
+ "text": "Let's follow what AI contributes to one banking release. Our example is a payment that times out after acceptance. The customer retries, and the team must prove that the money moves once. First, AI helps clarify the requirement. The product owner confirms the expected behavior.\n\nSecond, AI drafts the test scenarios: normal payment, timeout, repeated callback, concurrent retry, and a conflicting request. Domain testers review the coverage and expected outcomes.\n\nThird, AI helps developers write unit tests for retry and duplicate-request logic. These are fast checks of code behavior; they do not replace payment integration tests.\n\nFourth, AI turns accepted cases into candidate API and user-interface tests. Reviewers require money-movement assertions, not just a successful response.\n\nFifth, AI helps draft synthetic data and provider simulations. Engineers validate them. Isolated environments and service virtualization make the work repeatable.\n\nSixth, AI recommends relevant tests or requests an authorized pipeline run. The delivery pipeline executes the tests. Mandatory payment coverage stays in place.\n\nSeventh, AI connects failed assertions with logs and traces, and drafts a diagnosis. The team checks the evidence before accepting the explanation.\n\nEighth, AI can propose a repair. A developer reviews the change, and the pipeline reruns the tests with fresh data. The expected payment behavior stays fixed.\n\nNinth, AI assembles a linked release summary and suggests reviewed failures for the regression suite. People decide whether the evidence is sufficient. That is the end-to-end opportunity: less repetitive preparation and investigation, supported by dependable execution and accountable review. This is a proposed workflow to validate in a pilot.",
+ "speakText": "Let's follow what AI contributes to one banking release. Our example is a payment that times out after acceptance. The customer retries, and the team must prove that the money moves once. First, AI helps clarify the requirement. The product owner confirms the expected behavior.\n\nSecond, AI drafts the test scenarios: normal payment, timeout, repeated callback, concurrent retry, and a conflicting request. Domain testers review the coverage and expected outcomes.\n\nThird, AI helps developers write unit tests for retry and duplicate-request logic. These are fast checks of code behavior; they do not replace payment integration tests.\n\nFourth, AI turns accepted cases into candidate API and user-interface tests. Reviewers require money-movement assertions, not just a successful response.\n\nFifth, AI helps draft synthetic data and provider simulations. Engineers validate them. Isolated environments and service virtualization make the work repeatable.\n\nSixth, AI recommends relevant tests or requests an authorized pipeline run. The delivery pipeline executes the tests. Mandatory payment coverage stays in place.\n\nSeventh, AI connects failed assertions with logs and traces, and drafts a diagnosis. The team checks the evidence before accepting the explanation.\n\nEighth, AI can propose a repair. A developer reviews the change, and the pipeline reruns the tests with fresh data. The expected payment behavior stays fixed.\n\nNinth, AI assembles a linked release summary and suggests reviewed failures for the regression suite. People decide whether the evidence is sufficient. That is the end-to-end opportunity: less repetitive preparation and investigation, supported by dependable execution and accountable review. This is a proposed workflow to validate in a pilot."
}
},
"industry-technical": {
"slide-1": {
"title": "Assurance across the AI lifecycle",
- "text": "This presentation examines the system behind AI-enabled quality work. We will connect context, independent evaluation, action boundaries, release decisions and operational feedback. The architecture covers both AI-assisted engineering and assurance of AI applications. Every important boundary needs an owner, a versioned contract and a failure behavior. The banking engineering blueprint provides the more detailed payment implementation example; this deck develops the reusable assurance architecture.",
- "speakText": "This presentation examines the system behind AI-enabled quality work. We will connect context, independent evaluation, action boundaries, release decisions and operational feedback. The architecture covers both AI-assisted engineering and assurance of AI applications. Every important boundary needs an owner, a versioned contract and a failure behavior. The banking engineering blueprint provides the more detailed payment implementation example; this deck develops the reusable assurance architecture."
+ "text": "This industry briefing explains assurance across the AI lifecycle: context, generated tests, independent evaluation, action controls and release evidence. It includes testing AI applications as well as using AI in quality engineering. If your immediate question is how AI helps an existing banking QA team, follow the banking workflow link on this slide. That engineering walkthrough traces one payment requirement through unit tests, API tests, fixtures, execution, diagnosis, repair and release evidence. The final slide here also provides that nine-step overview. Choose the banking route for concrete delivery handoffs, and this industry route for the wider assurance architecture.",
+ "speakText": "This industry briefing explains assurance across the AI lifecycle: context, generated tests, independent evaluation, action controls and release evidence. It includes testing AI applications as well as using AI in quality engineering. If your immediate question is how AI helps an existing banking QA team, follow the banking workflow link on this slide. That engineering walkthrough traces one payment requirement through unit tests, API tests, fixtures, execution, diagnosis, repair and release evidence. The final slide here also provides that nine-step overview. Choose the banking route for concrete delivery handoffs, and this industry route for the wider assurance architecture."
},
"slide-2": {
"title": "The enterprise assurance platform",
@@ -558,6 +588,11 @@
"title": "Measuring the incremental AI effect",
"text": "Measure the incremental AI effect under shared conditions. Conventional and assisted work should use comparable tasks, frameworks, environments and acceptance rules. Reviewers inspect both, and independent tests challenge the behavior. Record every attempt, including correction, unsuccessful proposals and operating costs. First separate modernization improvements from the additional effect of AI. The decision to expand should follow accepted outcomes and complete effort, with uncertainty visible.",
"speakText": "Measure the incremental AI effect under shared conditions. Conventional and assisted work should use comparable tasks, frameworks, environments and acceptance rules. Reviewers inspect both, and independent tests challenge the behavior. Record every attempt, including correction, unsuccessful proposals and operating costs. First separate modernization improvements from the additional effect of AI. The decision to expand should follow accepted outcomes and complete effort, with uncertainty visible."
+ },
+ "slide-36": {
+ "title": "Nine AI-assisted steps, with explicit handoffs",
+ "text": "Trace one release through nine handoffs. This is AI assistance to an existing payments testing team, distinct from evaluating an AI application. Start with approved context: the payment story, API contract and relevant defects. AI drafts clarification questions. Product and domain QA approve the rule that a same-key, same-payload retry returns the original transfer without a second posting.\n\nNext, test design produces a reviewed matrix. AI proposes timeout, duplicate callback, concurrency and conflicting-payload cases. Domain QA supplies the expected behavior independently of the implementation. A written case is an input to executable test code, not the code itself.\n\nThe developer unit-test step uses the handler source and accepted behavior. Copilot can draft JUnit candidates for key validation and duplicate-request logic. The developer checks the fake repository and verifies one insertion for repeated calls. A passing unit test does not establish correctness across the real database and provider.\n\nThe API and user-interface step turns the reviewed matrix into a pull request. REST Assured tests exercise the payment service; selected Playwright checks cover the customer's pending state and retry action. Reviewers require the original transfer identifier, one journal, and balances of ninety thousand and ten thousand minor units. A status-only assertion is rejected.\n\nData and provider behavior are versioned inputs. AI can draft synthetic seed scripts and WireMock mappings for acceptance followed by a timeout. Engineers validate those mappings against the provider contract. Testcontainers and the delivery pipeline supply repeatable resources. Real-provider and settlement checks remain separate requirements.\n\nFor execution, AI may recommend affected tests or request an authorized pipeline job. Azure Pipelines runs the approved suite and publishes raw JUnit results and traces. The mandatory payment suite cannot be silently omitted. Record the build, test commit, fixture and stub versions under the run identifier.\n\nDuring investigation, AI reads retained evidence and proposes a cause. In our injected-defect example, the assertion expects one journal but observes two. The defect draft must link that evidence. A reviewer confirms the diagnosis, and the original failing verdict remains unchanged.\n\nFor repair, AI may propose a source change for developer review. Keep the accepted payment assertions fixed. The pipeline uses a fresh run identifier and isolated data for the retest. The corrected build must pass, and the deliberate duplicate-posting variant must still fail.\n\nFor release evidence, AI drafts a summary of coverage, run results, reviewed dispositions and missing checks. The release owner reviews the linked pack, including required real-provider evidence. Accepted defects can become reviewed regression cases. The shared platform provides context access, artifact versions, scoped pipeline access and evidence retention across these steps; it does not replace the named owners.",
+ "speakText": "Trace one release through nine handoffs. This is AI assistance to an existing payments testing team, distinct from evaluating an AI application. Start with approved context: the payment story, API contract and relevant defects. AI drafts clarification questions. Product and domain QA approve the rule that a same-key, same-payload retry returns the original transfer without a second posting.\n\nNext, test design produces a reviewed matrix. AI proposes timeout, duplicate callback, concurrency and conflicting-payload cases. Domain QA supplies the expected behavior independently of the implementation. A written case is an input to executable test code, not the code itself.\n\nThe developer unit-test step uses the handler source and accepted behavior. Copilot can draft JUnit candidates for key validation and duplicate-request logic. The developer checks the fake repository and verifies one insertion for repeated calls. A passing unit test does not establish correctness across the real database and provider.\n\nThe API and user-interface step turns the reviewed matrix into a pull request. REST Assured tests exercise the payment service; selected Playwright checks cover the customer's pending state and retry action. Reviewers require the original transfer identifier, one journal, and balances of ninety thousand and ten thousand minor units. A status-only assertion is rejected.\n\nData and provider behavior are versioned inputs. AI can draft synthetic seed scripts and WireMock mappings for acceptance followed by a timeout. Engineers validate those mappings against the provider contract. Testcontainers and the delivery pipeline supply repeatable resources. Real-provider and settlement checks remain separate requirements.\n\nFor execution, AI may recommend affected tests or request an authorized pipeline job. Azure Pipelines runs the approved suite and publishes raw JUnit results and traces. The mandatory payment suite cannot be silently omitted. Record the build, test commit, fixture and stub versions under the run identifier.\n\nDuring investigation, AI reads retained evidence and proposes a cause. In our injected-defect example, the assertion expects one journal but observes two. The defect draft must link that evidence. A reviewer confirms the diagnosis, and the original failing verdict remains unchanged.\n\nFor repair, AI may propose a source change for developer review. Keep the accepted payment assertions fixed. The pipeline uses a fresh run identifier and isolated data for the retest. The corrected build must pass, and the deliberate duplicate-posting variant must still fail.\n\nFor release evidence, AI drafts a summary of coverage, run results, reviewed dispositions and missing checks. The release owner reviews the linked pack, including required real-provider evidence. Accepted defects can become reviewed regression cases. The shared platform provides context access, artifact versions, scoped pipeline access and evidence retention across these steps; it does not replace the named owners."
}
}
}
diff --git a/assets/data/narration.json b/assets/data/narration.json
index e405ba1..d345c48 100644
--- a/assets/data/narration.json
+++ b/assets/data/narration.json
@@ -1,5 +1,5 @@
{
- "edition": "architecture-v1.21.0",
+ "edition": "banking-journey-v1.22.0",
"decks": {
"evp": {
"label": "Banking executive narration",
@@ -50,13 +50,13 @@
"sha256": "9e54de8c1559e4fe9e51b79d594bb443d12fdd537f6fcf98e630461a4c6419ae"
},
"slide-6": {
- "audio": "/assets/audio/chris-v1.17.0/evp/slide-6.mp3",
- "captions": "/assets/audio/chris-v1.17.0/evp/slide-6.vtt",
- "transcript": "Compare the two workflows. Today, engineers interpret requirements, prepare cases and data, wait for a shared environment, then collect evidence manually. The target adds approved context, repeatable execution and retained results. AI can propose a test or draft a diagnostic explanation at the appropriate stage. A human reviews the result before it progresses. This is a pilot target: foundation work, review effort and rework must be measured alongside any faster drafting.",
+ "audio": "/assets/audio/banking-journey-v1.22.0/evp/slide-6.mp3",
+ "captions": "/assets/audio/banking-journey-v1.22.0/evp/slide-6.vtt",
+ "transcript": "Start with today's manual workflow. People copy cases, prepare shared accounts, wait for a vendor test slot, and reconcile screenshots and logs. Seventy-five testers still face the same environment bottleneck. Now separate the modernization step. Engineers create reviewed automated tests, isolated data, and validated simulations of the payment provider. The delivery pipeline runs those tests and retains the evidence. That repeatability is valuable even without AI. Real-provider checks still need vendor capacity. Then add AI assistance. It helps draft cases, test code and fixtures, recommends relevant coverage, and helps explain failures and summarize proof. Engineers review the outputs, existing runners execute, and people make release decisions. Compare equivalent payment packs at all three stages. Measure waiting and reliability separately from AI drafting, review and rework. These are proposed states, not measured client improvements.",
"voice": "ElevenLabs / Chris — Charming, Down-to-Earth",
- "caption_method": "ElevenLabs character alignment, restored display terminology",
- "duration": 30.32,
- "sha256": "fd637dc8c0b9c6ebaef59881ed029c25c8143c569e500a72400a9de4a011ba15"
+ "caption_method": "ElevenLabs character alignment; authored section boundaries",
+ "duration": 63.44,
+ "sha256": "c2fdf6329c6d32a30f1fe94f872a3c874b3107cc8975cfe861c7ae2d8f446340"
},
"slide-7": {
"audio": "/assets/audio/chris-v1.17.0/evp/slide-7.mp3",
@@ -174,6 +174,24 @@
"caption_method": "ElevenLabs character alignment, restored display terminology",
"duration": 53.36,
"sha256": "3576429426c5f2d1f6feb7039fd0da48768aefc7dce819ce638fee66c4268af9"
+ },
+ "slide-20": {
+ "audio": "/assets/audio/banking-journey-v1.22.0/evp/slide-20.mp3",
+ "captions": "/assets/audio/banking-journey-v1.22.0/evp/slide-20.vtt",
+ "transcript": "Let's follow what AI contributes to one banking release. Our example is a payment that times out after acceptance. The customer retries, and the team must prove that the money moves once. First, AI helps clarify the requirement. The product owner confirms the expected behavior. Second, AI drafts the test scenarios: normal payment, timeout, repeated callback, concurrent retry, and a conflicting request. Domain testers review the coverage and expected outcomes. Third, AI helps developers write unit tests for retry and duplicate-request logic. These are fast checks of code behavior; they do not replace payment integration tests. Fourth, AI turns accepted cases into candidate API and user-interface tests. Reviewers require money-movement assertions, not just a successful response. Fifth, AI helps draft synthetic data and provider simulations. Engineers validate them. Isolated environments and service virtualization make the work repeatable. Sixth, AI recommends relevant tests or requests an authorized pipeline run. The delivery pipeline executes the tests. Mandatory payment coverage stays in place. Seventh, AI connects failed assertions with logs and traces, and drafts a diagnosis. The team checks the evidence before accepting the explanation. Eighth, AI can propose a repair. A developer reviews the change, and the pipeline reruns the tests with fresh data. The expected payment behavior stays fixed. Ninth, AI assembles a linked release summary and suggests reviewed failures for the regression suite. People decide whether the evidence is sufficient. That is the end-to-end opportunity: less repetitive preparation and investigation, supported by dependable execution and accountable review. This is a proposed workflow to validate in a pilot.",
+ "voice": "ElevenLabs / Chris — Charming, Down-to-Earth",
+ "caption_method": "ElevenLabs character alignment; authored section boundaries",
+ "duration": 122.24,
+ "sha256": "51bff8a242e0c0f414284bfffc7a6c2d1e38d21a8f2955a1a786f99486bc15eb"
+ },
+ "slide-21": {
+ "audio": "/assets/audio/banking-journey-v1.22.0/evp/slide-21.mp3",
+ "captions": "/assets/audio/banking-journey-v1.22.0/evp/slide-21.vtt",
+ "transcript": "Follow the same payment test through six handoffs. The approved requirement says a retry with the same key returns the original transfer and creates no second posting. The reviewed test matrix carries that intent forward. AI drafts a candidate test. A response-status check alone is too weak, so the reviewer requires the original transfer identifier, one journal, and independently agreed balances. That reviewed test becomes the change we can inspect. Now challenge the test with a deliberately faulty build. Our illustrative run finds two journals where one was expected. The test fails, and the original failure evidence is retained. AI links the failed assertion to the journal and trace evidence, and proposes a duplicate-posting diagnosis. An engineer confirms the cause and reviews the proposed fix. The pipeline performs a fresh retest. The corrected build must pass, while the deliberately faulty variant must still fail. Changing the test simply to accept two debits would invalidate the result. Finally, the release pack links the requirement, reviewed test, failed run, fix and retest. The release owner checks remaining coverage and real-provider integration evidence. A passing retest is an input to that decision, not automatic approval. All identifiers and results here are authored examples.",
+ "voice": "ElevenLabs / Chris — Charming, Down-to-Earth",
+ "caption_method": "ElevenLabs character alignment; authored section boundaries",
+ "duration": 84.08,
+ "sha256": "14277c21eaeea153f4ae57944c636c48e2cb8df3d77e2ef7cdf4d3ac3c170aa0"
}
},
"duration": 611.2
@@ -254,13 +272,13 @@
"sha256": "635841d9d05ce4854030647f82afa13b459dda783fb3b5df5faf836234efa37a"
},
"slide-9": {
- "audio": "/assets/audio/chris-v1.17.0/technical/slide-9.mp3",
- "captions": "/assets/audio/chris-v1.17.0/technical/slide-9.vtt",
- "transcript": "Choose the test layer that exposes the behavior. Service tests can check idempotency, concurrency and journal outcomes directly. A browser journey checks pending states, the retry action and the final message. Existing Selenium and Appium suites remain where they are owned and useful. Settlement reconciliation and provider checks stay scheduled separately. Replacing the browser framework does not create another settlement environment or remove a vendor access constraint.",
+ "audio": "/assets/audio/banking-journey-v1.22.0/technical/slide-9.mp3",
+ "captions": "/assets/audio/banking-journey-v1.22.0/technical/slide-9.vtt",
+ "transcript": "Choose the test layer for the behavior you need to prove. Start with developer unit tests for idempotency-key validation and duplicate-request logic. Copilot can draft JUnit candidates, but developers review the assertions and test doubles. A fake repository cannot establish real payment integration. At the service and API layer, REST Assured and JUnit cover retry, concurrency, conflicts and journal outcomes. At the web layer, Playwright checks the pending state, retry action and final customer message. Keep the owned Selenium and Appium coverage for existing browser and mobile journeys. Batch settlement reconciliation and real-provider sandbox checks remain separate requirements. Generate tests within the appropriate layer; adding a browser framework does not resolve a scarce settlement environment.",
"voice": "ElevenLabs / Chris — Charming, Down-to-Earth",
- "caption_method": "ElevenLabs character alignment, restored display terminology",
- "duration": 29.2,
- "sha256": "24364558187c1e123c954c745ad4da2c1c50b9004553db7da0465d5fca608164"
+ "caption_method": "ElevenLabs character alignment; authored section boundaries",
+ "duration": 51.92,
+ "sha256": "f2bc620e93e33f193e37f89a6344ac09e9acf2facc196a6b52a0b968e4f9504a"
},
"slide-10": {
"audio": "/assets/audio/chris-v1.17.0/technical/slide-10.mp3",
@@ -450,6 +468,33 @@
"caption_method": "ElevenLabs character alignment, restored display terminology",
"duration": 32.08,
"sha256": "79e3a65a90f2083276c7c22a425af11808d1cacde8712331642f9d468b6c398e"
+ },
+ "slide-31": {
+ "audio": "/assets/audio/banking-journey-v1.22.0/technical/slide-31.mp3",
+ "captions": "/assets/audio/banking-journey-v1.22.0/technical/slide-31.vtt",
+ "transcript": "Trace one release through nine handoffs. This is AI assistance to an existing payments testing team, distinct from evaluating an AI application. Start with approved context: the payment story, API contract and relevant defects. AI drafts clarification questions. Product and domain QA approve the rule that a same-key, same-payload retry returns the original transfer without a second posting. Next, test design produces a reviewed matrix. AI proposes timeout, duplicate callback, concurrency and conflicting-payload cases. Domain QA supplies the expected behavior independently of the implementation. A written case is an input to executable test code, not the code itself. The developer unit-test step uses the handler source and accepted behavior. Copilot can draft JUnit candidates for key validation and duplicate-request logic. The developer checks the fake repository and verifies one insertion for repeated calls. A passing unit test does not establish correctness across the real database and provider. The API and user-interface step turns the reviewed matrix into a pull request. REST Assured tests exercise the payment service; selected Playwright checks cover the customer's pending state and retry action. Reviewers require the original transfer identifier, one journal, and balances of ninety thousand and ten thousand minor units. A status-only assertion is rejected. Data and provider behavior are versioned inputs. AI can draft synthetic seed scripts and WireMock mappings for acceptance followed by a timeout. Engineers validate those mappings against the provider contract. Testcontainers and the delivery pipeline supply repeatable resources. Real-provider and settlement checks remain separate requirements. For execution, AI may recommend affected tests or request an authorized pipeline job. Azure Pipelines runs the approved suite and publishes raw JUnit results and traces. The mandatory payment suite cannot be silently omitted. Record the build, test commit, fixture and stub versions under the run identifier. During investigation, AI reads retained evidence and proposes a cause. In our injected-defect example, the assertion expects one journal but observes two. The defect draft must link that evidence. A reviewer confirms the diagnosis, and the original failing verdict remains unchanged. For repair, AI may propose a source change for developer review. Keep the accepted payment assertions fixed. The pipeline uses a fresh run identifier and isolated data for the retest. The corrected build must pass, and the deliberate duplicate-posting variant must still fail. For release evidence, AI drafts a summary of coverage, run results, reviewed dispositions and missing checks. The release owner reviews the linked pack, including required real-provider evidence. Accepted defects can become reviewed regression cases. The shared platform provides context access, artifact versions, scoped pipeline access and evidence retention across these steps; it does not replace the named owners.",
+ "voice": "ElevenLabs / Chris — Charming, Down-to-Earth",
+ "caption_method": "ElevenLabs character alignment; authored section boundaries",
+ "duration": 199.04,
+ "sha256": "a3d24c7646517acd5344a359b294ccb308401b793e8b7edd20d3abb158fbe095"
+ },
+ "slide-32": {
+ "audio": "/assets/audio/banking-journey-v1.22.0/technical/slide-32.mp3",
+ "captions": "/assets/audio/banking-journey-v1.22.0/technical/slide-32.vtt",
+ "transcript": "Begin with the approved requirement and its test-case reference. The same idempotency key and payload must return the original transfer. The test matrix carries that criterion into the unit and API layers. The identifiers in this diagram are authored trace examples. The AI candidate becomes a reviewed pull request. The unit test checks one insertion through a fake repository. The API test independently checks the original transfer ID, one balanced journal, payer balance ninety thousand, and recipient balance ten thousand minor units. A response-status check alone is rejected. The first run pins the fixture and provider-model revisions. Execute the deliberate duplicate-posting variant: one journal is expected, but two are observed. JUnit reports a failure. Retain the assertion, trace and journal identifiers before cleanup. This is a designed challenge, not a reported banking incident. The defect record links that failed run. AI proposes duplicate posting as a hypothesis, with evidence references. An engineer confirms the cause and reviews a production-code repair. Neither the AI summary nor the repair process may turn the original failed run into a pass. A fresh retest uses a new run identifier and unchanged payment expectations. The corrected build should pass, while the deliberately faulty variant must still fail. Link the source change and both results so the reviewer can inspect the difference. The release pack includes the approved requirement, test commit, fixture and stub revisions, failed run, reviewed defect, repair and retest. Check required coverage and real-provider evidence before deciding. If integration proof is absent, the pack records that gap; the diagram does not grant release approval.",
+ "voice": "ElevenLabs / Chris — Charming, Down-to-Earth",
+ "caption_method": "ElevenLabs character alignment; authored section boundaries",
+ "duration": 110.88,
+ "sha256": "c692bde7540abeb4bc3f939a1057cf5c7a714f4613bda6ef32183df2f205bdc5"
+ },
+ "slide-33": {
+ "audio": "/assets/audio/banking-journey-v1.22.0/technical/slide-33.mp3",
+ "captions": "/assets/audio/banking-journey-v1.22.0/technical/slide-33.vtt",
+ "transcript": "The starting state has manual API requests and spreadsheets, shared environments, and no virtualized provider backend. QA engineers collect and reconcile evidence. Vendor test-slot availability constrains parallel execution. The modernized state introduces reviewed REST Assured and JUnit tests, delivery-pipeline execution, isolated fixtures and a validated WireMock provider model. Testcontainers supports repeatable service-test resources. Raw assertions, traces and run identifiers survive cleanup. This foundation creates repeatability without depending on AI. The AI-assisted state adds approved context, candidate artifacts and evidence-based assistance around that same execution path. AI drafts tests and fixtures, proposes relevant scope and diagnoses failures. Reviewers approve changes before existing runners execute them. Compare equivalent payment packs to distinguish modernization gains from incremental AI benefit. Include review, correction, platform overhead and real-provider checks. No measured improvement is claimed in this scenario.",
+ "voice": "ElevenLabs / Chris — Charming, Down-to-Earth",
+ "caption_method": "ElevenLabs character alignment; authored section boundaries",
+ "duration": 68.8,
+ "sha256": "7e3426502372771118d6b85186ea10418d88bb59209bd7ee2b7ca9fd6ecf9622"
}
},
"duration": 960.72
@@ -681,6 +726,15 @@
"caption_method": "ElevenLabs character alignment, restored display terminology",
"duration": 31.52,
"sha256": "18a1cc2acaaad7838d4f7a21145abc3449a2aa26b1edeeac09cf95b0917cd4d2"
+ },
+ "slide-26": {
+ "audio": "/assets/audio/banking-journey-v1.22.0/evp/slide-20.mp3",
+ "captions": "/assets/audio/banking-journey-v1.22.0/evp/slide-20.vtt",
+ "transcript": "Let's follow what AI contributes to one banking release. Our example is a payment that times out after acceptance. The customer retries, and the team must prove that the money moves once. First, AI helps clarify the requirement. The product owner confirms the expected behavior. Second, AI drafts the test scenarios: normal payment, timeout, repeated callback, concurrent retry, and a conflicting request. Domain testers review the coverage and expected outcomes. Third, AI helps developers write unit tests for retry and duplicate-request logic. These are fast checks of code behavior; they do not replace payment integration tests. Fourth, AI turns accepted cases into candidate API and user-interface tests. Reviewers require money-movement assertions, not just a successful response. Fifth, AI helps draft synthetic data and provider simulations. Engineers validate them. Isolated environments and service virtualization make the work repeatable. Sixth, AI recommends relevant tests or requests an authorized pipeline run. The delivery pipeline executes the tests. Mandatory payment coverage stays in place. Seventh, AI connects failed assertions with logs and traces, and drafts a diagnosis. The team checks the evidence before accepting the explanation. Eighth, AI can propose a repair. A developer reviews the change, and the pipeline reruns the tests with fresh data. The expected payment behavior stays fixed. Ninth, AI assembles a linked release summary and suggests reviewed failures for the regression suite. People decide whether the evidence is sufficient. That is the end-to-end opportunity: less repetitive preparation and investigation, supported by dependable execution and accountable review. This is a proposed workflow to validate in a pilot.",
+ "voice": "ElevenLabs / Chris — Charming, Down-to-Earth",
+ "caption_method": "ElevenLabs character alignment; authored section boundaries",
+ "duration": 122.24,
+ "sha256": "51bff8a242e0c0f414284bfffc7a6c2d1e38d21a8f2955a1a786f99486bc15eb"
}
},
"duration": 737.68
@@ -689,13 +743,13 @@
"label": "Industry technical narration",
"slides": {
"slide-1": {
- "audio": "/assets/audio/chris-v1.17.0/industry-technical/slide-1.mp3",
- "captions": "/assets/audio/chris-v1.17.0/industry-technical/slide-1.vtt",
- "transcript": "This presentation examines the system behind AI-enabled quality work. We will connect context, independent evaluation, action boundaries, release decisions and operational feedback. The architecture covers both AI-assisted engineering and assurance of AI applications. Every important boundary needs an owner, a versioned contract and a failure behavior. The banking engineering blueprint provides the more detailed payment implementation example; this deck develops the reusable assurance architecture.",
+ "audio": "/assets/audio/banking-journey-v1.22.0/industry-technical/slide-1.mp3",
+ "captions": "/assets/audio/banking-journey-v1.22.0/industry-technical/slide-1.vtt",
+ "transcript": "This industry briefing explains assurance across the AI lifecycle: context, generated tests, independent evaluation, action controls and release evidence. It includes testing AI applications as well as using AI in quality engineering. If your immediate question is how AI helps an existing banking QA team, follow the banking workflow link on this slide. That engineering walkthrough traces one payment requirement through unit tests, API tests, fixtures, execution, diagnosis, repair and release evidence. The final slide here also provides that nine-step overview. Choose the banking route for concrete delivery handoffs, and this industry route for the wider assurance architecture.",
"voice": "ElevenLabs / Chris — Charming, Down-to-Earth",
- "caption_method": "ElevenLabs character alignment, restored display terminology",
- "duration": 31.12,
- "sha256": "56d97bcdecb12bb1d7947ce5fc3403358140c526d8fae8c927315e7e52ababf7"
+ "caption_method": "ElevenLabs character alignment; authored section boundaries",
+ "duration": 44.64,
+ "sha256": "97ca4704cdc2205397cc1001b3fa64d67e4089376e2df0bad9620ec57b27d9fe"
},
"slide-2": {
"audio": "/assets/audio/architecture-v1.21.0/industry-technical/slide-2.mp3",
@@ -1002,6 +1056,15 @@
"caption_method": "ElevenLabs character alignment, restored display terminology",
"duration": 33.44,
"sha256": "ebf1588c359257ebba0ba55677f36dfdcbe18f80e11a66f85b11ed32b6530a6c"
+ },
+ "slide-36": {
+ "audio": "/assets/audio/banking-journey-v1.22.0/technical/slide-31.mp3",
+ "captions": "/assets/audio/banking-journey-v1.22.0/technical/slide-31.vtt",
+ "transcript": "Trace one release through nine handoffs. This is AI assistance to an existing payments testing team, distinct from evaluating an AI application. Start with approved context: the payment story, API contract and relevant defects. AI drafts clarification questions. Product and domain QA approve the rule that a same-key, same-payload retry returns the original transfer without a second posting. Next, test design produces a reviewed matrix. AI proposes timeout, duplicate callback, concurrency and conflicting-payload cases. Domain QA supplies the expected behavior independently of the implementation. A written case is an input to executable test code, not the code itself. The developer unit-test step uses the handler source and accepted behavior. Copilot can draft JUnit candidates for key validation and duplicate-request logic. The developer checks the fake repository and verifies one insertion for repeated calls. A passing unit test does not establish correctness across the real database and provider. The API and user-interface step turns the reviewed matrix into a pull request. REST Assured tests exercise the payment service; selected Playwright checks cover the customer's pending state and retry action. Reviewers require the original transfer identifier, one journal, and balances of ninety thousand and ten thousand minor units. A status-only assertion is rejected. Data and provider behavior are versioned inputs. AI can draft synthetic seed scripts and WireMock mappings for acceptance followed by a timeout. Engineers validate those mappings against the provider contract. Testcontainers and the delivery pipeline supply repeatable resources. Real-provider and settlement checks remain separate requirements. For execution, AI may recommend affected tests or request an authorized pipeline job. Azure Pipelines runs the approved suite and publishes raw JUnit results and traces. The mandatory payment suite cannot be silently omitted. Record the build, test commit, fixture and stub versions under the run identifier. During investigation, AI reads retained evidence and proposes a cause. In our injected-defect example, the assertion expects one journal but observes two. The defect draft must link that evidence. A reviewer confirms the diagnosis, and the original failing verdict remains unchanged. For repair, AI may propose a source change for developer review. Keep the accepted payment assertions fixed. The pipeline uses a fresh run identifier and isolated data for the retest. The corrected build must pass, and the deliberate duplicate-posting variant must still fail. For release evidence, AI drafts a summary of coverage, run results, reviewed dispositions and missing checks. The release owner reviews the linked pack, including required real-provider evidence. Accepted defects can become reviewed regression cases. The shared platform provides context access, artifact versions, scoped pipeline access and evidence retention across these steps; it does not replace the named owners.",
+ "voice": "ElevenLabs / Chris — Charming, Down-to-Earth",
+ "caption_method": "ElevenLabs character alignment; authored section boundaries",
+ "duration": 199.04,
+ "sha256": "a3d24c7646517acd5344a359b294ccb308401b793e8b7edd20d3abb158fbe095"
}
},
"duration": 1025.2
diff --git a/assets/pdf/ai-qe-evp-v1.22.0.pdf b/assets/pdf/ai-qe-evp-v1.22.0.pdf
new file mode 100644
index 0000000..739041e
Binary files /dev/null and b/assets/pdf/ai-qe-evp-v1.22.0.pdf differ
diff --git a/assets/pdf/ai-qe-fintech-evp-v1.22.0.pdf b/assets/pdf/ai-qe-fintech-evp-v1.22.0.pdf
new file mode 100644
index 0000000..cfc7441
Binary files /dev/null and b/assets/pdf/ai-qe-fintech-evp-v1.22.0.pdf differ
diff --git a/assets/pdf/ai-qe-fintech-technical-v1.22.0.pdf b/assets/pdf/ai-qe-fintech-technical-v1.22.0.pdf
new file mode 100644
index 0000000..60b7d4f
Binary files /dev/null and b/assets/pdf/ai-qe-fintech-technical-v1.22.0.pdf differ
diff --git a/assets/pdf/ai-qe-technical-v1.22.0.pdf b/assets/pdf/ai-qe-technical-v1.22.0.pdf
new file mode 100644
index 0000000..7ba7b34
Binary files /dev/null and b/assets/pdf/ai-qe-technical-v1.22.0.pdf differ
diff --git a/briefings/evp.html b/briefings/evp.html
index 46ab378..28889dc 100644
--- a/briefings/evp.html
+++ b/briefings/evp.html
@@ -5,7 +5,7 @@
description: Research-informed AI and quality engineering — Executive · Strategic vision.
audience: Executive · Strategic vision
deck_class: evp-deck
-slide_count: 25
+slide_count: 26
nav_exclude: true
search_exclude: true
permalink: /briefings/evp/
@@ -148,3 +148,9 @@
25 / Fintech evidence and adoption
A focused first engagement
{% include fintech-evidence/pilot-paths.html %}
Select the entry point that fits the client’s foundations. Build reusable assets and retain evidence for the next adoption decision.
{% include slide-footer.html n="25" source="/case-studies/fintech/evidence/" label="Fintech evidence and pilot design" %}
+
+
+
+{% include slide-footer.html n="36" source="/case-studies/fintech/#ai-journey" label="Banking workflow, artifacts and sources" %}
+
diff --git a/case-studies/fintech-implementation.md b/case-studies/fintech-implementation.md
index d8c586e..f96741d 100644
--- a/case-studies/fintech-implementation.md
+++ b/case-studies/fintech-implementation.md
@@ -200,3 +200,37 @@ Use one record per comparable API test pack. Retain failed runs and foundation w
## External evidence and the client trial
The [financial-services evidence explorer]({{ '/case-studies/fintech/evidence/' | relative_url }}) separates direct AI testing cases from modernization and adjacent engineering results. Use its trial selector to agree the first workflow, reviewer and acceptance criteria. Peer figures do not replace Our Banking Client’s illustrative inputs or supply a client forecast. Record actual API pilot dates and effort against the illustrative planning windows; readiness and sufficient evidence determine progression.
+
+## From a unit-test candidate to API proof {#unit-to-api}
+
+The [nine-step walkthrough]({{ '/case-studies/fintech/#ai-journey' | relative_url }}) follows one authored payment scenario. Its identifiers connect the handoffs; they are not records from a deployed bank. Developer unit testing is shown alongside the existing eight-stage QA effort model, without adding an unsupported savings estimate.
+
+**Approved input:** AC-142 requires the same idempotency key and payload to return the original transfer without another posting. CASE-142-R exercises a timeout after provider acceptance and a same-key retry. Domain QA sets the expected outcome before AI drafts the code.
+
+An AI assistant can draft this **JUnit-style pseudocode** from the accepted behavior and existing test patterns. The handler, request and fake repository below illustrate interfaces that the application team must implement; this snippet is not an executable bank integration.
+
+```java
+@Test void sameKeyReturnsOriginalTransfer() {
+ var repository = new RecordingFakeTransferRepository();
+ var handler = new TransferHandler(repository);
+ var request = transfer("pay-142", "payer", "recipient", 10000);
+
+ var original = handler.create(request);
+ var retry = handler.create(request);
+
+ assertEquals(original.id(), retry.id());
+ assertEquals(1, repository.insertions());
+}
+```
+
+**Developer review:** verify that the fake records real calls, that assertions reflect AC-142, and that the test fails when deduplication is deliberately bypassed. This unit test does not exercise network timeouts, actual database constraints, provider acceptance, or concurrent transactions. Those need separate API, concurrency and integration cases.
+
+**API handoff:** PR-142 carries the reviewed executable test. FIX-142 supplies synthetic accounts starting at 100000 and 0 minor units. STUB-142 models provider acceptance followed by a lost response. A REST Assured/JUnit test must check the original transfer ID, exactly one balanced journal, payer 90000 and recipient 10000 minor units after retry. Selected Playwright checks cover the pending state and customer retry action.
+
+**Failure and repair:** the deliberately faulty variant produces two journals in RUN-142. AI can draft DEF-142 with assertion, trace and journal references; an engineer confirms the cause. Keep the original FAIL record. After a reviewed production fix, RERUN-143 uses fresh data and unchanged expected behavior. The corrected build must pass and the deliberate duplicate-posting variant must still fail. These are expected sample outcomes, not executed client results.
+
+**Release handoff:** PACK-142 links AC-142, CASE-142-R, the test commit, fixture/stub revisions, original run, reviewed defect, fix and rerun. Required real-provider checks and settlement evidence remain release gates. AI drafts the summary; the release owner decides.
+
+**Measure three states:** compare manual QE with repeatable automated QE, then compare equivalent automated packs with and without AI assistance. Record critical-scenario coverage, candidate acceptance after review, injected-fault detection, environment wait, feedback time and evidence completeness. Include review, rework and platform overhead. Service virtualization benefits must not be counted as an isolated AI gain.
+
+Mechanism references: [Copilot test generation and review](https://docs.github.com/en/copilot/tutorials/write-tests), [WireMock service virtualization](https://wiremock.org/docs/solutions/service-virtualization/), and [Azure Pipelines test-result publishing](https://learn.microsoft.com/en-us/azure/devops/pipelines/tasks/reference/publish-test-results-v2?view=azure-pipelines).
diff --git a/case-studies/fintech.html b/case-studies/fintech.html
index b54d28d..fc978f2 100644
--- a/case-studies/fintech.html
+++ b/case-studies/fintech.html
@@ -8,7 +8,7 @@
---
{% assign case = site.data.fintech_case %}
-
{{ site.data.fintech_case.company }} / A fictional fintech story / Edition v{{ case.edition }}
A payment retry. A different way to deliver quality.
In this QE testing scenario, a customer sends CAD 100, sees a timeout and tries again. Across five squads, 75 offshore QA staff need to prove that the money moves once while much testing remains manual and vendor test environments are scarce. Follow the release and the work behind it.
{{ case.disclosure }}
+
{{ site.data.fintech_case.company }} / A fictional fintech story / Edition v{{ case.edition }}
A payment retry. A different way to deliver quality.
In this QE testing scenario, a customer sends CAD 100, sees a timeout and tries again. Across five squads, 75 offshore QA staff need to prove that the money moves once while much testing remains manual and vendor test environments are scarce. Follow the release and the work behind it.
{{ case.disclosure }}
@@ -24,6 +24,14 @@
QE testing scenario with an injected defect, not an observed client failure. No live payment service, test runner or customer data is used. Each journal has two balancing entries. No fees, FX or unrelated activity. The arrows show sequence, not traffic volume.
+
One release / Nine connected steps
What AI contributes from requirement to release
Follow PAY-142 through approved intent, test design, developer unit tests, executable API/UI tests, fixtures, execution, investigation, repair and release evidence. Each step names the AI output and the person who checks it. This is a proposed walkthrough, not a claim that a bank has already deployed it.
+{% include fintech/ai-journey.html %}
+
Three responsibilities: AI drafts and recommends. Existing automation provisions environments and executes tests. People approve behavior, changes and release decisions. Unit testing is developer work alongside the QA workflow; it adds no hours to the existing eight-stage effort model.
+
{% for step in site.data.qe_journey.figures['qe-journey'].nodes %}{{ step.title }}
Follow one artifact chain, including the failed run
Every reference below belongs to the same authored PAY-142 example. The duplicate-posting defect is deliberately injected to challenge the test. Original failures remain linked after a repair; actual integration evidence is still required.
{% include fintech/artifact-trace.html %}
Outcome checks: critical-scenario coverage, first-pass usable candidates, injected-fault detection, environment waiting, feedback time and evidence completeness. Compare manual to modernized QE first; then measure the additional effect of AI on equivalent packs, including review and rework.
+
The leadership adoption roadmap
Four layers of AI-assisted QE
Start with a person using Copilot, connect one repeatable workflow, delegate bounded tasks where justified, and scale proven services across squads. Select a layer to inspect its payment example and prerequisites.
This is the target to build and prove; backend service virtualization and isolated runs are not available in the scenario baseline. Context adapters bring approved stories, test examples and relevant defects into the AI workbench. Reviewers approve artifacts before existing pipelines execute them. The platform team owns the shared integration and fixtures; each application team owns its expected behavior.
Use three primary measures to judge whether the pilot earns trust. Inspect the definitions below for supporting proof, owners and limits.
{% include fintech/outcomes.html %}
Business outcomes to validate: fewer customer-impacting payment defects, fewer emergency fixes and more predictable releases. Track these across comparable releases; the pilot measures alone do not establish those effects.
Choose a stage to inspect the manual work, AI assistance and a concrete sample artifact. Samples are authored illustrations, not a live payment integration.
+
03 / Break down the work
AI assistance at every workflow stage
Before / after: manual, modernized and AI-assisted QE
{% include fintech/before-after.html %}
Choose a stage to inspect the manual work, AI assistance and a concrete sample artifact. Samples are authored illustrations, not a live payment integration.
{% for stage in case.workflow %}
{{ forloop.index }}. {{ stage.title }}
“{{ stage.example }}”
How the work changes: inputs, assistance, owners and tools
{% endfor %}
diff --git a/docs/research-log.md b/docs/research-log.md
index 0c7c9fe..c0b3005 100644
--- a/docs/research-log.md
+++ b/docs/research-log.md
@@ -148,3 +148,8 @@ Earlier entries below record the initial review; this entry supersedes their sta
- Will OSFI issue guidance specific to agentic AI beyond the July 2026 bulletin, and will E-23 proportionality be clarified for human-reviewed assistants?
- What does Bill C-36 look like after second reading, and does the automated-decision explanation duty reach AI-generated test evidence?
- Do any banks publish measured results (not case-study claims) for AI-QE pilots with a stated capture mechanism?
+
+
+## 9 September 2026 — Banking AI contribution through the release
+
+Rechecked GitHub Copilot test-generation guidance, WireMock service virtualization and Azure Pipelines Publish Test Results documentation. The in-place banking walkthrough maps these mechanisms to approved inputs, AI candidates, engineer review, deterministic execution and retained evidence. PAY-142 artifacts and failure/repair results are authored illustrations; no client execution or measured outcome is claimed. The comparison separates modernization from incremental AI assistance. Existing eight-stage QA effort assumptions remain unchanged.
diff --git a/index.md b/index.md
index c8cd7f5..45f0b03 100644
--- a/index.md
+++ b/index.md
@@ -25,14 +25,14 @@ has_toc: false
What happens when the payment provider accepts a transfer, but the customer sees a timeout? Use this familiar problem to explain the platform, the workflows and the human decisions.
What happens when the payment provider accepts a transfer, but the customer sees a timeout? Use this familiar problem to explain the platform, the workflows and the human decisions.
1See the payment failureRetry, duplicate prevention and reconciliation
2Break down the QA workManual work → AI assistance → human check
3Change the delivery assumptionsDevOps, cloud and testing maturity affect the opportunity
diff --git a/releases.md b/releases.md
index 93da07a..debafe2 100644
--- a/releases.md
+++ b/releases.md
@@ -9,6 +9,14 @@ The version identifies the site and presentation player. A player-only patch can
+## v1.22.0 · 9 September 2026
+
+The [banking case]({{ '/case-studies/fintech/#ai-journey' | relative_url }}) now follows **nine explicit AI-assisted steps**, from approved requirements and developer unit tests through API/UI tests, fixtures, CI execution, investigation, repair and release evidence. A connected artifact trail preserves the original injected-defect failure, reviewed fix and fresh retest.
+
+The comparison distinguishes **manual QE, modernized QE and AI-assisted QE**, with separate contributions and measures. Existing slide links remain valid. Guided banking routes bring the new workflow, comparison and evidence trail into the presentation sequence; the industry decks link to the banking implementation story.
+
+All **116 slides** have narration and timed English captions. Changed explanations use new recordings; workflow, comparison and artifact highlights follow those recordings, including pause and seek. Existing two-second slide pauses and shared audio focus remain. All four slide/PDF editions advance to **v1.22.0**: banking **21 executive / 33 technical**, industry **26 executive / 36 technical**. The film retains its original edition. [GitHub release v1.22.0](https://github.com/tomqwu/ai_qe/releases/tag/v1.22.0) packages the current publication.
+
## v1.21.2 · 9 September 2026
The [3D architecture]({{ '/demos/architecture/?scenario=generate' | relative_url }}) now opens from a **higher, more front-facing camera angle**, so the platform's depth is easier to read. Framing fits the model with space around its edges and preserves its proportions across wide, short and mobile windows. Camera motion keeps the same elevated view.
diff --git a/tools/check_flow_narration.cjs b/tools/check_flow_narration.cjs
index e2aa232..ad0ffca 100644
--- a/tools/check_flow_narration.cjs
+++ b/tools/check_flow_narration.cjs
@@ -93,7 +93,7 @@ async function snapshot(figure) {
cueCount++;
}
}
- assert.equal(toured.size,9);
+ assert.equal(toured.size,new Set(profiles.map(profile=>profile.diagram)).size);
// Paused frame, playback speed, backwards seek, replay and manual inspection.
await page.goto(base+'/briefings/technical/#slide-2');
const figure=page.locator('#slide-2 [data-diagram="platform"]'),audio=page.locator('[data-narration-audio]');
diff --git a/tools/check_presenter_notes.cjs b/tools/check_presenter_notes.cjs
index 0bb691c..16f5a60 100644
--- a/tools/check_presenter_notes.cjs
+++ b/tools/check_presenter_notes.cjs
@@ -2,6 +2,8 @@
const assert = require('node:assert/strict');
const {chromium, webkit} = require('playwright');
const base = (process.env.QE_TEST_URL || 'http://127.0.0.1:61600/ai_qe').replace(/\/$/, '');
+const deckCounts = require('../_data/briefing_room.json').map(deck => [deck.url.split('/').filter(Boolean).at(-1), deck.slides]);
+const slideCount = deckCounts.reduce((sum, [, count]) => sum + count, 0);
const routes = ['', 'ai-adoption/', 'qe-modernization/', 'dictionary/', 'platform-readiness/',
'case-studies/fintech/', 'case-studies/fintech/evidence/', 'case-studies/fintech/implementation/',
'docs/industry/', 'docs/industry/operating-model/', 'docs/industry/evidence/',
@@ -41,7 +43,7 @@ async function playing(audio) { await audio.page().waitForFunction(a => !a.pause
assert.doesNotMatch(await page.locator('body').innerText(), /\bChris\b/, 'Public narration uses neutral audio labels');
}
assert.equal(requestedAudio,0,'Collapsed in-place guides do not download MP3 files');
- for(const [route,count] of [['fintech-evp',19],['fintech-technical',30],['evp',25],['technical',35]]){
+ for(const [route,count] of deckCounts){
await page.goto(base+`/briefings/${route}/`);
await page.waitForFunction(n=>document.querySelectorAll('.slide-narrator-notes').length===n,count);
assert.equal(await page.locator('[data-narrator-guide]').count(),0,'No duplicate page player inside slides');
@@ -101,7 +103,7 @@ async function playing(audio) { await audio.page().waitForFunction(a => !a.pause
await page.emulateMedia({media:'print'});
assert.equal(await page.locator('[data-narrator-guide]').isVisible(),false);
assert.deepEqual(errors,[]);
- console.log(`${engine.name()}: all 109 slide notes; diagram coverage on 16 existing pages; actual recorded audio/captions, lazy loading, audio focus, mobile and four architecture scenarios passed`);
+ console.log(`${engine.name()}: all ${slideCount} slide notes; diagram coverage on 16 existing pages; actual recorded audio/captions, lazy loading, audio focus, mobile and four architecture scenarios passed`);
}finally{await browser.close();}
}
})().catch(error=>{console.error(error);process.exit(1);});
diff --git a/tools/check_recorded_narration.cjs b/tools/check_recorded_narration.cjs
index af3f4f3..054b8ed 100644
--- a/tools/check_recorded_narration.cjs
+++ b/tools/check_recorded_narration.cjs
@@ -89,13 +89,13 @@ async function advanced(page, id) {
}
await page.goto(base+'/briefings/fintech-technical/?route=client#slide-26');
await page.locator('[data-narration-start]').click(); await playing(page);
- await nearEnd(page); await advanced(page, 'slide-28'); await playing(page);
- await page.goto(base+'/briefings/fintech-evp/#slide-19');
+ await nearEnd(page); await advanced(page, 'slide-19'); await playing(page);
+ await page.goto(base+'/briefings/fintech-evp/#slide-21');
await page.locator('[data-narration-start]').click(); await playing(page);
await nearEnd(page);
await page.waitForFunction(()=>document.querySelector('[data-narration-audio]').ended &&
document.querySelector('[data-narration-start]').getAttribute('aria-pressed') === 'false');
- assert.match(page.url(), /#slide-19$/);
+ assert.match(page.url(), /#slide-21$/);
assert.equal(await page.locator('[data-narration-start]').getAttribute('aria-pressed'),'false');
assert.deepEqual(errors,[]);
console.log(`${engine.name()}: guided-route order and final-slide stop passed`);
diff --git a/tools/prepare_release.py b/tools/prepare_release.py
index 0d9350f..8b07cf4 100644
--- a/tools/prepare_release.py
+++ b/tools/prepare_release.py
@@ -37,8 +37,12 @@ def prepare(output):
narration = json.loads((ROOT / 'assets/data/narration.json').read_text())
assert narration.get('complete'), 'The narration release requires all slide recordings'
bundle = assets / f'ai-qe-narration-v{release["version"]}.zip'
+ scripts = json.loads((ROOT / 'assets/data/narration-scripts.json').read_text())['decks']
+ assert set(narration['decks']) == set(scripts), 'Narration audiences differ from the slide scripts'
+ total_slides = sum(len(slides) for slides in scripts.values())
records = []
for audience, deck in narration['decks'].items():
+ assert set(deck['slides']) == set(scripts[audience]), f'{audience}: incomplete narration coverage'
for slide, entry in deck['slides'].items():
for field in ('audio', 'captions'):
source = (ROOT / entry[field].lstrip('/')).resolve()
@@ -47,7 +51,7 @@ def prepare(output):
assert hashlib.sha256(source.read_bytes()).hexdigest() == entry['sha256'], 'Changed narration audio'
records.append((source.relative_to(ROOT).as_posix(), source.read_bytes()))
records.append((f'transcripts/{audience}/{slide}.txt', (entry['transcript'] + '\n').encode()))
- assert len(records) == 109 * 3, 'Narration bundle must cover all 109 slides'
+ assert len(records) == total_slides * 3, 'Narration bundle must cover every slide'
records.append(('narration.json', json.dumps(narration, ensure_ascii=False, indent=2).encode()))
guides = json.loads((ROOT / 'assets/data/narration-guides.json').read_text())
for guide in [*guides['guides'], *guides['demo'].values()]:
@@ -57,7 +61,7 @@ def prepare(output):
records.append(('narration-flows.json', json.dumps(flows, ensure_ascii=False, indent=2).encode()))
records.append(('README.txt', (
'AI x QE — English audio narration\n\n'
- 'One MP3, timed WebVTT subtitle file and transcript per slide. '
+ 'Every slide maps to MP3 audio, timed WebVTT captions and a transcript. Shared explanations may reuse a recording. '
'Folder keys: evp = banking executive, technical = banking architecture, '
'industry-evp = industry executive, industry-technical = industry architecture.\n\n'
'Open https://tomqwu.github.io/ai_qe/briefings/ and select Play narration '
@@ -65,10 +69,10 @@ def prepare(output):
'narration-guides.json maps existing diagram and scenario explanations to these recordings '
'and supplies presenter walkthrough notes and the 3D story caption anchors. narration-flows.json maps exact recorded caption '
'cues to diagram components and arrows for audio-driven visual focus. '
- 'The original PDF content editions are unchanged.\n'
+ f'Industry PDFs: v{release["slide_edition"]}; banking PDFs: v{release["fintech_edition"]}.\n'
).encode()))
with zipfile.ZipFile(bundle, 'w', compression=zipfile.ZIP_DEFLATED) as archive:
- for name, content in sorted(records):
+ for name, content in sorted(dict(records).items()):
info = zipfile.ZipInfo(name, date_time=(2026, 9, 8, 0, 0, 0))
info.compress_type = zipfile.ZIP_DEFLATED
archive.writestr(info, content)
@@ -96,7 +100,7 @@ def prepare(output):
- Research companion: **v{release["research_edition"]}** — 13 pages
- Fillable discovery questionnaire: **v{release["questionnaire_edition"]}**
-Assets include all six PDFs, the architecture film and captions, the industry, modernization and fintech-evidence CSV/JSON source registers, and the complete 109-slide audio narration bundle with English subtitles and transcripts. SHA256SUMS.txt covers all fifteen downloadable publication files. The PDF filenames identify their content edition, which may precede a player release. The existing architecture film retains its v1.8.0 edition.
+Assets include all six PDFs, the architecture film and captions, the industry, modernization and fintech-evidence CSV/JSON source registers, and the complete {total_slides}-slide audio narration bundle with English subtitles and transcripts. SHA256SUMS.txt covers all fifteen downloadable publication files. The PDF filenames identify their content edition, which may precede a player release. The existing architecture film retains its v1.8.0 edition.
Published only after the site build, browser checks, PDF checks and GitHub Pages deployment succeed. The fintech case is fictional; its estimates and outcomes are illustrative assumptions.
'''
diff --git a/tools/test_generate_elevenlabs_narration.py b/tools/test_generate_elevenlabs_narration.py
index 8b9bc95..59f2a5f 100644
--- a/tools/test_generate_elevenlabs_narration.py
+++ b/tools/test_generate_elevenlabs_narration.py
@@ -18,7 +18,7 @@ def setUp(self):
def test_all_slide_scripts_restore_to_the_display_text(self):
plan = generator.build_plan(self.scripts, self.profile, generator.DECKS)
- self.assertEqual(len(plan['jobs']), 109)
+ self.assertEqual({(job['audience'], job['slide']) for job in plan['jobs']}, {(audience, slide) for audience, slides in self.scripts['decks'].items() for slide in slides})
for job in plan['jobs']:
text = job['speakText']
fixture = {'characters': list(text),
diff --git a/tools/test_release.py b/tools/test_release.py
index 045328a..de4bf76 100644
--- a/tools/test_release.py
+++ b/tools/test_release.py
@@ -6,7 +6,7 @@
import unittest
import zipfile
from publish_release import publish
-from prepare_release import prepare
+from prepare_release import prepare, ROOT
SHA = 'a' * 40
@@ -95,11 +95,20 @@ def test_current_package_contains_only_current_editions(self):
self.assertEqual(set(guides['demo']), {'generate', 'evaluate', 'deny', 'hold'})
self.assertEqual(sum(len(guide['story']) for guide in guides['demo'].values()), 24)
flows = json.loads(archive.read('narration-flows.json'))
- self.assertEqual(len(flows['profiles']), 12)
- self.assertEqual(sum(len(profile['cues']) for profile in flows['profiles']), 85)
- for extension in ('.mp3', '.vtt'):
- self.assertEqual(sum(name.endswith(extension) for name in archive.namelist()), 109)
- self.assertEqual(sum(name.startswith('transcripts/') for name in archive.namelist()), 109)
+ self.assertEqual(flows, json.loads((ROOT / 'assets/data/narration-flows.json').read_text()))
+ self.assertEqual(len(archive.namelist()), len(set(archive.namelist())), 'Shared recordings must not duplicate ZIP paths')
+ narration = json.loads(archive.read('narration.json'))
+ scripts = json.loads((ROOT / 'assets/data/narration-scripts.json').read_text())['decks']
+ expected_media = set()
+ for audience, slides in scripts.items():
+ self.assertEqual(set(narration['decks'][audience]['slides']), set(slides))
+ for slide in slides:
+ entry = narration['decks'][audience]['slides'][slide]
+ expected_media.update(entry[field].lstrip('/') for field in ('audio','captions'))
+ self.assertEqual(archive.read(f'transcripts/{audience}/{slide}.txt').decode().strip(), entry['transcript'])
+ self.assertEqual(hashlib.sha256(archive.read(entry['audio'].lstrip('/'))).hexdigest(), entry['sha256'])
+ self.assertEqual({name for name in archive.namelist() if name.endswith(('.mp3','.vtt'))}, expected_media)
+ self.assertEqual(sum(name.startswith('transcripts/') for name in archive.namelist()), sum(map(len,scripts.values())))
if __name__ == '__main__':
{% include slide-footer.html n="01" source="/docs/industry/" label="Research scope and sources" %}