← BBS SG Bank submission · All documents

05 — Demo Script (2–3 minutes)

Target length: 2:30 (hard cap 3:00). Presenter: {PRESENTER_NAME}. Recording: https://bbs-sg-bank-demo.pages.dev/media/bbs-sg-bank-demo.mp4 · Live app: https://bbs-sg-bank-demo.pages.dev.

Rule for this demo: show, don't claim. We show the legacy code, run the modern batch through the actual demo app, run both test suites, and show the measured parity/benchmark transcripts. Every speedup figure is shown only with the disclosure that the workload is synthetic and the legacy design deliberately inefficient (see 02-before-after.md §6).

Pre-flight checklist (do before recording)

python3 site/backend/app.py --open (defaults to http://127.0.0.1:8765/).

app reports the legacy time as unavailable — here are the transcripts from a host that has it."* (Never invent a number.)

Script

0:00–0:20 — Hook (screen: app Overview tab)

"BBS SG Bank runs its overnight batch on this: a COBOL program that, for every single transaction, re-opens the accounts file and scans every account, then rewrites the whole file. Deposit, withdraw, transfer — same cost every time. This is the app we built around the modernized engine; everything you'll see runs live against the real batch code."

0:20–0:45 — Before (screen: legacy/bank.cob, highlight L108 + L133)

"Two lines tell the story. Line 108: 'reopen and scan the flat file for every operation.' Line 133: 'rewrite every account for every accepted operation.' The cost is operations times accounts — it gets quadratically worse as the bank grows. The fix isn't faster COBOL; it's not doing that work at all."

0:45–1:20 — After (screen: Batch console tab → Run a batch)

"The modern engine loads accounts once into an in-memory index, applies each operation with a constant-time lookup, and writes the file once — O(accounts + operations) instead of O(operations × accounts). I'll run a 60-operation batch."

Click Run a batch; point at the result panel.

"Notice three things: the ledger total is unchanged — transfers only move value, they don't create it; the rejected rows are broken out by reason; and this 'engine matches simulation' check confirms the UI's expectations agree with what the batch actually did. The site runs the unmodified engine, not a reimplementation."

1:20–1:50 — Correctness (screen: terminal → run both suites, then open the transcripts)

"We don't ask you to trust that. The core suites pass: 33 tests in scripts/test_bank.py and 5 in tests/test_modern.py — covering deposits, withdrawals, transfers, every rejection case, malformed input, and the duplicate-ID / overflow safety checks. The demo site has 50 more and the operator terminal 20. And here's the parity proof: the harness compiles the real COBOL and the modern batch, runs them on byte-identical fixtures, and confirms identical output and byte-identical account files."
GNUBOL_PREFIX=/tmp/gcb-build/install python3 scripts/test_bank.py     # Ran 33 tests … OK
python3 tests/test_modern.py                                          # Ran 5 tests … OK

Open scripts/evidence/benchmark-1200x400.txt.

"Same results on both engines. And because we've now built GnuCOBOL, the harness can time both: the legacy batch takes about a second at 1,200 accounts versus 35 milliseconds for the modern engine — 28.6x — and at 5,000 accounts it's 128.1x. The operator terminal runs that same real COBOL live: a 1,200×400 job did 400 processed, 3 rejected in 1.197 s of actual COBOL execution (1.234 s overall), and the modern engine's total matched. Two honest caveats: this is a synthetic workload, and the legacy design is deliberately inefficient — it rewrites the whole ledger per operation — so this is a fact about that algorithm, not a claim about COBOL in general."

1:50–2:15 — How we built it (screen: Forge pipeline slide)

"We drove the planning of this through the Opsera Forge pipeline. We uploaded the legacy folder to Forge and its Assessment is complete: ForgeScore 57 out of 100 — Developing, with 10 findings including 3 high, flagging exactly the O(m×n) scans, the full-file rewrites, and the missing specs. We approved and downloaded Intent v1, PRD-Spec v1, Architecture v1 and User Stories v1 (6 epics / 33 proposed stories), and Forge generated and exported Testing v1 (132 proposed test cases) — that page had no Approve button — all into docs/forge/ with recorded hashes. The stories and test cases are proposals, not implemented features or executed tests; the local suites are separate and total 108 passing. The supplied MCP token still returns 401, so we pulled the documents through the signed-in browser, which works. To be clear: Forge authored the planning documents, and its proposals (safe temp-file replacement, append-only audit, FastAPI, Forge Shipping) are not implemented; the modern Python is our own code — Forge assessed and framed the work; it didn't write or run the engine, and nothing is deployed."

2:15–2:35 — Impact + close (screen: impact slide)

"The impact: a super-linear batch becomes linear — one file write per run instead of one per transaction — no GnuCOBOL toolchain, an audit trail for every posting, and tests that guard every future change. That's BBS SG Bank's batch, modernized, with the proof in the repo."

Timing table

SegmentLengthCumulative
Hook / problem0:200:20
Before (legacy)0:250:45
After (live batch)0:351:20
Correctness (tests + measured parity)0:301:50
Forge pipeline0:252:15
Impact + close0:202:35

Do / Don't

✅ Do❌ Don't
Show the two bottleneck lines in real codeQuote a speedup without the synthetic-workload disclosure
Run a batch live in the appHand-wave the parity check
Show the measured transcripts (28.6x / 128.1x) with the disclosurePresent 128.1x as a general COBOL or banking claim
State "33 + 5 core tests pass; parity byte-identical" if askedClaim the prototype has a public hosted URL
Credit Forge for the Assessment, Intent v1 and PRD-Spec v1 documentsClaim Forge generated or ran the modern engine

Q&A crib

Likely questionAnswer
"Prove the speedup.""Measured with isolated GnuCOBOL 3.2.0: 1.004s→0.035s (28.6x) at 1200×400 and 4.728s→0.037s (128.1x) at 5000×500, parity byte-identical. Synthetic fixtures against a deliberately inefficient legacy design — not a general COBOL claim."
"How do you know it's correct?""33 tests in scripts/test_bank.py + 5 in tests/test_modern.py (plus 50 site and 20 terminal tests); the parity runs assert byte-identical account files."
"Is the UI a separate reimplementation?""No — site/backend/service.py calls the unmodified modern/bank.py engine and cross-checks its counts against a simulation after every batch."
"Where did Forge help?""The Forge Assessment is complete — 57/100, 10 findings incl. 3 high — and Intent v1, PRD-Spec v1, Architecture v1 and User Stories v1 (33 proposed stories) are approved, while Testing v1 (132 proposed cases) was generated and exported without an approval step; all are downloaded into docs/forge/ (hashes recorded). Those stories/tests are proposals, not code or runs; our local suites are 108 passing. Every stage maps to an artifact under docs/forge/ (doc 04). Forge authored the planning documents; we wrote the engine."
"What's unfinished?""The raw Assessment export, the Delivery stage, public hosting, demo recording, and per-member posts."