Skip to main content

PowerFill Greg-Demo Narrative — Demo with What We Have Today

Author: PSSaaS Collaborator Date: 2026-04-20 Status: DEFERRED — fallback reference material only. Per PO direction 2026-04-20: "I won't bug Greg to look at PSSaaS PowerFill until we have data for reports." This document was drafted as Backlog #32 path (a) when (a) was the default; PO has since reached out to Joe (path (b) — sanitized customer data sourcing) which is now the load-bearing path. Path (c) PS608 was eliminated (Watermark TPO does not use PowerFill). This narrative remains as the framing PSSaaS Collab + PO would use IF Joe's data-sourcing doesn't deliver in time AND PO wants to show Greg the empty-state-well-framed demo as a fallback. Otherwise it's deferred-reference-material for whenever the demo gets scheduled (which now waits on Joe). Extends the PowerFill A54 Fix Greg-Demo Readiness completion report with the post-Phase-8.5/Phase-9-close demo content shape.

One additional re-framing the Greg demo will need WHEN it happens, regardless of path (a) vs (b) data state: the chunk-#2 selection conversation in Slide 5 was originally framed as "what would you like next?" — that's the wrong framing because Watermark TPO doesn't use PowerFill (chunk #1). The right framing is "what does Watermark TPO actually use that we should do next, since chunk #1 wasn't yours?" The chunk-#1-was-PowerFill rationale itself is open with PO + worth surfacing during the demo (or pre-demo with PO) so the chunk-#2 conversation lands cleanly. This narrative document does NOT yet reflect that re-framing; will be updated when Joe's response + the demo-actually-getting-scheduled give us a forcing function for the rethink. Companion docs:

Why this exists​

The Phase 8.5 W1 close on 2026-04-20 produced an authenticated, embedded, Keycloak-protected staging surface at https://pssaas.staging.powerseller.com/app/. PO's first reaction on landing on the working Hub dashboard: "Seems fairly useless. Where do I see the good stuff?"

That's empirical fresh-eyes feedback worth taking seriously. The architectural-correctness narrative (Hub renders inline! auth boundary works! embedded SDK consumes the .NET API guest-token endpoint!) doesn't survive contact with the empty-data reality of PS_DemoData per A66 (no syn-trade arbitrage opportunities → psp_powerfillUE rebuilds user-facing tables empty by design intent). The per-report dashboards 14-20 also render 0 rows for the same A66 reason.

This document is the disciplined-craft demo narrative — what the Greg demo should be when the visual content is sparse. It's path (a) of the three Backlog #32 paths (the other two are: get a syn-trade-rich PS_DemoData snapshot via Joe + customer-data sanitization; or move to PS608 customer data with appropriate access). Path (a) is independently useful even if (b) or (c) eventually land — it forces articulation of what's actually compelling about the current state.

Strategic frame: Greg is the canonical hedging/risk domain authority + the immediate downstream consumer of the migration thesis. Per ADR-021 §Narrow Bug-Fix Carve-Out clause (d), the Greg demo is itself the consultation surface for the A54 fix + the A69 finding + the A66 expected-empty framing. The demo's job is to demonstrate craftsmanship + invite his domain expertise on the open questions, not to dazzle with screenfuls of analytical data.

Consultation routing (PO direction 2026-04-20):

  • Greg for hedging/risk domain expertise + the A66/A69 reactions + chunk #2 selection conversation
  • Rudy (junior dev currently in the PowerFill code) for technical-implementation-level consultation on A54 fix soundness + A69 hypothesis space + A66 syn-trade-population question — Rudy's been working on PowerFill most recently, higher-fidelity input than Tom for these PSSaaS-side questions; PO can raise these with Rudy at his convenience, no rush
  • Joe (IT/Infrastructure + customer migration) for the data-richness question — sanitized customer data sourcing for richer DemoData; this is the right path-(b) ask, not Tom
  • Tom (PowerBuilder veteran) is NOT the immediate consultation source for any of A54/A66/A69. Tom remains the canonical authority on Desktop App config patterns + legacy PowerBuilder code archaeology; future Phase 10+ cutover-shape conversations will route through him, but path-(b) data-richness + A66/A69 consultation route through Rudy + Joe instead

What's empirically demoable RIGHT NOW (post-Phase-8.5-W1-close, pre-data-richness-disposition)​

Live surfaces​

SurfaceURLWhat it shows
Auth-protected operator UIhttps://pssaas.staging.powerseller.com/app/Login via Keycloak (Microsoft Entra MFA), tenant identity from OIDC claim
Hub dashboard (embedded inline)/app/ Home page12+ historical PowerFill runs against PS_DemoData (3 Complete + 7 Failed + 2 Cancelled); status-coded; sortable; the canonical proof-of-life
Run-status page/app/runs/<run_id>Per-run status + step-by-step transition history + cancel button (live polling for active runs)
Per-report navigation/app/runs/<run_id>/<report-name>8 reports per run (Allocation Guide / Trade Recap / Pool Switching / Pool Candidates / Existing Disposition / Pooling Guide / Cash Trade Slotting / Kickouts); each renders an embedded Superset dashboard inline
Submit-a-run form/app/submitOperator-grade UX: scope selector, settle-window, BX price-floor, RunOptions defaults pre-filled; submits to POST /api/powerfill/run
Operator runbookhttps://pssaas.staging.powerseller.com/docs/Docusaurus surface, NOT auth-gated, hosts the spec + assumptions log + all completion reports + ADRs

Live artifacts​

  • Phase 9 first-run validation report at /docs/devlog/2026-04-20-powerfill-phase-9-first-validation-run — the auto-rendered Markdown output from the harness's first comparison run (PSSaaS API path vs direct sqlcmd path on PS_DemoData)
  • Phase 9 harness source at tools/parallel-validation/ — Python + Jinja2; runnable in WSL Ubuntu; ~10 source files
  • A54 fix scar at src/backend/PowerSeller.SaaS.Modules.PowerFill/Sql/009_CreatePoolGuideProcedure.sql lines marked -- A54 FIX (PSSaaS, 2026-04-19) — 30 LOC of surgical changes inside a 5,000+ line legacy proc with NVO line citations + ADR-021 cross-references
  • Cross-project-relays archive at /docs/agents/cross-project-relays/ — 2 entries documenting the "Writer-Time vs Reader-Time Truth Divergence" antipattern family + 4 instances + the meta-rule earning empirical receipts

Numbers worth memorizing for the demo​

  • 20+ years: age of the Desktop App PowerBuilder codebase being migrated
  • 19,801 lines: NVO source for psp_powerfillUE (the legacy proc Phase 9 validates against)
  • 5,886 lines: NVO source for psp_powerfill_conset (Phase 6b deliverable; the allocation engine)
  • 30 lines: A54 surgical fix surface (ADR-021 §Narrow Bug-Fix Carve-Out; first canonical instance)
  • 515: allocations PowerFill produces end-to-end on PS_DemoData per Complete run
  • 30 seconds: end-to-end Complete-run wall-clock time on PS_DemoData
  • 12+: historical run count visible in the Hub dashboard (3 Complete, 7 Failed, 2 Cancelled)
  • 9 phases shipped: 0 (spec) through 8 (W1 + W2 + W2 deploy + A54 fix + 8.5 ecosystem auth) + Phase 9 (parallel validation harness)
  • A1 through A70: 70 documented assumptions in the assumptions log (each is an interpretation made during reverse-engineering, citation-anchored to NVO source)

The 5-slide demo deck (suggested structure)​

Each slide is a section + a recommended live-demo action. ~25-30 minutes total.

Slide 1 — The strangler-fig migration thesis (3 min)​

Title: "Why we're rewriting PowerSeller, chunk by chunk"

Talking points:

  • PowerSeller Desktop App is a 20+ year old PowerBuilder codebase running real revenue-generating mortgage secondary-marketing for Watermark TPO (and historically others). PowerBuilder's vendor support, talent pool, and platform compatibility are all on the long, slow death curve.
  • The cost of a forklift rewrite has been the perpetual blocker — too risky, too much business logic embedded in PowerBuilder code that no one fully understands anymore, no clear migration path that doesn't bet the business on a single big-bang cutover.
  • The strategic insight: chunk-by-chunk strangler-fig migration. Each chunk is a piece of core business logic; reverse-engineered against the legacy source as the empirical ground-truth; re-implemented in modern stack (.NET 8 + EF Core + Azure SQL MI + AKS); exposed as stable API the existing Desktop App can call into.
  • PowerFill is chunk #1. Algorithmically dense (~20K lines of T-SQL across 3 procs); economically valuable (heart of "what loans go in what pool"); bounded inputs/outputs.
  • Today: PowerFill is empirically running end-to-end against real (sanitized) customer data with auth + observability + parity-validation harness. The migration model works for chunk 1 → therefore it can work for chunk 2 + 3 + N.

Live action: Open https://pssaas.staging.powerseller.com/app/ → Greg watches Keycloak SSO redirect → Microsoft Entra MFA → land back at the React UI. The auth surface is identical to what he'd expect from any modern enterprise SaaS.

Slide 2 — "Bug as Feature": the A54 fix (5 min)​

Title: "We found a 20-year-old bug while porting"

Talking points:

  • During the verbatim port of psp_powerfill_pool_guide (~3,300 lines of T-SQL), we hit a PRIMARY KEY violation on a ##cte_posting_set_1300 temp table. The bug had been latent in the legacy code for years — masked by silent failure paths in the PowerBuilder layer.
  • Diagnostic-First Rule: rather than guess + patch, we ran the failing proc with PRINT instrumentation. The hypothesis from the kickoff (multi-pa_key Switching) was wrong. Mid-run probe revealed the actual cause: trade 36177868 had 4 rows with 3 distinct settlement_dates across loans → fan-out from a JOIN qualifier missing the settlement_date predicate.
  • 30 lines of surgical fix inside the 3,300-line proc. Both fixes inside ADR-021's amended §Narrow Bug-Fix Carve-Out (precedent-setting; first canonical instance).
  • The fact that we found this bug + understood it well enough to fix it surgically is the load-bearing demonstration that the migration model isn't just "translate the code"; it's "understand the code, including its bugs, well enough to ship it correctly."

Live action: Open /docs/handoffs/powerfill-a54-fix-greg-demo-readiness in browser → walk Greg through the 5-run signature evolution table at the top + the surgical fix scar in 009_CreatePoolGuideProcedure.sql. Ask him: "Does this bug shape look familiar? Is ##cte_posting_set_1300 something you've seen failing in the Desktop App?"

Slide 3 — Operator workflow: submit a run, watch it complete (5-7 min)​

Title: "End-to-end: PSSaaS does the same thing the Desktop App does, on the same data, in 30 seconds"

Talking points:

  • The React UI exposes the operator workflow: pick a tenant DB, configure RunOptions (scope / settle-window / BX price-floor), submit. The .NET API runs the 6-step PowerFill pipeline (BX cash-grids → BX settle-and-price → candidate-builder → conset → pool_guide → UE) against the chosen tenant DB.
  • Every step's status surfaces to the UI in real-time. Failures are visible with structured error context. Cancellation works mid-run.
  • All 12 historical runs visible in the Hub are real PowerFill runs against real (sanitized) customer data: 3 Complete + 7 Failed + 2 Cancelled. The Failed ones are pre-A54-fix runs; the Complete ones are post-A54-fix.

Live action: Click "Submit a run" → leave defaults → submit → watch status transition through 5-7 states → land on Complete → click any report → embedded Superset dashboard renders inline. Then explain A66 immediately: "The reports render empty. That's not a bug; that's psp_powerfillUE's design intent on this dataset. PS_DemoData has no syn-trade arbitrage opportunities, so UE rebuilds the user-facing tables empty after every Complete run. This is a question for you, Greg — is that the correct behavior on this dataset, or is something missing?"

The empty reports become the demo asset that invites Greg's domain expertise, not a flaw to apologize for.

Slide 4 — Parity validation: the harness (5 min)​

Title: "We don't just translate. We verify."

Talking points:

  • The migration thesis is "each chunk verifiably matches legacy behavior loan-by-loan." The Phase 9 Parallel Validation Harness is the empirical lever for that claim.
  • The harness runs PowerFill via two independent paths against the same tenant DB at the same time: Path A (PSSaaS API → 6-step orchestration with C# wrapping the legacy procs); Path B (direct sqlcmd → same legacy procs called bare). Both paths against the same fixed proc body. Outputs compared loan-by-loan with verdict logic per row: Match / TolerableDiff / Divergent / Incomparable / A66-Match.
  • First end-to-end run on PS_DemoData surfaced A69 — a state-dependent UE failure path that fires only when pfill_powerfill_guide has 515 rows from a prior pool_guide step. UE in isolation against post-rebuild-empty state runs cleanly. This is exactly the class of finding the harness was built to surface — the harness earned its charter on its first run.

Live action: Open /docs/devlog/2026-04-20-powerfill-phase-9-first-validation-run → walk through the TL;DR verdict table + the A69 finding section. Ask Greg: "We have two hypotheses: PSSaaS silently swallows the same internal error and reports Complete; OR PSSaaS hits a different code path because of how C# calls the proc. Which seems more likely to you given how UE behaves in the Desktop App?"

Slide 5 — What we want from you, what comes next (5-7 min)​

Title: "We need your input on three open questions, and we want to talk about what's next"

Three open questions (in order of weight):

  1. A66 framing: is PS_DemoData representative of "typical customer data" (in which case empty post-UE reports are the norm and the demo's analytical surface needs PS608 or similar), or is PS_DemoData atypically syn-trade-poor (in which case a different historical snapshot would be richer)? Rudy may also have technical input from his recent PowerFill work; Joe is the right person for the "do we have other sanitizable customer data" sourcing question.
  2. A69 hypothesis space: PSSaaS-silently-swallows vs different-code-path. We have empirical reproduction (4 consecutive runs) + a Diagnostic-First plan for next session. Greg's domain knowledge of UE's behavior on real customer data could short-circuit the investigation.
  3. A54 fix soundness: 30-line surgical fix inside the legacy psp_powerfill_pool_guide proc. Both edits documented + cross-referenced. Per ADR-021 §Narrow Bug-Fix Carve-Out clause (d), the demo IS the consultation. Does the fix shape look right? Are there cases on PS608 that would behave differently than on PS_DemoData?

What's coming next (in priority order):

  • Chunk #2 selection conversation (Greg + PO): which Desktop App piece moves to PSSaaS next? Pipeline Management is the current top candidate; Risk Validation Module is a close second. The migration playbook from PowerFill (Phases 0-9 + 8.5) is reusable.
  • Customer-DB validation sweep: once Greg signs off on the demo + A69 has root-cause OR carve-out, the harness runs against PS608 and (eventually) other tenant DBs. Operator-driven; PSSaaS Collab + Architect on standby for issues.
  • Production cutover playbook: Phase 10 is "the Desktop App calls PSSaaS API for PowerFill instead of running PowerFill itself." Architectural plan exists; the question for Greg is the transition shape — feature flag per customer? Hard-coded per-build? Configurable via INI? Tom is the canonical authority on Desktop App config patterns.

What we're NOT asking for in this demo:

  • A commitment to anything. This is the "are we on a path you'd consider" conversation, not the "are you signing the contract" conversation.
  • Hours of Greg's time post-demo. We're scoped for ~30-45 min total. Followups happen if Greg wants them.
  • Greg's input on the React UI's UX or the Superset embedding — those are operator-workflow decisions PSSaaS owns and iterates on. Greg's input is wanted on the business logic, not the operator surface.

Live action: Show /docs/specs/powerfill-engine Phased Implementation table → Phase 9 ✓ Complete; Phase 10 = "Validation + Tom/Greg critique + cutover" (current state); Phase 11+ = chunk #2 selection. Walk Greg through which Desktop App pieces are most-extracted-next.

Demo discipline notes (PSSaaS Collab observations)​

These are notes for the PO running the demo, not slides for Greg.

Things to NOT do during the demo​

  • Don't apologize for the empty reports. Frame them as "documented expected behavior; question for you, Greg." A66 is a feature of PowerFill's design intent on this dataset, not a bug in our port.
  • Don't show the A69 hypothesis space as uncertainty about whether PSSaaS works. Frame it as "the harness caught exactly the class of finding it was built to catch — and we want your domain input on the disposition." This is craftsmanship demonstration, not failure admission.
  • Don't deep-dive on the process discipline. The cross-project-relays archive + the 7-failure runtime cutover sequence + the family-velocity-as-evidence-signal observation are real wins for OUR side, but Greg doesn't care. The audience for those is future PSSaaS Collab/Architect/Developer agents + future hires + future customer security reviewers. Mention them in passing if relevant; don't tour them.
  • Don't show the React UI's tenant picker or the OAuth2 sign-in screen lingering. Both work but neither is impressive. Get past them quickly to the operational content.
  • Don't quote internal discipline jargon ("Member 3 family", "practice #13", "ADR-021 §Narrow Bug-Fix Carve-Out") to Greg. Translate to plain English: "we have a discipline doc that flags this kind of thing"; "we have an architectural decision record that guards against scope creep on bug fixes"; etc.

Things to DO during the demo​

  • Show the legacy code reverence. The 30-line A54 fix scar inside the 3,300-line proc body is a visual artifact that shows we treated the legacy carefully. The verbatim-port discipline (ADR-021) is the right philosophical frame even if not named explicitly.
  • Invite questions early and often. Greg has decades of mortgage hedging/risk + Desktop App context. The demo's job is to elicit his input on A66 + A69 + A54 + chunk-#2-selection — every interaction is more valuable than any of our slides.
  • Use the live URL. The fact that this is on staging (not localhost; not a slide deck) reinforces that the migration model survives contact with real-shaped infrastructure. Click around freely. If something breaks during the demo, that's another data point.
  • Time-box. Stop at 30-45 min unless Greg actively wants more. Followup conversations are higher-quality than demo-extension.
  • End with the chunk-#2 question. "Which Desktop App piece moves next?" is the conversation that turns Greg from observer to design-input-provider. Even an inconclusive answer is signal.

What "success" looks like for the demo​

  • Tier 1 (minimum viable): Greg sees the auth surface, the operator workflow, the A54 fix scar, and the Phase 9 harness output. Walks away saying "I see it works; I have questions; let me think about it."
  • Tier 2 (good): Greg engages with one of the three open questions during the demo. We learn something new about A66, A69, OR A54 from his perspective.
  • Tier 3 (great): Greg names a Desktop App pain point that he'd want chunk #2 to address. We have a starting seed for the Phase 11+ chunk-selection conversation.

Don't optimize for Tier 3. Optimize for Tier 1 + invite Tier 2 + leave Tier 3 as serendipity.

Open questions for the PO (not for Greg)​

Drafted as Backlog #32 disposition aids. PO's call which path to pursue first — these are the three from session-handoff:

PathWhatPO trigger
(a) Demo with what we haveThis document. Run the demo this week.Default if (b) + (c) don't land in time
(b) Syn-trade-rich sanitized customer data snapshotJoe (IT/Infra/customer-migration) asked whether other customer data exists that can be sanitized + used as a richer DemoData sourcePO will raise with Joe; no urgency; demo waits OR runs on (a) anyway
(c) PS608 customer dataPSX Infra provisions PS608 connection string for staging API; Greg consents to live-customer-data demo; A69 risk handling on different DBBigger ask; meaningful consent question; defer until post-Greg-demo unless reaction to (a) demands it

My read (PSSaaS Collab):

  • (a) is the right baseline regardless. The demo can run this week.
  • (b) is worth raising with Joe at PO's convenience. Joe may or may not have other sanitizable customer data; cheap to ask + uncoupled from any time pressure.
  • (c) is worth deferring until post-Greg-demo. Greg's reaction to (a) shapes whether (c) is worth the consent/security/A69 work.

What this document is NOT​

Per the "what I am NOT providing" honesty list shape adopted from the PSX exchange:

  • Not a slide deck — Markdown narrative; PO turns into actual slides if helpful, OR runs the demo from this doc as outline
  • Not Tom-demo prep — Tom's the PowerBuilder veteran; he'd want to see different things (more code-deep-dive; less business-narrative). A separate Tom-demo narrative would be its own artifact when scheduled
  • Not a customer pitch — Greg's an internal stakeholder + domain authority, not a paying customer. The framing is "are we on a path you'd consider" not "would you sign"
  • Not a technical-decision artifact — ADRs + completion reports + assumption log entries hold the technical decisions. This document orchestrates them into demo-shaped narrative
  • Not a substitute for PO + Greg conversation prep — PO knows Greg better than I do; final demo content + tone is PO's call. This is the PSSaaS-Collab-side recommendation