Golden State Signal
The problem
Any vendor or reseller selling infrastructure into a state agency wants to know three things: what does this department already own, when does it come up for renewal, and who currently sells to them. California publishes the data that answers all three, and none of it is usable as shipped. Two incompatible export formats arrive under the same file extension. There is no product taxonomy. Contract terms are buried in free-text line descriptions. The same supplier is spelled three different ways in one file.
What I built
A local Python pipeline — ingest, normalise, categorise, analyse — that reconciles the raw state exports into one schema with full provenance, classifies every purchase into a product taxonomy, overlays contract-renewal timing and statewide reseller authorizations, and emits a validated JSON snapshot per department. A Cloudflare stack serves it: Pages, Pages Functions, D1, R2, and Zero Trust Access. Currently 267,267 purchase orders, 957,847 line items, and $49.43B in spend across 176 California departments, with every order carrying a category label and zero duplicates — scaled from a nine-department, $17.2B pilot to statewide coverage without a schema rewrite, and shipped as an independent business at goldenstatesignal.com.
It is not built for one territory or one manufacturer. The taxonomy, the lifecycle overlay, and the generation step all generalize — every state, county, and large municipality publishes procurement data with exactly the same characteristics.
What it is now
The deliverable stopped being a document. It is the Account Runbook: one California department, owned by one named salesperson, hosted behind per-user identity, with an advisor inside it that answers only from that department's filings. It refuses rather than estimates — and when it cannot answer, the refusal is recorded, because the gap between what users ask and what the data holds is the roadmap.
The part that compounds is the revision loop. A salesperson says what they learned on a call and the recommendation rewrites itself, re-tiered honestly in both directions, with what they said stored beside what changed. Everyone can read the same public filings. Nobody else has the corrections.
Choices I'd defend in an interview
SQLite locally, D1 in production. Same shape, same query language, nothing to learn twice. Generation stays local — nothing generates in production, so there is no pipeline to keep alive and no 3am failure mode. The publish command pushes finished artifacts up and then verifies the live result.
The snapshot is the single source. The same JSON renders the page and grounds the advisor, so the two cannot drift apart and tell a customer different things. Multi-tenant from the first commit — a tenant id on every row and every query including read-only ones, because customer two may be customer one's competitor, and retrofitting that later costs a rewrite.
The model is narrative only. Ingest, join and ranking work correctly with zero model calls. The model turns already-correct structured output into prose, or reasons over a snapshot it cannot add to.
The decision that mattered
I ran an LLM pass to improve product descriptions, then measured it instead of assuming it helped. 7,575 enriched rows carried only 681 distinct texts, and 74% of rows had dropped a model number or SKU that was in the original. I killed the approach, salvaged the one component that worked, and documented the negative result so it would not be tried again.
That set the architectural rule the whole system runs on: the pipeline works with zero AI calls. Ingest, normalization, joins, ranking, and aggregation are ordinary deterministic code. The model is confined to turning already-correct structured output into prose. The brief generator makes two model calls and neither one produces a number.
What scaling actually tested
Going from nine departments to statewide was the real audit of the design. It ran without a schema rewrite, but it surfaced two data-quality defects that a smaller dataset had been hiding. A mislabeled duplicate export would have double-counted $439.5M. A fuzzy-matching rule misattributed $517M of dark-fiber spend to the wrong manufacturer. Both were caught before anything reached a client, and both were fixed at the methodology level rather than patched case by case.
Scale also forced an entity-classification layer. A supplier name on a California purchase order is usually a reseller, but not always — sometimes it is a manufacturer selling direct, a consultancy, or one state agency billing another. Separating those cut the unattributable bucket from 39% to 18.5% of enterprise-relevant spend, which is the difference between a competitive map you can act on and one you have to caveat.
Four bugs that make the point
Each of these reported success while being wrong. That is the category worth talking about, because nothing in the logs asks you to look.
Purchase orders were being silently deleted. Rows were grouped into orders by purchase order number alone — but those numbers are only unique within a department. Orders sharing a number across departments merged, the first department won, and every other one vanished with its line items reattached to the survivor. One file collapsed 5,452 real orders into 4,914. Recovering them across the corpus restored 8,695 purchase orders. Nothing had ever errored.
A revision system that had never once run. The write called a method the database wrapper does not have, so it threw on every request. It looked healthy because the telemetry a few lines above logged the model's intention to revise rather than the outcome — the dashboard showed successful revisions against an empty table. The fix included making that flag report what actually happened.
Identity conflated with rank. Recommendations were keyed
play-1 through play-N in generation order, and the schema
enforced it. A refresh that dropped one would shift every id and silently relayer a
salesperson's field notes onto a different recommendation. Caught while the table was
still empty, which made it free; a month later it would have needed a migration and a
guess.
A deploy that shipped nothing and reported success. Run from the wrong directory, the tool found no functions directory, uploaded the static assets, and shipped no server code. The site answered 404 rather than the middleware's 403, so it read as a missing file rather than a missing application. Fixed by making the deploy command verify the live result instead of trusting its own exit code.
The through-line: the interesting failures are the quiet ones, and the fix is almost never the patch. It is changing what the system is willing to call success.
Where it came from, and where it goes
Version one was a 450-record HTML dashboard I built for my own territory. This is what it became once the question changed from what do I need to what would a vendor pay for. It now runs as its own business under the name Golden State Signal, with a public site, a live read-only demo, and per-account runbooks behind a login, each carrying an advisor scoped to what it is allowed to answer from. The multi-tenancy the architecture was built toward is now in place rather than pending, and the first customer runbooks are in test.
Read the full engineering breakdown →
The seven-source demand chain, where the model is and deliberately isn't, cost engineering, and the honest limits.
