Free learning / Industry proof workbook
Financial-services operations: a business-to-code workbook
Separate provisional credit from a final outcome. Build a synthetic dispute handoff, prove its authority and retry boundaries, and prepare a receiving-owner review.
No account needed. Use your own copy for writing and keep the original as a reference.
Engineering lab library / Run locally
Turn business meaning into code evidence.
Predict ten cases, run the guarded code, then remove one meaning check and inspect the unsupported note that escapes.
Real scratch SQLite with invented cases. No model, network, patient data or bank integration. The output is an internal handoff note; this does not decide care, coverage, liability or money movement.
Start here / Python 3.11+ · Standard library
Financial-services handoff proof lab
Inspect actual SQLite notes across ten financial-services cases and a deliberately broken meaning check.
Python 3.11+ · standard library only · synthetic data
Build an internal status handoff for an invented U.S. consumer debit dispute. Begin with the visual Financial-services business 101 lesson and original video. The five-lesson Academy course adds architecture, worked examples, checks, code proof, financial reconciliation and a receiving-owner review.
You need Python 3.11 or newer, a terminal and a local folder. No bank account, API key, model or network connection is required. Estimated working time: 60–90 minutes, including review rehearsal. This exercise never moves money, decides liability or calculates legal deadlines.
1. Translate the business language
“The money is back. Is the dispute over?” Separate the accounting event from the case outcome. Temporary credit can coexist with an open investigation.
| Term | Plain meaning | Engineering consequence |
|---|---|---|
| Transaction | The referenced business event | Keep its identity separate from a case ID |
| Ledger entry | A recorded accounting change | Verify kind, amount and references |
| Dispute / error notice | A reported problem | An allegation is not a finding of fraud |
| Provisional credit | Temporary credit in the applicable investigation process | Do not label it a final outcome |
| Final credit | Credit made final through the authorized process | Require the matching case evidence |
| Reconciliation | Comparing related records and resolving differences | Missing or conflicting evidence needs an owner |
| Idempotency | One operation identity for an unchanged retry | Changed content is a conflict, not a replay |
Add case owner, product type and jurisdiction to your dictionary. Consumer debit, credit-card billing, commercial accounts and lending are different domains; do not copy a single legal timetable across them. The policy owner must validate applicability and deadline logic.
2. Specify the smallest useful workflow
Scope this assistant to a private case handoff. It reads permitted case evidence, derives supported wording, drafts a note, obtains review and writes that note once. It does not issue credit, determine fraud, close a dispute or send a customer notice.
Draw read-case → meaning check → draft → review → note writer. Show where identity is established and where each source is loaded. Customer messages and documents are input, not authority. Separate a known pending investigation from an unknown technical outcome after a timeout.
The synthetic case source says dispute_case / provisional_credit. The supported note is temporary_credit_recorded. The proposal final_credit_recorded goes beyond the evidence. An accepted review cannot create an absent final case outcome.
UNDERSTAND THE SYSTEM
Temporary credit is not a final decision
Follow a fictional U.S. consumer debit dispute. A ledger event, an investigation and a customer communication answer different questions.
See what moves and why.
Read the connections in plain English
- 01Error notice → Investigation
Preserve the customer's report without changing an allegation into a final finding.
- 02Investigation → Credit entry
The institution's authorized process may issue provisional credit during an investigation.
- 03Source records → Operations review
The handoff must reference the current case evidence.
- 04Credit entry → Operations review
The kind of credit matters; amount alone cannot establish finality.
- 05Investigation → Operations review
A final outcome must come from the authorized case process.
- 06Operations review → Status handoff
Publish only the supported internal status, once.
Check your understanding: The ledger shows a credit. Is it safe to close the dispute?
Not from that fact alone. Establish whether the credit is provisional, check the authorized case outcome and keep required investigation and communication work visible.
3. Run the proof lab
Start with the 101 lesson’s Try it stage: predict a handoff, inspect its actual saved notes, and compare the deliberately broken meaning check. The browser presents recorded observations from this same Python lab. Then reproduce them locally below.
The JSON attempts array preserves each delivery’s exact input, database before, result, and database after. For a retry, inspect attempt two rather than reusing the first delivery’s source. A review must match the exact case ID, proposed note, case revision and source revision. Add an unseen test that changes the case ID or reviewed note; verify review_content_mismatch and no new row.
Download the Python file into an exercise folder. Every scenario gets a fresh in-memory SQLite database, so the reports are reproducible and isolated from your platform account.
python3 fde-industry-proof-lab.py --domain finance --json > finance-guarded.json
python3 fde-industry-proof-lab.py --domain finance --omit-meaning-check --json > finance-broken.jsonPredict the following before opening the reports:
| Scenario | Evidence to inspect |
|---|---|
| supported | A temporary-credit note is stored |
| meaning-trap | The guarded run withholds final wording; the broken run stores it |
| missing-evidence | A model summary is not the expected case source |
| stale-review | The earlier review cannot cover a changed source revision |
| wrong-workspace | A different workspace's review is rejected |
| wrong-reviewer | The drafting agent cannot accept its own proposal |
| specialist-question | Dispute adjudication leaves this handoff flow |
| identical-retry | The second attempt adds no note |
| changed-retry | The first note remains and changed content conflicts |
| supported-final | A source that actually records final credit supports final wording |
Inspect source, proposal, outcomes and saved_notes together. Both scripts can exit successfully. Only one preserves the intended business meaning in meaning-trap. Valid JSON, accepted review and a successful SQL write do not prove that the statement is supported.
For a compact report:
python3 fde-industry-proof-lab.py --domain finance4. Change the code and design the deployment boundary
In a copy, add an unknown-state scenario using replace(base, observed_state="unrecognized") and a rejected-review scenario using replace(base, review="rejected"). Predict, run and inspect zero new notes for both. Propose how a new business state would be reviewed before adding it to the policy table.
The Packet values are trusted fixtures. A production API must load workspace, source and reviewer authority on the server; it must not accept them as claims from a model or browser. The local sequential exercise does not prove concurrent retries, source changes during a write, real ledger reconciliation or regulatory deadline behavior. Write an integration test contract for each boundary you would need.
Go deeper with the financial reconciliation lab: compare case and credit records, distinguish repeated delivery from two distinct entries, and give unresolved differences an owner.
Keep the business dictionary, diagram, guarded and broken reports, your new cases and their results. Add a receiving note that separates proven scratch behavior from the next integration milestone.
5. Rehearse the mentor and receiving-owner review
Ask a peer or facilitator to run this 20-minute review. If working alone, record self-rehearsal. The Academy lesson coach can help prepare reasoning; the worksheet does not imply a scheduled human reviewer.
- Explain why money being credited does not always mean the case is finished.
- Demonstrate the unsupported final note in the deliberately broken run.
- Let the reviewer change the source revision or retry payload. Predict the outcome.
- Explain what happens when case and ledger evidence disagree.
- Show the next receiving owner, stop condition and missing integration evidence.
Record the challenge, initial explanation, changed decision, actual evidence and unresolved work. The reviewer should be able to reproduce your proof without your narration.
Build a hypothetical value case around accepted handoffs. Include correction, reconciliation, review and operating costs. Faster drafting alone does not establish net value, and the course does not provide measured financial outcomes.
6. Sources and next practice
Original LockedIn Labs instruction, checked against these primary references on 22 October 2026:
- CFPB: unauthorized transactions and temporary credit.
- CFPB: Regulation E error-resolution procedures. Applicability, exceptions and timing need the responsible policy owner's interpretation for the actual product and circumstances.
Continue with the protected financial-services course, or compare this workflow with healthcare operations. The engineering discipline transfers; the business terminology and decision rights must be learned again.