Splittr

Where the splitter cuts in the wrong place — measured against the final package, which is what support left behind after fixing it

snapshot

Range

Split accuracy vs the final package

Share of uploads whose final page ranges exactly match what splittr proposed · dashed = trend, bars = uploads scored that day (right axis) · the final ranges reflect support remediation, so this is the splitter's real-world hit rate · the y-axis floors just below the worst day rather than at 0, so small moves are visible — read thin-volume days with care · starts

Package accuracy

Share of packages where every upload split cleanly — up is good, and the gap below 100% is the work support absorbs · one bad split anywhere in a package pulls a human in, so this sits below the per-upload rate because a package carries several uploads · bars = packages (right axis)

What changed after the split

Only the uploads that did not match · merged = final has fewer documents (splittr over-split), fragmented = more (under-split), reshaped = same count, different boundaries · the line is bad-split support tickets filed that day, an independent count of what the team actually hit — ticket dates lag the split, so read the two as trends, not row-for-row

Packages to look at

The most recent packages whose final splits differ from what splittr proposed · these are the ones a human had to fix, listed so they can be pulled up directly

Accuracy by upload size

Bigger uploads have more seams to get wrong — this is where to look for the next splitting win · counts are uploads we could compare against the final package

Accuracy by customer

Uploads split in the joinable window · a customer with low exact% is one whose documents the splitter finds hard — or whose support team re-cuts aggressively

Bad splits per package

How concentrated the damage is

Hard job failures

Only jobs that crashed and produced nothing — these are rare. The far more common failure is a job that succeeds but cuts in the wrong place: see bad splits above · error text is bucketed, never quoted

Strategy league table

Trailing window · ok% = job-level success · exact% = splits that survived unchanged (only uploads in the joinable window)

Split volume & strategy

Jobs per day stacked by the strategy that actually ran (failover included) · line = documents found per upload (right axis)

Throughput

Time per page (left axis, p50 and p95) and total split time per package (right axis) · per-page cost is the number that has to come down as uploads get bigger · per-package figures start

Gemini vs Infrrd

Model calls per day by provider (bars) with each provider's error rate (lines, right axis) · gemini is the primary splitter; infrrd is the fallback and the large-file path

Pages by engine

Which engine actually carved each page · infrrd runs a small share of the jobs but takes the big documents, so its page share runs far ahead of its job share

Provider reliability

Call-level, whole window

Failover paths

Jobs where the strategy that ran wasn't the one selected

Repair signals

Work the splitter did to fix itself mid-run · rising counts mean harder documents or a regression upstream

Model calls

Per provider & call type · p50 latency and error rate

Failure classes

Bucketed error classes — raw messages are never inlined

Methodology. Splitter telemetry comes from the splittr_telemetry dataset in the Laminr Data Warehouse (BigQuery), filtered to environment='prod'; final splits come from files_file in laminr-prod. Metabase cannot join across the two, so the refresh routine pulls each side and joins them on split_jobs.file_id = files_file.source_file_id (verified: splittr's file id is the uploaded source file, and page indexes are 0-based and identical on both sides). Package accuracy rolls the per-upload result up to the package: a package counts as clean only if every one of its scored uploads matched exactly, which is why it runs below the per-upload rate — a package carries several uploads and one bad split is enough to require intervention. Bad-split tickets are read from the committed snapshot of the Laminr Tickets dashboard in this repo (its "Bad Split" category) and overlaid as an independent count of what support actually hit; a ticket is dated when it was filed, which lags the split, and some bad splits get fixed by re-uploading rather than editing page ranges — so detection here runs below the ticket count and the two should be read as trends rather than matched row for row. Accuracy compares the set of page ranges: splittr's proposal is its post_enrichment rows when present, else its split rows, de-duplicated; the final set is every surviving child of that upload. Exact = identical range sets. Because the final ranges are what support leaves behind after remediation, a mismatch is evidence the original split was wrong — though automated downstream steps can also alter ranges, so treat it as a strong signal, not proof. Uploads splittr logged in prod that have no rows at all in the prod database are left out of every figure here rather than counted as failures: stage traffic is already filtered out and internal/test tenants explain only a fraction, so they are a join-coverage artifact (concentrated on 2026-07-14, the first day file ids were populated), not a splitting outcome. The refresh routine still tracks them as a join-health gate. Remediation arrives over time, so the most recent days are optimistic and will drift down as support catches up. Windows: telemetry begins 2026-07-10, but file_id/package_id only began populating 2026-07-14 — the accuracy, size, customer and per-package timing panels start there while volume, strategy, per-page throughput, provider and repair panels use the full window. The cutover was abrupt rather than gradual: 2026-07-13 ran 1,160 jobs but only 19 carry a file id, so that day cannot be scored and a 7-day view shows volume for it with no accuracy — from 07-14 onward coverage is 100%. Note also that a crashed job (counted under hard job failures) and a bad split (a job that succeeded but cut in the wrong place) are different failures: the first is rare, the second is the one support meets daily. Per-page time is processing_time_seconds / total_pages per job with the percentile taken per day; per-package time sums every split of a package and takes the daily median across packages, so multi-day figures are completion-weighted and marked ~. Split time is heavily right-skewed: the median is ~12s but the mean is ~22s, p95 ~63s, p99 ~224s and the slowest observed job 13m — and the gemini_chunked path alone medians near 4 minutes. Read the median as the typical upload, not the cost of a hard one; the accuracy chart's y-axis is scaled to the data rather than 0–100% for the same reason. Weekends are included (splits are pipeline events that follow borrower uploads, same convention as the Cashflow Check Waterfall); lines are smoothed with a centered moving average at 30d while KPIs and tables stay raw. Internal/test tenants excluded (same list as Customer Volume). File names, document identifiers and raw error text are never inlined — they can carry borrower details; only bucketed classes, counts and tenant names appear here. Package public IDs are shown in the two drill-down tables so a flagged package can be pulled up directly: they are internal operational references (the same ones support quotes in tickets), this site is restricted to Laminr accounts, and no borrower data accompanies them.