SHEPHERD · CREDITSBA packaging

For the SBA packager whose name is on the Form 159 — every figure computed under a floor that re-derives from the SOP itself, every judgment disclosed as yours, signed, and re-checkable by the lender without an account.

Not underwriting software. The defensible packaging file — the one your name is actually on.

01 · The disagreement a blended spreadsheet misses

Two SBA tests, computed independently. They don't always agree.

representative test case, not a live client file

SBA SOP 50 10 8 requires two separate debt-service coverage tests on a 7(a) deal — a business-only test and a global (business + guarantor) test — and forbids blending them into one number. Run the same deal shape through Credit's real engine and the two tests genuinely disagree:

Business net income: $70,000/yr
Business debt service (existing equipment loan): $88,000/yr
Guarantor net cash flow: $50,000/yr  ·  guarantor debt service: $10,000/yr
Business-only DSCR
1.0500x
SBA floor: 1.15x
FAILS
Global DSCR (business + guarantor)
1.4091x
SBA floor: 1:1
PASSES

A blended spreadsheet averages these into a single passing number and gets the deal wrong. The SBA's own SOP forbids blending the two tests — Credit computes and discloses both, independently, every time, never averaged.

02 · The floor re-derives from the regulation, not a hardcoded number

The 1.15x / 1:1 floors above aren't typed in. They're read out of a pinned, hash-verified excerpt of the actual SBA document.

“The Applicant’s debt service coverage ratio (OCF/DS) must be equal to or greater than 1.15 on a historical and/or projected cash flow basis and 1:1 on a global basis.”
Document: SBA SOP 50 10 8 — Lender and Development Company Loan Programs
Authority: U.S. Small Business Administration
Locator: SOP 50 10 8 v8 (eff. 6/1/2025) — 7(a) loan section, “Underwriting Standard 7(a) Loans” > “Lender’s Credit Analysis”
Captured: 2026-08-21
SHA-256 of the captured document:
bf5cae038c3baeab115daee1ecd0151510426cd13d8dcbf13095fbf70fb17ac1

If the SOP is re-issued and the floor changes, the pin's hash breaks and the number stops being trusted until it's re-captured — the constant doesn't quietly drift out of sync with the regulation it claims to cite.

03 · The mint refuses without a real signer credential

Sign-off is a non-delegable human gate — bound to a credential, not a self-typed name.

Reproduced live against a running dev instance of this engine, on the representative deal above.

underwrite→ broker reviews add-backs→ mint requires signoff.signerId + signoff.signerToken

Attempt with an invalid signer credential:

POST /mint/:token  {"deal": {…}, "signoff": {"name": "Brad Kiefer", "signerId": "brad-kiefer", "signerToken": "totally-wrong-token"}}

{"status":"REFUSED","code":"bad-signer-token",
 "reason":"the presented signerToken did not verify for signerId
 \"brad-kiefer\" — either it's wrong, or no signer credential has
 ever been provisioned (see register_signer). The sign-off is the
 non-delegable human gate (Gate 7) and must now be bound to a real
 credential the signer alone holds, never just a self-typed name."}

With a real, provisioned credential, the same deal mints:

{"status":"OK","serial":"SHC-2026-08-25-624c00dcaada",
 "scopeLine":"these figures are arithmetically consistent under the
 inputs provided and the add-backs the broker selected — NOT a
 credit decision, an approval, or a statement the underlying
 numbers are audited or true"}

The serial is real output from a live mint against the representative deal above — not an invented example. Any lender can independently re-verify a minted Hallmark (GET /verify/:token/:serial or by presenting the VC directly), issuer-pinned, without an account.

04 · Data custody

Nothing about a specific deal is ever written to disk, at any point, by this product.

  • The ledger that stores figures and refusals (createLedger()) is a plain in-memory array. There is no code path from a deal to a file — no ledgerFile option exists to pass one.
  • The Hallmark's input-provenance mechanism hashes each intake section (sha256 over canonicalized JSON) and stores only the hash. The raw business, personal, and collateral figures a broker types in never leave that property.
  • A receipt — including the borrower's name and the computed figures — lives only as long as the server process stays up. A restart clears everything.
  • The one thing genuinely written to disk is the product's own signing key, a cryptographic secret, not client data — file-mode 0600, outside the repo.