The knowledge base (3,059 operator rules) can be rebuilt in 6–12 weeks. The outcome dataset cannot. It only exists inside a running instance — accumulated deal by deal, nightly, across 18 months of production use.
All figures come from our live deployment. The endpoint at /api/outcomes/dashboard is public and unauthenticated — check it yourself.
The routing engine is not a static lender priority list. It is a weight model that updates every night from the previous day's funded, declined, and countered deals.
FICO score, LTV, loan amount, vehicle type, down payment, and stip tolerance are entered. matchLenders() reads the current per-dealer weight map and returns a ranked lender list with the best first-look probability at top. Only lenders with active programs for that FICO tier are eligible.
When the lender responds — approved, declined, or countered with stips — the outcome is written to the lender_outcomes table: decision, days to fund, stip count, and deal ID. The row is tagged with the dealer's dealership_id and is never shared across dealers or accessible from outside that dealer's session.
lenderReweightJob() fires for every dealer with live outcome data. For each lender, it queries all historical outcomes for that dealership and computes a composite score weighting approval rate (70%) and funding speed (30%). Any lender whose approval rate dropped more than 5 points versus the 7-day prior snapshot triggers an owner alert email.
The following morning, the next credit submission uses the freshly computed weight map. Lenders with fewer than 3 outcomes on that dealership's history are excluded from weight-based ranking — below that threshold, program eligibility alone governs. Routing precision compounds as volume grows.
Each nightly run saves the weight state to lender_weight_cache. One week later, the next run compares current weights against that snapshot — this is the mechanism behind the approval-rate-drop alert. The cache also provides immutable proof that the loop ran and what the state was at any given time.
The formula and code are visible in the repository. What is not transferable is the per-dealer data that feeds it — the 18+ months of approved/declined outcomes that give each lender's approval_pct meaning for a specific store.
The table below is fetched live from the agent log on this server. Every success entry confirms that lender weights were recomputed and saved for at least one dealer that night.
| Timestamp (CT) | Job | Result | Detail |
|---|---|---|---|
| Loading job history… | |||
0 2 * * * America/Chicago — every day at 2:00 AM Central. Defined in src/agent.js alongside 16 other nightly and intraday jobs. The sim→closed-loop sync runs at 1:30 AM (30 minutes prior) so simulation-validated deals are already in lender_outcomes when the reweight fires.
Every outcome row is tagged dealership_id. getWeights() and matchLenders() always filter by that ID. There is no shared routing model, no cross-dealer aggregation of approval rates, and no mechanism to query another dealer's history.
Every diligence team will ask this. Here is the answer before they ask it.
3,059 operator-encoded rules: desk logic, stip playbooks, lender program eligibility, bankruptcy timing, compliance checks, objection handling. A competitor with a 30-year dealer principal and adequate funding could rebuild this in a focused sprint. This is not the durable moat. It never was.
Each store's approved/declined/funded history per lender — across FICO tier, LTV band, vehicle age, stip profile, and deal structure. This data only exists inside a running instance. It cannot be scraped, purchased, or synthesized. A competitor deploying today would need 12–18 months of live production to build comparable calibration for a single dealer.
This table answers the most common diligence question: "We're buying the platform, but do we get the data?"
| Asset | Transfers at close? | Notes |
|---|---|---|
| Full codebase (163 route files, all 150 modules) | YES | Complete IP transfer. All-IP transfer preferred at close. |
| Operator knowledge base (3,059 rules, prompts, stip logic) | YES | Fully encoded in the system. 12-week formal transfer plan available in data room. |
| 42-lender matrix (program terms, eligibility tiers, stip maps) | YES | Complete documentation. Lender relationship introductions available. |
| Routing weight algorithm | YES | Published openly on this page. In the codebase at src/routes/lenderOutcomes.js. |
| Founding store outcome history (18 months, 1,167+ routed deals) | YES | The trained weight dataset from the founder's stores. This is the calibration head start. |
| External customer outcome histories (post first external pilot) | NEGOTIABLE | Subject to dealer data agreements. Structured as part of acquisition terms. |
| Per-dealer model accuracy for new deployments | ACCUMULATES POST-CLOSE | New rooftops added by the acquirer start calibration from zero and build over 12–18 months of live operation. |