Measured,
Not Modeled.

This page documents how garage.paddock20.com decides what it is allowed to publish. Not the pitch, the plumbing: how a phone screenshot becomes a reconciled number, how a build can refuse to ship itself, and why the site makes no live requests at all once it is live.

Written for a reader deciding whether an engineering claim is real, not for a reader deciding whether to like it. See the case study this came from for the narrative version.

Every public claim about what an electric vehicle costs to run falls into one of two buckets: a manufacturer figure produced under laboratory conditions, or a personal spreadsheet nobody outside the household can inspect. Paddock Garage was built to sit in neither bucket. The rule it follows is simple to state and expensive to build: a number either comes from an invoice or a sensor, or it says, in the same breath, that it does not.

That rule only means something if it is enforced somewhere other than the author’s memory. The discipline has a name, data provenance: proving where a number came from instead of asserting it. This page is about where that proof lives: in a label that travels with every figure, in a generator that will not publish a value it cannot trust, and in a pre-deploy check that reads the finished HTML looking for a reason to fail.

Three Labels, Not One

Every figure on the site carries a small chip next to it, and the chip is not decoration. It is a claim about where the number came from, and the build system treats the three chips as genuinely different categories, not shades of the same confidence.

The clearest illustration of why the distinction matters is not a case where one method is right and the other is wrong. It is a case where both are honest and they still disagree. This vehicle’s own ledger states a fuel saving of roughly two hundred fifty dollars against the specific gas vehicle it replaced, calculated from measured miles at a measured saved rate per mile. A connected-car analytics service the owner also uses reports a lower savings estimate for the same window, because that service compares against a generic vehicle averaging roughly twenty five miles per gallon rather than the specific vehicles this one replaced. Neither number is wrong. They answer different questions, and the page says which question each one answers instead of picking the more flattering figure and calling it settled.

A Site That Cannot Phone Home

Every page on garage.paddock20.com is plain, pre-rendered HTML and inline SVG, generated once at build time from a single JSON snapshot and shipped as static assets. There is no database call behind the page a visitor loads, no API request firing on page view, and no server process that could be queried, rate-limited, or tricked into returning something other than what was deployed. Several pages say this in plain language at the top: the page was built from a snapshot taken on a specific date, and it makes no live requests.

For a site publishing one person’s real driving and charging history, that constraint serves privacy and integrity as much as performance. There is no live endpoint for a scraper to hit repeatedly, no session state that could leak a number to one visitor that another visitor does not see, and no code path where a figure could be current on one page and stale on another, because no page holds a value that was not baked in at the same moment as every other page. Pulling a fresh snapshot and regenerating the entire site is the only way any number on it changes. There is exactly one door in.

From a Phone Screenshot to a Reconciled Number

The gig-work side of the site exists to answer a question a delivery platform’s own app will not: how many of the miles a driver puts on a car for a shift earned anything, and how much of the time the app claims was “active” was spent driving. Getting there means treating the app’s own numbers as one input, not the answer, and checking them against what the vehicle itself recorded.

Step one: capture on-device, nothing leaves the phone as text

A shift is documented the way the driver experiences it: screenshots of the delivery app’s own screens, taken on the phone that ran the shift. Reading those screenshots into structured data uses Apple’s on-device Vision framework, run locally with no network call and no API key. The images are converted to text on the same machine that stores them; nothing is uploaded to a third-party OCR service to get a batch count or a route distance off a screenshot.

Step two: reconcile against the vehicle, not the app’s own account

The OCR output for a shift, batches accepted, items, the app’s own route distance, its own sense of how long it was “active,” is matched against the vehicle’s independent telemetry for the same window: its drives, its recorded miles, its state of charge before and after any charging stop. The vehicle does not know what the app said, and the app was never asked whether the vehicle agrees. Reconciliation is what happens when both records land in the same place and get compared.

Step three: the gap is the finding

Two gaps come out of that comparison, and neither is visible from either source alone. The first is a time gap: the delivery app’s own clock only counts a batch as active from accept to final drop-off, so the minutes spent between batches, including any charging stop, do not appear on the app’s side at all. The second is a mileage gap: the vehicle’s recorded miles for the shift, compared against the app’s own planned route distance, show whatever driving happened beyond the planned route, sometimes called “dead miles” because no delivery was attached to them.

A real settled day from the site’s own published register: three batches, four orders, eighty nine items. The delivery app’s own clock read four hours and four minutes active. Door to door, from first accept to last drop-off, ran five hours and nineteen minutes. Most of that hour-and-fifteen-minute gap was one charging stop, from seventeen to eighty percent. The vehicle drove 29.3 miles against a planned route of 28.9, so 0.4 miles beyond the route, not zero, but not the kind of number that changes a decision either. The electricity for the entire day cost $3.19.

Step four: the export allowlist decides what leaves the warehouse

The reconciled data lives in a private warehouse with every column the app and the vehicle produced, including ones that never reach a published page. What ships to the site passes through an explicit allowlist: durations, counts, distances, and the vehicle’s own energy cost survive; every pay-related dollar figure, every per-hour rate, every clock time, every address, and the account identifier do not. The export step also refuses outright, exiting with an error instead of writing a file, if a day has a drive that has not been labeled, or a route leg that has not been logged. A day with a gap in its own record does not get to publish a clean-looking summary of itself.

A Build That Can Fail Itself

Before any of this reaches a visitor, a pre-deploy check reads every generated page as plain text and looks for reasons to refuse the deploy. It is not a style guide someone consults. It is a script with a nonzero exit code, and a failing run stops the site from shipping.

What it checks for, on every page, every time: a fixed set of forbidden patterns, including any identifying serial characters, a street address, coordinates precise enough to locate a residence, and the site’s own house style rule against the em dash. A separate rule reads every sentence that contains a dollar sign and fails it if the same sentence also contains a pay-related word, a platform name, a store name, or the words batch, order, or delivery, while letting a plain statement of the vehicle’s own running cost through. A page documenting one delivery day is additionally checked for literal clock times, since a duration is safe to publish and a start time is a statement about when a household is or is not home. Every local file a page links to has to exist, and no single page is allowed past a fixed size ceiling.

A concrete catch: an impossible number in the source data

This is not a hypothetical safeguard. In the daily telemetry, one date’s reading for the share of that day’s miles logged under the vehicle’s own driver-assist system came back at 154.1 percent, a figure that cannot be true of any day no matter how it is measured. The page generator checks that value against a 0 to 100 percent range before it is allowed into that day’s detail view. Outside that range, the field is silently dropped from that single day’s display, a warning is written to the build log so the anomaly is not lost, and the rest of that day’s real figures, its mileage, its charging, its efficiency, still publish normally. The build does not stop, and it does not print a number it cannot stand behind. It prints less, and says so in the one place a person reviewing a build would look.

The distinction that example is meant to draw out: the gate did not catch this because someone happened to notice a strange chart while reviewing the site. It caught it because the formatter that assembles that one field cannot execute without the range check passing first, whether or not anyone was watching that day.

Aggregation Is a Privacy Decision, Not an Afterthought

A separate, earlier decision shapes what the reconciliation pipeline is even allowed to compute toward a public page. Raw drive data is precise: exact coordinates and exact departure times, which is exactly the problem. A handful of drives from the same vehicle cluster tightly enough to point at a residence and a regular destination, and a departure-time pattern is, in effect, a public log of when a home is empty.

The site’s driving page resolves that risk by design rather than by redaction after the fact: individual drives are aggregated into city-level corridor pairs, weighted by how many trips ran between them, before anything is rendered. Per-drive coordinates and departure timestamps are excluded from the aggregation entirely, not blurred or rounded, so there is no higher-resolution version of the public page sitting one query away. The shape of the driving is public. The driver’s schedule is not.

Why Any of This Is the Point

None of the mechanisms above are unusual in isolation. On-device OCR, a data warehouse, a static site generator, and a pre-deploy linter are all ordinary tools. What they add up to here is a specific discipline: state a number, show the mechanism that produced it, and make the mechanism something a reader can go check rather than take on faith. That is the same standard this studio applies to a client’s production system, turned on its own.

The source for every claim on this page is a public repository and a live site, not an internal document. A reader who wants to verify any of it can read the actual check that runs before every deploy, the actual function that dropped the anomalous reading, or the actual published page carrying the reconciled shift. Links are below.