# Timshel MVP
### Product Requirements Document
**Bail bond management for Midwest Bonding**
Version 0.2, draft for review

---

## 1. Summary

Midwest Bonding writes surety bail bonds across Minnesota's 87 counties, backed by Lexington National. A ten person office manages several hundred live bonds using roughly twenty spreadsheets, a shared Dropbox, QuickBooks, and the surety's reporting portal. Information is retyped between them constantly, deadlines are discovered rather than anticipated, and the evidence needed to win a bond back after a defendant misses court is scattered across six places.

Timshel replaces the spreadsheets with one record per bond and one shared view of the portfolio. The MVP covers lifecycle stages 1 through 7 and stage 12: lead, production, closure, surety reporting, active servicing, and resolution (exoneration). Stage 2 (bond written in the field) is unchanged. Forfeiture, recovery and petitions (stages 8–11) are Phase 2.

**The MVP is done when the nine named artifacts in the kill list are no longer used.**

---

## 2. Problem

Three problems, in order of cost.

**Nobody can see the whole portfolio.** There is no way to ask "how many live bonds do we have, and which ones need attention today" without opening several files. Julie's words during the walkthrough, when asked to find a defendant with an outstanding warrant: "if we had a database, I could type in one, but there's no way for us to know right now, which is crazy."

**One person is the bottleneck for the most important work.** Sarah spends three and a half to five hours a day moving data between the public court record and the surety system, then separately builds the reminder call list by hand, works a 35 page list of bonds with no known court date on a two week cycle, and maintains the weekly exoneration list. Four of the twelve lifecycle stages are hers.

**The record that wins petitions is not being kept.** When a defendant fails to appear, Minnesota courts decide whether to give the bond back using the Shetsky factors, which weigh what the surety did to get the defendant to court. MWB does that work every day. It just cannot prove it, because the proof lives in a dialer log, an email thread, a Word document and someone's memory.

---

## 3. Goals and success metrics

| Goal | Metric | Baseline | Target |
|---|---|---|---|
| Retire the spreadsheets | Named kill-list artifacts still in use | 9 of 9 | 0 of 9 |
| Close the visibility gap | Median hours from bond execution to record created | Unmeasured (establish in week 1) | Under 24 hours within 60 days of intake launch |
| Give Sarah her day back | Minutes per day on court date tracking and list building | 210 to 300 | Under 90 |
| Know where every bond stands | Percent of live bonds with a known next court date or an explicit no-date subtype | Unmeasured | 95% within 90 days of servicing launch |
| Account for the instrument | Powers in unaccounted state at any moment | Unmeasured | Zero for two consecutive weekly reconciliations |
| Make rework visible | Report defect rate and median time to resolve, by agent | Unmeasured | Measured weekly; median resolve under 3 business days |
| Build the evidence | Percent of live bonds with at least one logged contact per month (bonds with a hearing in that month) | Unmeasured | 80% |

Establishing unmeasured baselines in the first two weeks of each module's dual-run is itself a deliverable. Targets above are launch acceptance bars, not aspirational slogans.

---

## 4. Users

| Person | Role in Timshel | Primary surface |
|---|---|---|
| Julie, Bri | Create bond records from scanned packets | Intake review |
| Tif | Quality gate. Closes reports, releases everything downstream | Closure queue |
| Sarah | Court date tracking, reminder calls, no-date queue, exonerations | Work queue |
| Ellie | Surety export, power disbursement, replenishment | Surety and powers |
| Emma | Power entry, exoneration follow up | Surety and powers |
| Mandy | Financed premium entry, voided powers | Record, powers |
| Heidi | Physical power matching | Powers |
| Angela | Jail roster leads | Leads queue |
| Josh, Ron | Portfolio oversight | Board |
| Field agents | Read only. Their own bonds, their own commission report | Agent view |

Ten office users, roughly five of them in the system continuously. Field agents are read only in the MVP and are not asked to change how they write bonds.

---

## 5. Scope

### Stage ↔ module map

Lifecycle stages from the four-lane timeline. Stage 2 is field work; Timshel does not change how agents write bonds.

| Stage | Name | MVP module | Kill artifact | Rollout wave |
|---|---|---|---|---|
| 1 | Lead | Leads | Jail roster lead sheet | 3 |
| 2 | Bond written | — (field agents, unchanged) | — | — |
| 3 | File uploaded | Intake | Dropbox watch (integrate, not kill) | 2 |
| 4 | Record created | Intake | Microsoft intake form; form download workbook | 2 |
| 5 | Closed | Closure | Agent assignment sheet; per-agent report spreadsheets | 2 |
| 6 | Reported | Powers; Surety reporting | Hand-maintained Lexington import workbook | 1 |
| 7 | Active | Servicing; Evidence | TBD list; dialer upload list | 4 |
| 8–11 | Distress path | Phase 2 | Forfeiture and recovery sheets | — |
| 12 | Resolved | Exoneration | Exoneration list | 4 |

Cross-cutting: **Board** (wave 5), **Agent view** (ships with wave 2 data; read-only filter), **Evidence** (ships with servicing, required from first closed bond).

### In scope

1. **Leads.** Jail roster matching against current clients, lead lists to agents
2. **Intake.** Document upload watch, extraction, review and correction, case number validation, financed vs paid-in-full flag
3. **Closure.** Completeness checklist, defect loop back to the agent, closure as the trigger event
4. **Powers.** Serial register, assignment, execution, expiry, voiding, reconciliation
5. **Surety reporting.** Weekly export file, disbursement report, replenishment request, agent commission report
6. **Servicing.** Court date tracking, appearance results, no-date queue, reminder call list, call dispositions
7. **Evidence.** Notes, contact attempts, documents, all timestamped and attributed
8. **Exoneration.** Candidate detection, human confirm, weekly surety report, liability release
9. **Board.** Portfolio view, aging, alerts
10. **Agent view.** Read-only list of an agent's own bonds and a filterable commission report
11. **Financing flag.** Record financed vs paid-in-full at intake; Mandy enters premium terms on the record. No QuickBooks sync

### Out of scope for MVP

- Forfeiture processing, recovery, petitions and reinstatement (Phase 2)
- Receivables, statements, collections, conciliation court, docketing (stays in QuickBooks; **no QuickBooks integration in MVP** — no read, no write)
- Collateral tracking, mortgage recording, IRS Form 8300 (Phase 2)
- Replacing QuickBooks
- Replacing the dialer in MVP. **Feed the existing dialer first:** Timshel generates the daily upload list and retires the hand-built one. Consent is captured at intake so a later move to SMS does not require redesign. Twilio SMS is post-MVP when the dialer expires
- A mobile app
- Any change to how field agents produce bonds
- Automated retrieval from the public court record

### Explicitly built in MVP despite paying off in Phase 2

The evidence layer. Notes and contact attempts must be captured from day one, because a petition written in month nine draws on servicing work done in month two. If evidence capture ships with Phase 2, the first year of petitions has nothing to draw on.

Likewise, failure to appear **detection** is in MVP. Sarah already records appearance results in stage 7. Timshel flags the FTA and fires the notice. Everything after that notice is Phase 2.

---

## 6. Domain model

### Core entities

**`bond`** is the central record but not the primary key of the business. Fields: internal number, penal amount, execution date, county, writing agent, supervising agent, surety, premium mode (`paid_in_full` | `financed`), derived status.

**`power`** is the serialized instrument and arguably the true primary key. Fields: serial (format `2026-AA-031162`), series code, issue date, **expiry date**, assigned agent, bond (nullable), reported date, paid date, status.

Power status is a state machine: `at_surety` → `with_agent` → `executed` → `reported` → `paid` → `replenished`, with `voided` and `expired` as terminal branches. Transfer between agents is an audited reassignment that keeps status `with_agent`. Lost or stolen is voided with reason `lost_stolen`, not left hanging.

**`unaccounted` is computed, never set.** A serial is unaccounted when it has been issued to the agency and is not in one of: `with_agent` (confirmed assignment), `executed`, `voided`, `expired`, or an explicit `in_transit` holding state with an open transfer. In-transit older than a configured clock ages into unaccounted.

**`court_case`** with a validated Minnesota case number (`82-CR-26-887` decomposes to county 82, type CR, year 26, sequence 887). County and judicial district derive from the number. **A bond may exist with no case**, because bonds are written before charges are filed. That is a first-class state, not an error.

**`hearing`** links to a case. Two independent nullable booleans: `appeared` and `warrant_issued`. These must not be collapsed into one status enum. A defendant can fail to appear without a warrant issuing, and that case behaves entirely differently. Optional free-text paste-back from MCRO for the next date and disposition notes.

**`person`** is one table. Roles attach through `bond_party` with a role of defendant, indemnitor, cosigner or reference, plus an `is_payer` flag. The same person is frequently both defendant and payer, so the model must permit it without assuming it.

**Person match and merge.** Jail-roster and intake matching score on normalized name + date of birth (and DL number when present). Matches are presented with confidence; never auto-merged. A permitted role can merge two person records with an audited survivor; bonds and contacts re-point to the survivor.

**`note`** and **`contact_attempt`** form the evidence layer. Both append-only, both carrying author, timestamp and category. A contact attempt records channel, direction, outcome (answered, machine, bad number, no answer) and whether the person confirmed they would appear.

**`consent`** on `person`: channel (`voice` | `sms` | `email`), granted at, source artifact (typically the signed indemnity / intake packet), and revoked at. Reminder lists include only contacts with active consent for that channel.

**`report`** carries the closure workflow: draft, in review, defect, closed. **`defect`** records what was wrong, who raised it, which agent it went to, and when it resolved. This makes the rework loop measurable for the first time.

**`financing`** (lightweight in MVP). On a financed bond: premium amount, down payment, balance, and notes Mandy needs to enter the QuickBooks side by hand. Timshel does not invoice or collect.

**`agent`** carries the producer license expiry and SCAO approval expiry, both biennial, both of which stop the agent writing when they lapse.

### Two architectural rules

**Status is derived, never set.** No status dropdown anywhere in the product. A bond is closed because Tif closed the report. A bond is active because a report is closed and a future hearing exists. A bond is at risk because the last hearing recorded no appearance. If a person has to finish a task and then separately go tell the system they finished it, they will stop doing the second part within a month and the board will go stale. Where an override is genuinely required, it is a separate audited record with a reason, not a mutable field.

**Clocks are configuration, not code.** Every deadline lives in a versioned rules table with a trigger field, a duration, a consequence and a citation. The court can change Rule 702. The company can change its hold policy. Neither should require a deploy.

MVP clocks: report defect aging, power expiry (January 1), surety reporting cycle (weekly), no next court date (7 days), power in-transit aging, license and approval renewals (biennial). Phase 2 adds the forfeiture clocks at 90, 90 to 180, and 180 days.

---

## 7. Functional requirements

### 7.1 Leads (stage 1)

- Import county jail roster data, match names and dates of birth against live bonds and closed clients
- Produce a per agent lead list filtered to the counties that agent covers
- Match confidence indicated, never auto-asserted; user confirms before a lead is sent
- Duplicate person candidates offered for merge rather than creating a second record blindly

### 7.2 Intake (stages 3 and 4)

- Watch the Dropbox folder. A new packet creates a draft record with no action from the agent
- Extract fields from the scanned packet and prefill. Extraction is a suggestion, never an authority. Every prefilled field is visually marked as unconfirmed until a human confirms it
- Side by side review: source document on the left, fields on the right, click a field to highlight where it came from
- Validate the case number format on entry, derive county and district
- Bind the power serial to the bond, verify the serial exists and is assigned to that agent
- **Record the interval** between execution date on the power and record creation. This is the unmeasured exposure gap
- Flag paid in full versus financed; if financed, capture premium, down payment and balance for Mandy
- Capture messaging consent per person (voice and SMS), linked to the signed indemnity / packet as the source artifact

**Accepted risk:** the entire intake design assumes extraction from handwriting is good enough to correct rather than retype. Validate this on twenty real packets before committing.

### 7.3 Closure (stage 5)

- Completeness checklist derived from document type, not a static list
- Numbers cross-check: bond amount, power serial, premium and case number must agree across the packet
- Raise a defect that routes to the writing agent with a specific list, or close
- Closure is the single trigger event. It releases surety reporting, agent commission, financing entry and servicing
- Named backup for the closer role is a **launch checklist item** (process), not a product feature: written checklist + designated backup person before wave 2 goes live

### 7.4 Powers (stage 6)

- Serial register with status, assigned agent, and expiry
- Barcode or serial scan on the intake screen rather than keying
- Agent stock levels visible, with low stock and expiry warnings before January 1
- Void with a reason and a second reader (including lost/stolen)
- Transfer between agents as an audited reassignment; optional `in_transit` until the receiving agent confirms
- Reconciliation view: every serial issued, its current state, and an unaccounted count that should be zero

### 7.5 Surety reporting (stage 6)

- Generate the weekly export in the format Lexbail's importer accepts
- Disbursement report of powers consumed, driving the payment amount and the one for one replenishment request
- Agent commission report as a filter on closed bonds, not a per-agent spreadsheet
- Weekly exoneration report

### 7.6 Servicing (stage 7)

The heaviest module and the one that decides adoption.

- **Hearing check queue.** Every bond with a hearing since the last check, in one list. Two independent answers per bond, appeared and warrant issued. Keyboard driven with auto-advance
- Deep link out to the public court record, prefilled with the case number, and a paste-back field for the result (next date, disposition notes). **Assisted lookup, never automated retrieval.** The portal's terms prohibit bots, and MWB's authority to write bonds is granted and revocable statewide by the same judicial branch that runs it
- Recording no appearance fires the FTA notice to office, writing agent and supervising agent, and marks the bond at risk
- **No-date queue** split into three types: no case filed, case unscheduled, warrant outstanding. Sorted by age. Each type gets a different action
- **Reminder list** generated daily from hearings due, filtered to good numbers and contacts with active consent for the outbound channel. Export in the format the current dialer upload accepts
- Call dispositions logged back against the bond: answered, machine, bad number, and whether the person confirmed they would appear. Bad numbers flagged and removed from future lists
- Every customer conversation logged against the bond with author, date and category

**Consent acceptance criteria:** (1) voice and SMS consent fields exist on person at intake, (2) source artifact linked, (3) reminder list excludes revoked or missing consent, (4) revoke is one action and takes effect on the next generated list.

### 7.7 Exoneration (stage 12)

Exoneration is never fully automatic.

**Candidate rules** (any one queues a bond for review):

- Last hearing recorded `appeared = true` and paste-back / notes indicate case disposed, sentenced, dismissed, or otherwise concluded with no further appearance required
- Case status paste-back contains a conclusion signal Sarah already uses today (disposed, sentenced, dismissed, remanded with bond released — exact phrase list confirmed with Sarah before build)
- Manual “mark ready for exoneration” action by a permitted role

**Confirm step.** Sarah or Emma confirms each candidate. Confirm releases liability on the bond, closes the bound power, includes the bond on the next weekly surety exoneration report, and flags collateral for return (collateral workflow itself is Phase 2; MVP only sets the flag).

If MCRO and the recorded hearing disagree, the human confirmation wins; the disagreement is logged as a note.

### 7.8 Board

- Live portfolio with counts and total exposure
- Reports awaiting closure, with age
- Bonds with no next court date, by type and age
- Power expiry countdown and unaccounted count
- License and approval renewals coming due
- Financed bonds with balance noted (informational; collections stay in QuickBooks)

### 7.9 Agent view

- Read-only list of bonds where the user is writing or supervising agent
- Derived status, next hearing, power serial, county
- Commission report: filter of closed bonds for that agent in a date range, exportable. Same data Ellie sees, scoped to one agent
- No edit of office fields. Notes from agents are out of scope for MVP unless already captured via existing office process

### 7.10 Financing (MVP slice)

- Intake sets `paid_in_full` or `financed`
- On financed bonds, Mandy can enter premium, down payment, balance and a free-text note on the Record
- Closure releases the financing entry task into Mandy’s queue
- No statements, no payment plans engine, no QuickBooks write-back

---

## 8. User interface

### Principles, borrowed from Linear

**Saved views are the navigation.** There is no fixed nav tree of modules. Each person opens Timshel to their own filtered view and that view is their entire day. Sarah opens to hearings needing a result. Tif opens to reports awaiting closure. Same data, different lens.

**Command palette for everything.** One shortcut opens search across defendant name, case number and power serial, plus every action. Nobody should have to learn where a screen lives.

**Keyboard first on the queues.** This is the highest leverage decision in the product. On a hearing row: `A` appeared, `N` did not appear, `W` toggles warrant, and the cursor advances to the next row. Sarah processes hundreds of these a week. Two keystrokes per bond instead of two window switches and a retype.

**Peek, do not navigate.** Selecting a row slides in the bond detail. Escape returns to the queue with position preserved. Losing your place in a list of two hundred is the thing that makes people go back to a spreadsheet.

**Optimistic and instant.** State changes render immediately and reconcile in the background. Perceived latency under 100ms on every interaction in a queue.

**Density over whitespace.** These people scan for one number among hundreds. Information per screen matters more than breathing room.

### The surfaces

**The Record.** One bond, everything about it. Header with defendant, amount, derived status, power serial, case number, county, agent, premium mode. A three track status strip showing liability, power and premium moving independently. Next hearing with a countdown. The evidence timeline as the centerpiece: reverse chronological, filterable by category, every note and call and document and court event in one column. Financing fields when `financed`.

**The Queue.** My work today, in sections. Fast, keyboard driven, no chrome. Includes hearing check, closure, no-date, leads, and Mandy’s financed-entry queue as saved views.

**The Board.** Portfolio state, aging, alerts. Designed to live on a wall monitor.

**The Agent view.** Read-only saved view scoped to one agent’s bonds plus commission filter. Same chrome density as the Queue; no office admin actions.

### Visual language

Monospace for identifiers, because power serials, case numbers, dates and amounts are what people scan for and columns must align. One status color used consistently everywhere, with red reserved strictly for deadline danger so it keeps meaning something. Clocks shown as countdowns rather than dates. Cool and institutional rather than glossy.

---

## 9. Technical architecture

| Layer | Choice | Note |
|---|---|---|
| Framework | Next.js (App Router), React, TypeScript | Server components for list views, client for queues |
| Styling | Tailwind, shadcn/ui on Radix primitives | Accessible primitives, keyboard behavior included |
| Data | PostgreSQL | Managed. Neon, Supabase or RDS |
| ORM | Drizzle | Typed SQL, easy migrations. Prisma acceptable if the team knows it |
| Server state | TanStack Query | Optimistic updates, cache invalidation |
| Auth | Auth.js or Clerk for identity and coarse roles | Field-level ACL and reveal-audit are **application layer**, not the auth vendor |
| Files | S3 compatible with signed URLs | Never serve documents from the app server |
| Jobs | pg-boss or Inngest | Clock evaluation, Dropbox polling, digests, export generation |
| Extraction | Claude API, structured output | Human confirms every field |
| Messaging | Dialer file export in MVP; Twilio SMS later when dialer retires | Consent gated either way |
| Email | Resend | Operational notices (FTA, defect, digests) |
| Errors | Sentry | |

### Operational targets

- Queue interactions: perceived latency under 100ms
- List views (board, agent portfolio): p95 under 1s for the live-bond working set
- Signed document URLs expire within 15 minutes
- Retention and destruction schedule owned by ops, defined before wave 2 launch

### Integrations

- **Dropbox.** Poll or webhook the agent folders, create draft records. Read only
- **Lexbail.** File-based. Generate the export in the accepted format. No API is known to exist; confirm with the surety
- **QuickBooks.** **Not in MVP.** No read, no write. Phase 2
- **Dialer.** Generate the daily upload file in the format the current dialer accepts. Do not replace the dialer in MVP
- **Public court record.** Deep link out and paste back. No automated retrieval, ever
- **Jail rosters.** Per county, only where a county publishes data in a permitted form

### Security and PII

The packet contains social security numbers, dates of birth, driver's license numbers and photographed identification for both defendant and indemnitor. This is a genuine requirement, not a checklist item.

- Field level encryption for SSN, DL number and date of birth. Not just disk encryption
- Role based access at the application layer. Bookkeeping does not need a social security number to enter a payment. Default to masked, reveal on a permitted role with the reveal logged
- Append-only audit log of every read and write on sensitive fields
- Documents behind signed, expiring URLs
- Retention and destruction schedule defined before launch, with a named owner
- The signed indemnity agreement is the consent artifact for credit or records pulls and for voice/SMS outreach. Store it linked to the person so the authorization is provable

---

## 10. Migration and rollout

**Migration.** Live bonds only. Historical closed bonds stay in the spreadsheets as an archive; do not attempt to backfill years of records into a new model. Migrate open liability, power inventory, next court dates, and known person/contact rows needed for servicing. Everything else can be reconstructed from documents on demand.

Before wave 1 starts: count live bonds and powers in agent hands (open questions 7–8). That count sizes the migration script and the dual-run burden.

**Rollout.** One module at a time, each replacing specific kill-list rows, with the spreadsheet kept running in parallel for one dual-run window and then deleted.

| Wave | Module | Owners | Dual-run window | Kill on accept |
|---|---|---|---|---|
| 1 | Powers register and surety export | Ellie, Emma | One weekly surety cycle | Hand-maintained Lexington import workbook |
| 2 | Intake and closure | Julie, Bri, Tif | Five business days parallel | Intake form; form download workbook; agent assignment sheet; per-agent report spreadsheets |
| 3 | Leads | Angela | Five business days parallel | Jail roster lead sheet |
| 4 | Servicing and exoneration | Sarah, Emma | One full TBD cycle (~two weeks) | TBD list; dialer upload list; exoneration list |
| 5 | Board | Josh, Ron | None (reads production data) | — |

Agent view and financing fields ship with wave 2 (data exists after intake/closure). Evidence logging is required from the first closed bond in wave 2 and becomes mandatory workflow in wave 4.

**Deletion is the acceptance test.** A module is not accepted until every kill-list row it owns is gone.

### Kill list (definition of done)

Exact Dropbox paths and filenames to be filled from Julie’s inventory before wave 1. Disposition is authoritative; names may be refined.

| # | Artifact | Owner today | Replacing module | Wave |
|---|---|---|---|---|
| 1 | Microsoft intake form | Julie, Bri | Intake | 2 |
| 2 | Form download workbook | Julie, Bri | Intake | 2 |
| 3 | Per-agent report spreadsheets | Julie, Bri | Closure / commission report | 2 |
| 4 | Agent assignment sheet | Julie, Bri | Closure workflow state | 2 |
| 5 | Hand-maintained Lexington import workbook | Ellie | Surety reporting (generated export) | 1 |
| 6 | TBD / no-date list (~35 pages) | Sarah | Servicing no-date queue | 4 |
| 7 | Exoneration list | Sarah, Ellie | Exoneration report | 4 |
| 8 | Dialer upload list | Sarah | Servicing reminder export | 4 |
| 9 | Jail roster lead sheet | Angela | Leads | 3 |

Phase 2 kill list (not MVP): master forfeiture spreadsheet, case tracking spreadsheet, cash collateral table, mortgage collateral table, large cash / 8300 table.

---

## 11. Open questions

**Blocking**

1. What is the consent order, who issued it, and what does it require? It constrains report closure and collections routing
2. What format does Lexbail's importer accept, and does it accept exonerations and reinstatements or only new powers?
3. Does extraction from scanned handwriting meet the accuracy bar? Test on twenty real packets before building intake
4. What does the power series code mean, and how are large bond authorization limits set?
5. What exact MCRO disposition phrases should queue an exoneration candidate? Confirm with Sarah
6. What file format does the current dialer upload require?

**Non-blocking but valuable**

7. Does MWB qualify for the judicial branch bulk data extract, and at what cost? Weekly refresh is useless for daily hearing checks but would transform the no-date queue
8. Which county jail rosters publish data in a form we may consume?
9. How many powers are in agent hands right now, and what is the annual expiry loss?
10. What is the real interval between bond execution and record creation?
11. How many live bonds exist today (migration sizing)?

---

## 12. Risks

| Risk | Impact | Mitigation |
|---|---|---|
| Extraction accuracy below the bar | Intake redesign, retyping persists | Test on 20 packets before build |
| Status becomes a manual field | Board goes stale, staff revert to spreadsheets | No status dropdown in the product. Derive everything |
| Scope creeps into Phase 2 | Nothing ships | Definition of done is the kill list, not a feature list |
| One person still gates closure | Bottleneck survives the rewrite | Named backup and a written checklist before wave 2 launch |
| PII exposure | Serious, and the current process is already exposed | Field encryption, app-layer field ACL, audit log from day one |
| Court rule change | Clocks wrong | Rules as versioned configuration with citations |
| Dialer expires before SMS is ready | Reminder channel breaks | Consent model ships in MVP; Twilio path designed but not required to launch |
| Bail reform legislation | Existential to the commercial model | Out of our control. Revisit each legislative session |

---

## 13. Appendix

### Launch checklist (process, not product)

- [ ] Named backup closer designated and trained
- [ ] Written closure checklist agreed with Tif
- [ ] Kill-list filenames and paths filled from Julie’s inventory
- [ ] Retention and destruction schedule signed off (named owner)
- [ ] Live bond and power-in-hand counts recorded
- [ ] Dialer upload format confirmed
- [ ] Twenty-packet extraction test passed

### Companion documents

- **[Glossary](glossary.html).** Every term the business uses, including where staff usage differs from the correct term
- **[Bond lifecycle map v2](lifecyclemap.html).** Three tracks, five phases, full clock register
- **[Four lane timeline](swimlanes.html).** Twelve stages across status, people, process and tools
- **[Phase 1 flowchart](map.html).** MVP scope in the company's own diagram style