Labeled assumptions

These are the load-bearing assumptions I made while building. I labeled them so you can challenge any one of them without having to reverse-engineer my reasoning from the code.

A. Customer & product

• A1. Reap's customer base is small and medium-sized business → mid-market, Asia-Pacific-heavy with Hong Kong headquarters, with web3-native businesses and cross-border importers/exporters as the prominent segments. The agent commits to one mocked accounting target (Xero, as the closest fit to that profile) but never touches an accounting client directly — it emits a typed payload that any adapter (Xero, QuickBooks Online, NetSuite) can consume.
• A2. Reap already ships card transaction streams, multi-currency support, United States Dollar Coin-settled payouts, and artificial-intelligence receipt optical character recognition. The Chief Financial Officer Agent extends, not replaces, that surface.
• A3. Agentic Payments on Reap today is directional, not shipped. This is a working sketch of what a production agent on that surface would look like.
• A4. The operator persona (controller / accounts-payable clerk) lives in the queue daily; the chief financial officer persona reviews the dashboard, treasury cockpit, and cash forecast. The weekly digest is deferred.

B. Scope of auto-tagging

• B1. Auto-tagging classifies card authorizations, stablecoin payouts, and bills to a general-ledger code from the tenant's chart of accounts. Tracking categories (department, project) are in the schema but not in the cognition contract today — they're the next prompt-version lever.
• B2. A vendor's typical general-ledger code acts as a weak prior; an override-created vendor rule acts as a hard short-circuit that bypasses the large language model entirely.
• B3. Confidence thresholds: ≥ 0.85 → autoApply (subject to autonomy gate), 0.5–0.85 → suggest, < 0.5 → refuse. Calibrated by intuition; the production move is to calibrate against the eval golden set's expected calibration error.

C. Stack & deployment

• C1. TypeScript over Python (see cross-cutting decisions). The risk of going against a Python-shop standard is named there.
• C2. SQLite is the prototype database; Postgres is the production target. The object-relational mapping dialect swap is mechanical.
• C3. Skills run synchronously inside a server action today; a durable workflow runtime (Inngest) is the production-target. The skill interface is shaped so the swap is a deployment change, not a rewrite.
• C4. All model calls go through one provider-agnostic surface (Vercel Artificial Intelligence Software Development Kit over OpenRouter). The eval harness can sweep Anthropic, OpenAI, and Google providers with one environment flip.
• C5. Ninety-two runtime golden cases across four skills (auto-tagging 37, policy-enforcement 22, accounts-payable agent 18, daily-pulse 15), plus 18 seam-specific cases for the natural-language policy compiler and accounts-payable optimizer. The harness scales linearly into the thousands; size is a time budget, not a ceiling.

D. Multi-tenant model

• D1. Tenant identifier is first-class on every table and every query — there is no path through the data layer that skips it. Production Postgres should layer row-level security on top.
• D2. Retrieval indexes are partitioned by tenant. No shared vector store across tenants, ever.
• D3. Cold-start priors today are short chart-of-accounts hints in the prompt plus the autonomy ladder defaulting new tenants to suggest. Anonymized cohort signals ("median fintech tenant codes Stripe fees to 6010") are a planned second source. The principle — never another tenant's raw labels — holds either way.

E. Decision lifecycle

• E1. Decision payloads are immutable by convention — corrections live in a separate overrides table. Vendor rules are append-only via supersession: each override marks its predecessor superseded and inserts a new active row, so rule history is preserved. Production should enforce decision immutability at the storage layer with a trigger.
• E2. Each decision row carries prompt, model, chart-of-accounts, and rules-bundle versions. Re-running the same event under different versions produces a new row, not an update.
• E3. The idempotency key is a hash of tenant + skill + event + prompt + model + chart of accounts + rules. Replays are safe because the conflict resolves to "do nothing" by design.
• E4. An override writes a per-vendor rule, optionally appends a golden-eval row, and flags the row for retrieval-index inclusion. The vector store remains a production sink.

F. Eval

• F1. Top-1 accuracy, refusal precision, refusal recall, mean confidence, expected-calibration-error buckets, latency, schema conformance, token volume, and estimated token cost are scored. The small golden set means expected calibration error is directional, not a promotion-grade calibration result yet.
• F2. Adversarial cases are hand-crafted. Without a real Reap customer's data, the surrogate for "out-of-distribution" is unfamiliar vendor + missing receipt.
• F3. Multi-model sweep treats each model as an independent run; no ensembling. Cost is estimated from OpenRouter usage metadata when available, with a local price-table fallback. Treat the dollar figure as directional, not invoice-grade billing.

G. Out of scope (explicit)

• G1. Real Xero / QuickBooks Online Open Authorization, sandbox calls, push to ledger
• G2. Real optical character recognition pipeline
• G3. Vector retrieval (deterministic vendor + merchant-category-code lookups serve in the minimum viable product)
• G4. Full chief-financial-officer-grade cash forecasting — partially built. /forecast projects six weeks of scheduled accounts-payable outflows against seeded balances and a working-capital floor; /treasury routes upcoming bills against seeded sleeve balances. Production still needs accounts-receivable/inflows, payroll, tax, seasonality, confidence bands, and walk-forward backtests.
• G5. Dual control on accounts-payable money-movement is built for the >$10k threshold. What's still deferred: real role-based access control roles, time-locked rollback, multi-signer chains.
• G6. Real Slack / email notifications (in-app review queue only)
• G7. Service Organization Control 2 control map, General Data Protection Regulation / data residency user interface (mentioned, not built)
• G8. Inngest deployment (interface in place; the minimum viable product runs synchronously)
• G9. Fine-tuning, custom embeddings, anything that would commit to a model family

H. Data fidelity

• H1. Seed data is deterministic (pseudo-random number generator with a fixed seed). 167 events across 5 kinds with Reap-realistic distributions (Hong Kong/Singapore/United States/Vietnam/Indonesia corridors, fiat + United States Dollar Coin). The same seed produces the same world every time, so eval cases and screenshots stay reproducible.
• H2. Foreign-exchange rates are static snapshots from early May 2026, sufficient for valid cross-event consistency tests. Not used for actual financial calculations.
• H3. Vendor seed (~30 vendors) covers the categories the golden set asserts on. Adding a vendor is a single JavaScript Object Notation entry.

---

Anything not on this list either falls under defaults from cross-cutting decisions or is an unintentional gap I would want called out in review.