Overview

Bookend is closing validation and boarding for commercial loans at community banks, deployed inside the bank’s own network. It sits after document generation and before boarding. It reads the executed closing package and the bank’s credit approval record (LAR), classifies every document, extracts every variable term with page and position, reconciles the terms with deterministic rules, verifies execution (signatures, initials, dates, notary blocks), stages the core boarding record and the wire request for your own maker-checker approval, and seals an append-only evidence packet per loan.

The dashboard. Every figure derives from evidence events, so it reconciles to the packets.

Where it sits

 LOS approves ──► documents generated ──► borrower signs ──►  BOOKEND  ──► core books the loan
 (approval, LAR)  (documentation system                       validate      (jXchange or a
                   or counsel)                                verify         boarding file)
                                                              board    ──► wire room sends
                                                              fund          the wire
                                                              evidence

Bookend is not a document generator, an LOS, a credit tool or a wire originator. Your documentation system or counsel still produce the documents, your LOS still approves, your core still books, and your wire room still sends.

New to Bookend? Start with the product pages:

• Why Bookend: the problem and the ten most common boarding errors.
• How it works: the five steps and a product tour.
• Capabilities and benefits
• For Jack Henry banks
• Deployment architecture and Security and compliance
• Implementation engagement: how a bank goes live.

Operating principle

The model finds. The rules judge. A human approves.

• Extraction (document classification, field location) runs in the inference container inside your network. Your own forms are taught by pointing at values on one example. There are no rules to write, and the result is data, not training.
• Judgment (does the note agree with the loan agreement?) is a versioned, deterministic rule with a documentation page. See Reconciliation rules.
• Approval is a person on the review workstation, and a second person for boarding and wires.

The containers

Service	Image	Role
app-ui	bookend/app-ui	nginx serving the React workstation; proxies /api and /mcp to api. The only published port.
api	bookend/api	ASP.NET Core minimal APIs: REST, MCP server, rules engine, Quartz jobs (pipeline stages, watch folder, nightly evidence verifier, retention, daily heartbeat).
inference	bookend/inference	Split, classify, OCR, extract and locate over HTTP; CPU only.
migrator	bookend/migrator	Applies the numbered, forward-only DDL scripts once, then exits; api waits for it.
db	postgres:16-alpine	Optional. Point DB__CONNECTION at your own Postgres 16+ or SQL Server 2019+ instead.

The demo compose adds jxchange-mock (a stand-in core), metering-mock (a stand-in metering endpoint) and mailhog (a mail catcher). See Compose reference and Deployment architecture.

System → Diagnostics. One card per container and dependency, each with a live probe.

Where things live

• Database: loans, document metadata, extracted values, findings, approvals, the evidence chain, settings (secrets encrypted with your master key), Quartz state, the audit log.
• documents volume: every uploaded file, content-addressed by SHA-256, plus rendered pages.
• exports volume: boarding files and wire requests produced by the file-export paths.
• watch volume: the watch folder for unattended intake (LOANREF/*.pdf + lar.json).

Integrate

• The REST API is described by an OpenAPI document published with every release.
• The MCP server exposes the same operations to assistants and automation, with the same tokens, permissions and audit trail.
• Core adapters: Jack Henry jXchange and file export.

Next

1. Sizing and prerequisites
2. Install
3. Onboarding wizard
4. Feed the first package: Intake