diff --git a/docs/architecture/SMB_LENDING_REMAINING_CHECKLIST.md b/docs/architecture/SMB_LENDING_REMAINING_CHECKLIST.md index ae236359..2bc12c1e 100644 --- a/docs/architecture/SMB_LENDING_REMAINING_CHECKLIST.md +++ b/docs/architecture/SMB_LENDING_REMAINING_CHECKLIST.md @@ -82,8 +82,14 @@ Production receipt: `docs/release/SMB_LENDING_PRODUCTION_PROOF_2026-07-21.md`. ## Casca-facing evidence package -- [ ] Write a clean-room case study that clearly disclaims Casca affiliation. -- [ ] Separate bank-specific configuration, reusable platform capability, and remaining platform gaps. -- [ ] Produce an editable proof deck and short walkthrough from the same receipts. -- [ ] Verify every claim against the exact release commit and proof bundle. +- [x] Write a clean-room case study that clearly disclaims Casca affiliation. +- [x] Separate bank-specific configuration, reusable platform capability, and remaining platform gaps. +- [x] Produce an editable proof deck and short walkthrough from the same receipts. +- [x] Verify every claim against the exact release commit and proof bundle. - [ ] Publish only after the production journey passes; describe earlier output as a prototype. + +The checked-in evidence package is under `docs/release/casca-fde/`. It includes the +case study, public claims ledger, editable nine-slide deck, rendered montage, a +45-second MP4 walkthrough, and a narration script. Public distribution remains a +separate consequential action so platform-specific copy and links can be reviewed at +the exact hashes being published. diff --git a/docs/release/casca-fde/APPLICATION_NOTE.md b/docs/release/casca-fde/APPLICATION_NOTE.md new file mode 100644 index 00000000..0b972a86 --- /dev/null +++ b/docs/release/casca-fde/APPLICATION_NOTE.md @@ -0,0 +1,40 @@ +# Casca FDE application note + +Casca's current Forward Deployed Engineer role describes a roughly 70% building and +shipping / 30% embedded-customer split. The role centers on living in bank workflows, +turning that understanding into production software, owning the lifecycle, and feeding +field learning back into the platform. Source: +https://jobs.ashbyhq.com/casca/577560f5-e509-4ffe-9ff0-cbf71b64e954 + +## Paste-ready note + +I am a former JPMorgan commercial credit analyst and healthcare, life-science, and +startup banker who became the AI product engineer building the systems I needed as an +operator. + +Casca's Forward Deployed Engineer role is compelling because it joins those two halves +directly: embed with underwriters, lenders, and operators; reconstruct the real workflow; +ship production software; and turn field discoveries into reusable platform capability. + +To demonstrate that loop, I built an independent, synthetic SMB Lending Deployment Room +inside NodeRoom. The production workflow uses version-pinned proposals, two explicit +human approvals, source and digest lineage, CAS-protected application state, a +decision-free human-review packet, and export/reopen proof. It does not make a credit +decision. + +The most useful result came from the first production attempt: the page and deployments +looked healthy, but the served frontend and reviewed backend were bound to different +Convex targets. The browser journey exposed the split. I corrected the production +binding, redeployed the exact clean commit, and repeated the workflow through verified +evidence, packet regeneration, export, reopen, and reload persistence. + +That is the kind of work I want to do at Casca: enter one bank deeply, focus on the +highest-value operational bottleneck, ship the bounded solution, and bring the proven +primitive and the real failure modes back into the platform. + +Proof package: `docs/release/casca-fde/` + +Live product: https://noderoom.live + +Independent project; not affiliated with or endorsed by Casca. Synthetic data only. + diff --git a/docs/release/casca-fde/CASE_STUDY.md b/docs/release/casca-fde/CASE_STUDY.md new file mode 100644 index 00000000..d4f2963f --- /dev/null +++ b/docs/release/casca-fde/CASE_STUDY.md @@ -0,0 +1,149 @@ +# Building the deployment room I would have wanted as a banker + +## Executive summary + +This project tests the core Forward Deployed Engineer loop on a synthetic small-business +lending workflow: + +```text +enter the operator's world +→ reconstruct actors, documents, dependencies, and authority +→ ship one governed workflow inside the product +→ exercise it in production +→ turn failures and customer-specific logic into platform learning +``` + +The result is the **SMB Lending Deployment Room**, a native NodeRoom template. It is not +a separate loan-origination product and does not make a credit decision. It creates a +collaborative room containing the synthetic application, evidence checklist, process +graph, underwriting workbook, application notebook, proposal review, proof receipt, +and human-review credit packet. + +## Why this problem fits my background + +At JPMorgan Chase I worked in commercial credit, healthcare and life-science banking, +and startup banking. That context taught me that the operational problem is not simply +"upload files and ask a model." A credit file depends on document state, missing +information, source lineage, calculations, exceptions, handoffs, and explicit decision +authority. + +This implementation uses only generalized workflow knowledge and synthetic data. It +does not use JPMorgan customer data, internal policies, documents, or screenshots, and +it does not represent prior SBA underwriting experience. + +## What was built + +NodeRoom remains the product and source of truth. The lending vertical adds domain +fixtures, document requirements, deterministic blocker and critical-path logic, +financial calculations, validators, and packet renderers. All durable changes pass +through NodeRoom's existing proposal, human decision, version/CAS, artifact, and receipt +spine. + +The production transaction is: + +1. Create an authenticated room containing eight canonical binder artifacts and the + first version-pinned proposal. +2. Approve the document-request proposal. +3. Apply `missing → requested` through the canonical CAS path and create the sequential + evidence-verification proposal. +4. Approve evidence containing a source identifier, locator, and immutable digest. +5. Apply `requested → verified` and atomically regenerate the proposal review, proof + receipt, decision-free human-review packet, and export bundle. +6. Export and independently reopen both the application and packet hashes. +7. Reload the room and recover the same verified state and receipt. + +## Production proof + +The exact reviewed implementation merged in PR #238 at +`631c53089a1bd3dc8354e21b20b31bfa880f5020`. The final clean-tree Vercel deployment was +`dpl_4mnkzEvigrAZLcu2brhmc1KS3gaj`, backed by Convex deployment +`zealous-goshawk-766`. + +The production browser journey passed with: + +- application version `3`; +- application hash + `6cf83646c22f4dae8cb922d5aa222f0c3fa33b58786f5078cb77eff76953306d`; +- packet hash + `59cdd91e4b4b2f71a6ff984c0b108f2317b50ef2dd5dc2aefc645e3260db44dc`; +- proposal reviewed `true`; +- base versions matched `true`; +- source lineage present `true`; +- no credit decision `true`. + +The full release gate passed: zero audit vulnerabilities, both TypeScript targets, +370 test files / 2,563 tests, browser tests, the production build, and all 313 Convex +exports live. + +## The defect the proof run found + +The first production browser attempt stalled even though the page and deployments looked +healthy. The served Vercel frontend had been compiled against a fallback Convex target +while the reviewed functions were deployed elsewhere. HTTP health checks did not expose +the split. + +The production environment was corrected, the exact clean commit was redeployed, and the +served runtime bundle was inspected before the browser journey was repeated. The same +workflow then passed and persisted after reload. + +That failure is an FDE result, not an embarrassment: a deployment is not complete until +the user-visible workflow proves the exact frontend/backend binding. + +## Benchmark result + +The locked four-mode benchmark ran manual, chat-only, graph-agent, and +memory-enhanced variants. All ten runs passed the dimensional evaluator. Each +model-backed mode ran three times. Required-document recall, blocker recall, +critical-path exactness, authority-boundary exactness, and source-lineage coverage were +all `1.0`; false-requirement rate was `0.0`. + +Mean recorded runtime was: + +| Mode | Runs | Mean runtime | +|---|---:|---:| +| Manual fixture baseline | 1 | 0 ms | +| Chat-only | 3 | 3,328 ms | +| Graph agent | 3 | 7,009 ms | +| Memory-enhanced | 3 | 8,367 ms | + +The provider response did not include billed cost, so cost is recorded as `n/a` rather +than estimated. The result is not a universal winner claim; it proves that all four +modes satisfied the locked contract on these fixtures. + +## Customer-specific configuration versus platform capability + +| Bank-specific configuration | Reusable platform capability | Remaining platform gap | +|---|---|---| +| Document checklist | Version-pinned proposals and CAS | Actual-byte browser upload | +| Product stages | Evidence identifiers, locators, and digests | Optional Neo4j read projection | +| Policy and exception rules | Human authority and approval history | External bank connectors | +| Integration mapping | Decision-free packets and proof receipts | More held-out products | +| Bank UI language | Export, reopen, and tamper checks | Institution-specific deployment proof | + +The promotion rule is conservative: customer-specific behavior becomes a core primitive +only after it survives the real product path and produces a portable receipt. + +## Why this is relevant to a Casca FDE role + +The project combines three capabilities: + +1. **Operator fluency:** understand the banker, applicant, analyst, underwriter, and + approver handoffs without collapsing them into a chat interaction. +2. **Production ownership:** implement the workflow inside the canonical product, + deploy the reviewed code, and verify it through the rendered user path. +3. **Platform feedback:** separate one bank's configuration from reusable primitives + and preserve the failure as a future release invariant. + +The concise pitch is: **former JPMorgan banker and credit analyst turned AI product +engineer, building the systems I previously needed as a user.** + +## Limitations and next tests + +- The fixtures are synthetic and the workflow does not make a lending decision. +- The production-certified template supplies synthetic evidence through a governed + proposal. A separate browser test with actual uploaded fixture bytes remains open. +- Neo4j/Aura has not been added. If used, it should remain a bounded, tenant-scoped read + projection whose failure cannot corrupt or block NodeRoom. +- No external bank core, KYB, credit bureau, or document-provider connector is claimed. +- This work does not imply affiliation with or endorsement by Casca or JPMorgan Chase. + diff --git a/docs/release/casca-fde/CLAIMS.md b/docs/release/casca-fde/CLAIMS.md new file mode 100644 index 00000000..4584aa1f --- /dev/null +++ b/docs/release/casca-fde/CLAIMS.md @@ -0,0 +1,22 @@ +# Casca FDE public claims ledger + +| Claim | Status | Evidence | +|---|---|---| +| The SMB lending workflow lives inside NodeRoom | Proven | PR #238 and native `#smb-lending` route | +| A fresh authenticated production room was created | Proven | Production proof receipt dated 2026-07-21 | +| Two sequential proposals were human-approved | Proven | Production browser journey and NodeProof receipt | +| Evidence lineage includes an immutable digest | Proven | `src-bank-statements-q2` receipt fields | +| Exported application and packet hashes reopened | Proven | Application and packet hashes in the production receipt | +| State persisted across reload and frontend replacement | Proven | Production proof journey steps 9–10 | +| The workflow makes no credit decision | Proven | Validator and NodeProof field `noCreditDecision: true` | +| Ten locked benchmark runs passed | Proven | `docs/eval/smb-lending/20260721-four-mode/benchmark-receipt.json` | +| Actual fixture bytes were uploaded through production Chrome | Not yet proven | Open checklist item | +| Neo4j is live in this vertical | Not implemented | Optional future read projection only | +| NodeRoom integrates with bank cores / bureaus / KYB providers | Not implemented | Future connector work | +| This is a Casca product or partnership | Prohibited | Independent project; no affiliation | +| This reproduces Casca's proprietary system | Prohibited | Clean-room workflow based on public role context and synthetic data | +| JPMorgan customer or internal data was used | Prohibited | Synthetic data only | +| The benchmark proves a universally superior mode | Prohibited | Dimensional evaluator, no winner claim | + +Public copy must preserve these boundaries and link to the production receipt. + diff --git a/docs/release/casca-fde/LINKEDIN_DRAFT.md b/docs/release/casca-fde/LINKEDIN_DRAFT.md new file mode 100644 index 00000000..cafdf98a --- /dev/null +++ b/docs/release/casca-fde/LINKEDIN_DRAFT.md @@ -0,0 +1,42 @@ +# LinkedIn build-in-public draft + +I built the deployment room I would have wanted as a banker. + +Before becoming an AI product engineer, I worked in JPMorgan commercial credit, +healthcare and life-science banking, and startup banking. The workflow was never just +"upload documents and get an answer." It was document state, missing evidence, +calculations, exceptions, handoffs, human authority, and whether the final packet could +survive review. + +So I built a synthetic SMB Lending Deployment Room inside NodeRoom as an independent +proof of work for a forward-deployed engineering role. + +The production journey now proves: + +- two sequential, version-pinned proposals; +- explicit human approval at both material transitions; +- source identifiers, locators, and immutable digests; +- CAS-protected application state; +- a decision-free human-review packet; +- export and independent reopen of both output hashes; +- the same receipt after reload. + +The best part: the first production run failed. + +The page looked healthy, but the served frontend and reviewed backend were bound to +different deployments. Browser proof caught what health checks missed. I corrected the +binding, redeployed the exact clean commit, and reran the user journey to PASS. + +That is the FDE flywheel I care about: + +live in the workflow → ship the bounded solution → prove the user path → feed the real +failure and the reusable primitive back into the platform. + +The editable deck, 45-second walkthrough, claims ledger, benchmark receipts, and open +limitations are in the public proof package. + +Independent project; synthetic data only; not affiliated with or endorsed by Casca. + +What would you test next: actual-byte document upload, a bank connector, or a bounded +Neo4j read projection? + diff --git a/docs/release/casca-fde/README.md b/docs/release/casca-fde/README.md new file mode 100644 index 00000000..b3373106 --- /dev/null +++ b/docs/release/casca-fde/README.md @@ -0,0 +1,30 @@ +# Casca FDE independent proof package + +This is a clean-room, independent proof of work for Casca's Forward Deployed +Engineer role. It is not affiliated with, endorsed by, or built from proprietary +Casca materials. The lending fixtures are synthetic. No JPMorgan customer data, +internal policies, documents, or screenshots were used. + +## Package + +- `CASE_STUDY.md` — the deployment story, production evidence, and platform learning. +- `CLAIMS.md` — claim-by-claim evidence ledger and prohibited overstatements. +- `APPLICATION_NOTE.md` — a role-aligned, paste-ready application note. +- `LINKEDIN_DRAFT.md` — public build-in-public copy, held until exact links exist. +- `casca-fde-noderoom-production-proof.pptx` — editable nine-slide proof deck. +- `casca-fde-noderoom-walkthrough.mp4` — 45-second silent visual walkthrough. +- `WALKTHROUGH_SCRIPT.md` — narration and shot timing for a voiced recording. +- `assets/deck-montage.png` — rendered deck overview. +- `package-proof.json` — hashes, source commits, media checks, and open boundaries. + +The authoritative product receipt is +`docs/release/SMB_LENDING_PRODUCTION_PROOF_2026-07-21.md`. The live application is +https://noderoom.live. + +## Honest boundary + +The native template lifecycle is production-certified: create a fresh room, approve +two sequential proposals, preserve source lineage, regenerate the packet and receipt, +export and reopen the bundle, and recover the same state after reload. A separate test +with actual uploaded fixture bytes remains open. Neo4j is an optional future read +projection; NodeRoom remains canonical. diff --git a/docs/release/casca-fde/WALKTHROUGH_SCRIPT.md b/docs/release/casca-fde/WALKTHROUGH_SCRIPT.md new file mode 100644 index 00000000..873f173f --- /dev/null +++ b/docs/release/casca-fde/WALKTHROUGH_SCRIPT.md @@ -0,0 +1,19 @@ +# 45-second walkthrough script + +The checked-in MP4 is a silent, five-seconds-per-slide proof walkthrough. This script +supports a voiced rerecording without changing the factual claims. + +| Time | Slide | Narration | +|---:|---|---| +| 0:00–0:05 | Cover | I built the deployment room I would have wanted as a banker: a governed SMB lending workflow inside NodeRoom. | +| 0:05–0:10 | Operating problem | The hard part is reconstructing document state, dependencies, authority, and proof—not adding a chatbot. | +| 0:10–0:15 | Architecture | NodeRoom stays canonical. The lending pack supplies domain logic, and every durable change uses the same governed transaction. | +| 0:15–0:20 | Product proof | In the browser, two approvals moved the synthetic application from missing to requested to verified, then reopened both output hashes. | +| 0:20–0:25 | Authority | The agent proposes and validates. Human credit authority remains explicit at both material transitions. | +| 0:25–0:30 | Defect | The first production run exposed a frontend/backend deployment split that health checks missed. We fixed the binding and redeployed the exact clean commit. | +| 0:30–0:35 | Benchmark | Ten locked runs passed across manual, chat-only, graph, and memory-enhanced modes. This is a dimensional result, not a universal winner claim. | +| 0:35–0:40 | Platform learning | The deployment separates bank-specific configuration from reusable proposal, evidence, packet, and proof primitives. | +| 0:40–0:45 | Close | That is the FDE loop: live the workflow, build the system, close the production loop, and feed the learning back into the platform. | + +End card: `Independent project · noderoom.live · source and proof available`. + diff --git a/docs/release/casca-fde/assets/deck-montage.png b/docs/release/casca-fde/assets/deck-montage.png new file mode 100644 index 00000000..1e2cd8c1 Binary files /dev/null and b/docs/release/casca-fde/assets/deck-montage.png differ diff --git a/docs/release/casca-fde/casca-fde-noderoom-production-proof.pptx b/docs/release/casca-fde/casca-fde-noderoom-production-proof.pptx new file mode 100644 index 00000000..5dc4cba3 Binary files /dev/null and b/docs/release/casca-fde/casca-fde-noderoom-production-proof.pptx differ diff --git a/docs/release/casca-fde/casca-fde-noderoom-walkthrough.mp4 b/docs/release/casca-fde/casca-fde-noderoom-walkthrough.mp4 new file mode 100644 index 00000000..4c9ef2e7 Binary files /dev/null and b/docs/release/casca-fde/casca-fde-noderoom-walkthrough.mp4 differ diff --git a/docs/release/casca-fde/package-proof.json b/docs/release/casca-fde/package-proof.json new file mode 100644 index 00000000..b0e4431b --- /dev/null +++ b/docs/release/casca-fde/package-proof.json @@ -0,0 +1,40 @@ +{ + "schemaVersion": "noderoom.casca-fde-package-proof.v1", + "generatedAt": "2026-07-21T11:20:00Z", + "independentProject": true, + "cascaAffiliation": false, + "syntheticDataOnly": true, + "sourceImplementationCommit": "631c53089a1bd3dc8354e21b20b31bfa880f5020", + "sourceProductionProofMerge": "73b1090f088ce29bebff587391c798b1e38b3193", + "productionUrl": "https://noderoom.live", + "artifacts": [ + { + "path": "casca-fde-noderoom-production-proof.pptx", + "sha256": "c445ddfddae22f1dfdfbd8849e70e4b5e06059cc660116f89042de63099c0a1d", + "verification": "slides_test.py passed with no overflow; all nine rendered slides inspected" + }, + { + "path": "casca-fde-noderoom-walkthrough.mp4", + "sha256": "7c55ea6dd03799c08a6700319fbda69f44149528f2af73e4e53b9fd1b3bf089e", + "verification": "H.264, 1280x720, yuv420p, 30 fps, 44.97 seconds; frames inspected at 2, 22, and 42 seconds" + }, + { + "path": "CASE_STUDY.md", + "sha256": "4811196c100b49f3b218673acf86a8ae615cfc545013e659602ae69fa25ab0b6" + }, + { + "path": "CLAIMS.md", + "sha256": "7f586405ad213d8c53aa303d2a5eb7214800cc0e923899bfa226ea30023f3853" + }, + { + "path": "assets/deck-montage.png", + "sha256": "be378d89cd6873f8740e6e90773df37bfd34256d5ad866abf9f3d61fc56c7e7f" + } + ], + "openBoundaries": [ + "actual-byte production browser upload", + "optional tenant-scoped Neo4j read projection", + "external bank connectors", + "public distribution of this exact package" + ] +}