Ainsworth Program — Roadmap

⚠ Action items requiring Mark (not coding)

• Set the MPA signers, then reassign the live merchant's inspection signature (2026-10-05, and the newest item on this list — three admin-page actions, minutes each). The inspection-signer rule shipped on 10-05 with its lists empty, so until they are filled a TRX / iBill send for a merchant with no sourcing agent is refused by design. In order: (1) Settings → MPA signers — tick Mark and Jeff, default Mark; (2) each partner's page → MPA signer, PayByCard first; (3) on the merchant whose application has been waiting on the wrong Ainsworth inspector since 09-30, press Reassign and hand the signature to the partner's signer or to Mark — if Dropbox Sign refuses to swap a signer on a half-signed request, cancel and re-send, and the merchant signs again. That third step is also the first live proof of Reassign, and of whether the swap is allowed at all.
• Decide how to handle Dropbox Sign's asynchronous cancel (2026-10-02, a decision once the probe result is in). A success answer from Dropbox Sign's cancel call is not proof the earlier request is dead, yet the portal closes the old request and sends its replacement at once — a short window with two live forms, in both the MPA and Add Location lanes. Pre-existing; Mark accepted it for the 10-02 ship. Designing a "cancellation pending" step needs two facts from a cancel probe (what a status lookup returns for a cancelled request, and how fast the cancel event arrives). The probe and the live check were scheduled for 19:45 ET on 10-02; no result is recorded as of 10-03.
• Decide whether to rotate the Dropbox Sign API key (2026-10-01, a judgment call plus a few minutes). Until the 10-01 hotfix, a logged Dropbox Sign error could write the API key into the hosting provider's runtime logs. The code path is closed, but whether the key actually reached the logs was not checked — the build session had no log access. If Mark rotates: set the new key in the production environment and redeploy (the webhook's event hash is keyed on the same key), then update the local copies. Entering the key is Mark's to do.
• Convert one live merchant's hand-uploaded signed application through the wet-sign lane (2026-09-30, a few minutes on the admin page). The signed-application checklist item is now filled only by an executed MPA. One live merchant had a signed copy uploaded by its partner as an ordinary document, with no executed MPA behind it, so its checklist now reads not started for that item. Download the partner's file, then use Upload wet-signed MPA on the merchant's admin page and confirm — the confirm files it and retires the manual copy. The merchant is named in PROJECT_STATE's "I.1 system-filled" section.
• Get the privacy policy reviewed, and confirm the contact mailbox on it is actually watched (2026-09-19, and the newest item on this list — now that the portal points at the policy, both halves matter more than they did). The text live on the marketing site is draft v0.1 with no counsel review, and as of 09-19 the portal's sign-in and signup pages name it as the governing description of how merchant information is handled. The second half is smaller but sharper: the policy gives info@ as the address a person writes to about their own data, and whether anyone monitors that mailbox is unconfirmed — a published privacy contact that nobody reads is worse than none. Jeff holds the draft. No mailing address is shown either, which some jurisdictions expect.
• Send the approved Canadian intake forms back to Fiserv Canada — and say which Canadian merchant they are for (2026-09-10, and unchanged in substance by the 09-11 build). The forms were reviewed and approved on first read with one addition, which has been made, so nothing engineering-side is outstanding: v0.3 now exists in English and French, with Fiserv's own logo on it at Fiserv's request. What holds the lane is the reply. Three things travel with it — how filled forms should come back (the PDF, their spreadsheet, or both), the process questions that are still open (a secure channel for bank details, which entity's mailbox sends a form branded Ainsworth on a QuickRefund thread, and the acknowledgement wording — French for Quebec is now built, and wants a native proofread before any merchant sees it), and the question underneath all of them: who the Canadian client actually is. Fiserv Canada asked on 09-09 whether the merchant still needed boarding, which means the relationship is warm and waiting on us, and a warm referral lane with no named merchant behind it goes cold on its own.
• Set the managed-crawler key in production — screening cannot read bot-walled sites without it (2026-09-06, and the newest item on this list — one environment variable). The screening tool falls back to a managed browser when a merchant's site sits behind a bot wall, and the production key for it is empty. The note written at batch 1 saying production already had one was wrong, and was corrected by checking the deployed environment directly rather than trusting the note. The blast radius is narrow but real: a protected site returns "couldn't fetch the homepage" instead of a verdict, so those merchants cannot be screened in production at all — and the sites most likely to be protected are the large, sophisticated ones. Nothing else is affected; ordinary sites crawl normally. Mark's part: add the key to the production environment.
• Decide the thin-crawl question the adversarial reviewer disputes (2026-09-06, a judgment call, not a task). When a screen only manages to read part of a site, the engine still reports "this required thing is missing" for checks whose trigger it did see, and floors the verdict at flag to say the coverage was thin. The reviewer argues that is unfair to a merchant whose evidence sat on a page nobody could fetch; the counter-argument, and the reason it shipped this way, is that a silent pass on an unread page is worse than a flag a human can clear in a minute. It is unchanged pending Mark's call, and it only matters when a crawl comes back thin — which the crawler key above will make rarer.
• Refill the Codex credits so the pharmacy rules finish their last adversarial round — CLOSED 2026-09-06 (opened 09-05, closed the next day). The credits were refilled, the owed post-merge pass ran against batch 1 before batch 2 merged, and all six defects it reproduced were fixed — including the false stops that prompted the item. The rules then took thirteen more adversarial rounds during batch 2, ending in an approve. Original entry: the first vertical went live on 09-05 after six adversarial rounds, all findings fixed; the seventh round started and died mid-run because the review workspace ran out of credits. Its interim note claimed three page layouts where the engine wrongly stops a merchant, and one place where it wrongly stays quiet; the quiet one was already closed by the engine, and the three false stops remain unverified — meaning a legitimate pharmacy could be told it fails a check it does not fail. Mark chose to merge without it rather than hold the ship, which was the right call, but the pass is owed. It has now run.
• Send the sponsor-bank compliance guide to Hagen and Corduro with the calibration ask (2026-09-04, and newly more valuable now that the first vertical is actually running). The plain-English bank edition of the new compliance rubric exists specifically to be sent — it is written for a bank underwriter, not for our own screener. The ask that goes with it is what makes it worth sending: show us pages you approved and pages you declined, and from Aaron specifically, the list of what our screening has flagged that it should not have, and what it has missed. That is the only way to calibrate 271 checks against how these banks actually underwrite rather than against how the rulebooks read. Sending it is external, so it keeps the confirm-before-send gate; the draft is ready at Compliance/Compliance Research/.
• PII key rotation — DECIDED 2026-08-21, booked for Saturday 08-22, DID NOT RUN — needs a new morning with Mark (opened 2026-08-16, and back to being the most consequential item on this list). The weekend went to the wet-sign lane instead — both slices 08-22, the notifications 08-23, and the lane is now finished; the plan is unchanged and nothing new blocks it, but the gap stays open until the rotation actually runs. The key protecting merchant PII exists only inside the hosting provider's runtime; it can't be exported, no copy exists anywhere else, and the password-manager candidate that looked right decrypted 0 of 21 rows against a restored dump — so today's nightly backup restores the system but not the protected columns. The plan is now grilled and locked: mint the second key and escrow it to the shared "Ainsworth Continuity" vault before a single row is written under it (the vault was created and populated 08-21, with Jeff added), run both keys side by side, then cut new writes over. The old key stays in the runtime until the November access review rather than being deleted at cutover, because it is the only thing that could ever read a straggler found late. Four things the grill caught get built in — six database constraints hard-pin the old key's version prefix and must be widened first; one table hides encrypted values inside a JSON payload the original column list missed; every rewrite guards against clobbering a concurrent edit; and the OCR-text table needs small batches. The tracer is a dry run, then one synthetic row re-encrypted and read back through the live runtime, then the book. Mark's part: be available and confirm the escrow before the first write.
• Confirm with TRX that VPS may sign the inspector block, then flip VPS onto the wet-sign lane (2026-08-22, one question and one click). The partner wet-sign lane shipped with nobody switched on, deliberately. Venture Payment Solutions is the whole reason it exists, but their applications carry an inspector block that Ainsworth normally signs, and whether VPS signing it is acceptable is TRX's call, not ours — it is a condition to confirm, not code to write. Once TRX answers, the permission is a single diff-audited flip on the VPS partner page and the lane is live for them.
• Chase Fiserv on the sandbox credentials — CLOSED 2026-08-24 (opened 08-18). Both halves cleared in one day. The signing failure was never Fiserv's linking or our code: the stored secret was a stale truncated value, and the correct pair arrived in the collection Fiserv sent — the sandbox answered on the first attempt afterwards. The pricing failure that followed was likewise not the missing price list it looked like, but a product combination nobody had priced. Boarding, the agreement and order status all return. What replaces this item is below, and it is commercial rather than technical.
• Own the Fiserv rate schedule — the one thing holding the boarding build's commercial half (2026-08-24, and the newest item on this list). Fiserv prices each element as a band: a floor, a default and a ceiling, with the per-deal number chosen inside the band at boarding time. That makes the floor Ainsworth sets into pricing discipline no admin can go under — which is why the numbers are Mark's call and not an engineering one. A draft schedule has already gone to Fiserv framed explicitly as a format check, not a final one. Two answers are needed to finish it: confirmation that the per-element band format is what their setup takes, and — the harder one — Ainsworth's own buy rates: what we are charged per chargeback, per retrieval and per ACH return. That schedule isn't written down anywhere Ainsworth holds today, and the generic numbers visible in the sandbox are Fiserv's defaults, not our cost. Also outstanding on their side: enabling document upload and order submission so the last two steps of the flow can be exercised.
• Pick the offsite backup destination + escrow the passphrase (2026-08-16, small). Nightly dumps and the blob mirror run locally, but the offsite leg is a no-op until a destination is set, and the encryption passphrase that protects it still needs to go into the password manager. A backup that only exists on the same machine as the thing it's backing up is one incident away from being no backup at all.
• Flip "Fiserv at invite" on for the partner who asked — DONE (2026-08-16, closed same day). The picker shipped with the permission off for everyone; Highwire Payments and Paymerica were enabled 08-16 and Venture Payment Solutions on 08-17, all on Mark's direction and all diff-audited. Every other partner remained off by design until 2026-08-20, when Mark reversed the default: the channel is now enabled for every partner and new partners start enabled, making the checkbox an opt-out. The permission is still per-partner and still diff-audited — what changed is which way it points.
• Regenerate stored MPAs — effectively CLOSED 2026-08-05 (open since 2026-07-15). The list turned out to be mostly stale: LUNA was regenerated back on 07-15, and Iron Peak Peptides was abandoned by Mark on 08-05 (restorable), which takes its three pre-bump MPAs out of scope. Two stored MPAs still predate the canonical-shape bump — Greystone/Well Rooted and Members America/Vital Lab Essentials, both generated 07-13 — and neither has an in-flight placement, so nothing is blocked. Regenerate them only if either deal wakes up. The standing rule is the part worth keeping: any stored MPA generated before the last shape bump 409s on send until regenerated — that gate exists so a pre-fix document can never reach a bank.
• Press "Link agreement to VPS" (2026-08-06, one click) — the Venture Payment Solutions agreement 6ce55d9b is still sitting at fully signed. Since the activation fix shipped, its page now offers Link agreement to VPS rather than the button that used to error. Mark presses it. (The MDS Ventures agreement was voided in the same ship — it was a real signature used to test the flow, kept as a record.)
• Eyeball a filled iBill MPA in Acrobat (2026-08-06, five minutes) — the last unclosed gate on the new paper. The Acrobat "error 18" class only ever reproduces in Acrobat itself, not in a browser preview; the iBill flatten path matches TRX's so the risk is low, but the check hasn't been done. A sample file was left open on Mark's screen at ship.
• Say where Zen Oil's other three URLs were sent — CLOSED 2026-08-13 (open one day). Camping Tools Storage, Gentleman Fashion Wear and Zen Oil Atelier went to TRX · Esquire, and Mark's answer was applied through the same update the first three used, with audit rows written. All six Zen Oil locations now carry a named channel; none read generic "Bank" any more. What remains from this ship is the larger call: whether a wet-signed location should be able to advance past approved at all is a product decision only Mark can make — which channels get a wet lane, and what gates it. ANSWERED 2026-08-22: the wet-sign lane shipped with that call made — a per-partner permission, off by default, partner uploads landing as pending and an admin confirmation acting as the attestation. What is still URL-Tracker-specific (whether a wet-signed location row should advance past approved) rides on the same decision and is now a build question rather than an open product one.
• Finish the VPS TRX portfolio data (2026-07-27, grew 07-28, grew again 09-11 and 09-15) — all 12 wet-signed entities are backfilled and placed, Marixor Holdings Corp being the newest (09-15, one TRX → Esquire channel) after Brave Fenn LLC, the first on two channels at once, but three things still need Mark: one DBA is missing its website URL (its app duplicates a sibling's, so the location row can't be created), one DBA's statement descriptor doesn't match its page-1 name and is flagged back to VPS, and all 12 EINs — plus Brave Fenn's and Marixor's banking numbers — need entering through the admin UI before the bank packages are complete. Those fields are encrypted columns, so a backfill script run locally cannot write them; only the admin UI can.
• Get the first real processor month into the import console — DONE 2026-08-10 (open since 2026-08-03, and the top item on this list for a week). The NMI Query API keys came through, both gateway accounts reconciled to the cent against the gateway's own snapshot, and Mark landed and applied both batches through /admin/import. ingestion_batches and metric_snapshots are no longer at zero, and the feed is now nightly rather than a standing ask. The TRX Manage Portal login is still pending with Craig but is no longer blocking anything — NMI carries the whole live book.
• Resolve the six open auth-decline alerts (2026-08-10, minutes) — the last step of the P4 exit gate and the only thing left on it. On /admin/alerts, close the six with the MCC-5411 note that's already seeded on the accounts: use Resolve, not False positive — they were true positives against the old 50% threshold, and mislabeling them teaches the wrong lesson to whoever reads the queue next. The retune to warn-80 / crit-90 shipped with the automation, so they won't re-fire below the new line.
• Corduro / Chesapeake pend batch — DECIDED 2026-08-05: not being loaded. All nine lists were captured (86 pends, reduced to a dozen repeated shapes plus four genuinely open questions, drafts and tracker at Applications/Venture Payment Solutions/PENDS_TRACKER_CORDURO_2026-08-03.md), but Mark's call is that we won't be responding to them — the Pend Tracker starts from new pends going forward. The captured file stays as reference. The one item that may still deserve an answer on its own merits is the missing/incorrect MPA on the Outdoor Ready Pro lead. Note the VPS applications mailbox is only reachable from mark@ainsworthpayments.com.
• Send the bank-auth expectations survey (2026-08-03) — draft is written at Ainsworth Payments/CRM/Bank_Auth_Survey_Draft_2026-08-03.md. It asks the sponsor banks what they require for logins (MFA, SSO, revocation). As of 08-10 this is the only gate holding /bank at demo-grade — the data gate closed when real gateway volume landed, so this one email now stands between a built surface and real bank users on it.
• Payout ledger stage-2 exit gate (2026-08-02, due ~late September) — the ledger went live having reconciled exactly against historical months, but the agreed second stage is a re-verify on a real period before any real payment reference is keyed in. Until that runs, the ledger is live but unproven on current money. Don't let the date pass silently.
• Call the ticketing gate — the June 15, 2026 forcing date lapsed with no decision. Phase 7's notification slice (the one hard dependency) is still unshipped, so the honest options are: ship that slice, or formally push ticketing to a named later date. Leaving it undated is how it quietly rots.
• Change Dropbox Sign account email (small) — Settings → Profile: msmith2000@gmail.com → mark@ainsworthpayments.com, so signer emails read "Mark Smith (mark@ainsworthpayments.com) has requested a signature." Login + billing receipts move with it; API key unaffected. Also consider cancelling the now-redundant $13.50/mo web Sign Essentials plan.
• Esquire fillable MPA — request a fillable AcroForm PDF from Esquire. Without it, the Esquire mapper can't be built and Esquire-placed merchants can't get a portal-generated MPA.
• Phase 6 PDF parser samples — get Corduro / TRX statement PDFs from Jeff. Unblocks the highest-leverage Phase 6 follow-on (residual statement parsing).
• Residual CSV/Excel sample — get a real upstream export sample. Unblocks the residual-automation input connector (the "next" QBO payout integration depends on this landing first).