docs: publish Casca FDE NodeRoom proof package

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.

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.
+

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.
+

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.
+

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?
+

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.

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`.
+

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"
+  ]
+}