Type III Outpost — Autonomous Spatial Intelligence Pipeline

Testing this idea properly meant building the whole thing. What it taught me was worth more than the business would have been.

Every Saturday at five in the morning, the system wakes up and goes to work for a company that was never founded. It starts its own database, works through the week's parcels, files its report, and shuts everything down behind it. It costs me less each month than four cups of coffee.

This is the story of why there is no company, and why I'd run the experiment again.

The idea, and the expensive way I tested it

The project is called Type III Outpost. I picked the name because it was fun. The Kardashev scale ranks civilizations by the energy they command: Type I harnesses everything its planet receives, Type II its star, Type III its galaxy. We are not close to any of them. A Type III civilization would outlast me, my relatives, and my offspring by a margin that makes a business plan look brief. The first step is capturing the sunlight already landing on the ground, and what that energy would power now is compute.

The outpost half is the honest half: find empty land with unrealized potential and plant small outposts of solar generation on it. One name holding the largest unit of civilization anyone has imagined and the smallest kind of settlement there is — a galaxy, and a shack in the desert.

Utility-scale solar and AI data centers share a bottleneck: land. Finding it is still a manual trade — brokers, county record rooms, PDF interconnection queues. The idea was to automate the whole origination funnel: a pipeline that reads the queues, parses county GIS records, checks the physics and the law of every parcel, and surfaces the few worth pursuing.

I didn't test that with a pitch deck or customer interviews. I built the entire system and let it run in production: a weekly serverless pipeline on GCP, AI agents parsing the documents, a geospatial warehouse doing the elimination, all under a fifty-dollar monthly budget ceiling. Actual spend came in far below the ceiling. The coffee number is real.

What the machine taught me

The build succeeded. A representative unattended run evaluated 293 parcels and promoted ten, no human involved. But the education was the real product, and it was blunt.

County data doesn't amortize. Every county is its own schema, its own portal, its own quirks, and commercial scale would mean onboarding them one at a time, forever. The moat I'd be digging was janitorial, not technological.

Ownership was worse. When I checked who owned the parcels my funnel promoted, one out of twenty-one was privately held and realistically buyable. Nevada is mostly federal land, so a funnel tuned purely on site quality keeps surfacing parcels you cannot buy with a letter — only with a multi-year federal process.

And a perfect parcel still needs a tie-line easement to reach the grid. A corridor across fragmented private land means dozens of small owners, each one holding a veto. Right-of-Way is a legal problem wearing a geometry costume.

Underneath it all, the capital reality: land options, legal work, interconnection deposits. A game where my software budget is a rounding error, and where capitalized players already scout in-house.

The arithmetic, then the razor

Each of those lessons came with a dozen smaller ones about regulation, market structure, and how much changes between two neighboring counties. So the honest arithmetic: for a single entrepreneur, this business held more unknowns than the value of the professional learnings I had already banked by building it.

I took the Occam's razor approach. Keeping the idea alive meant adding things — licenses, partners, capital, years of regulatory learning. Cutting it kept everything that was demonstrably real: a working system, the lessons, and a story worth telling.

Nothing here was a failed company. There was never a company. There was an idea, and I tested it with the most honest instrument available: live code and a monthly bill.

What's still running

The pipeline was not shut down. It still runs every Saturday, still starts and stops its own database, still sends me its digest. Reading that email genuinely brings me joy. (You can see a redacted sample of report here.) The original design doc lists Texas and Arizona as the expansion path, and maybe someday I'll point it there — not for a business this time, for the experience of running it at a larger scale.

Some ideas are worth building precisely to learn they're not worth pursuing.

How a weekly land-scouting pipeline runs scrapers, document AI, PostGIS and Gemini end to end on GCP — with a $0 idle bill, because the architecture refuses to spend before it has to.

The most expensive mistake an AI pipeline can make is asking the model a question that geometry could have answered. This architecture is organized around never asking it.

One DAG owns the whole run

A scheduler fires one Cloud Workflows DAG every Saturday morning. Everything that happens — scraping, parsing, evaluation, reporting, backup — happens inside that single workflow, so there is exactly one place to reason about ordering and failure.

Three scrapers run in parallel: the utility's interconnection queue (PDFs on a public portal), the California ISO queue (spreadsheets), and county parcel data (ArcGIS APIs). Every file they land triggers a document processor through Eventarc. Documents get chunked, embedded, and stored in the geospatial warehouse (PostGIS with vector search), so later stages can retrieve zoning context the way a RAG system does.

[ ARCHITECTURE DIAGRAM — CLOUD WORKFLOWS END-TO-END EXECUTION FLOW ] ↗ click to expand

Math before AI

Before any model sees a parcel, the geospatial warehouse eliminates most of them. A spatial join drops everything too small or too far from high-voltage transmission. Parcels with industrial zoning skip the model entirely and score deterministically — there is no reason to pay an LLM to confirm what a zoning code already states.

What remains goes to Gemini with retrieved zoning context, and comes back as a go or no-go with a confidence score. The model is the last resort, not the first pass.

[ SPATIAL DIAGRAM — GEN-TIE RIGHT-OF-WAY CORRIDOR ANALYSIS ] ↗ click to expand

The funnel spends money in the right order

Survivors enter a deep-assessment funnel ordered strictly by cost. Free HTTP checks first: solar irradiance, then slope. Next a corridor check that runs entirely inside the geospatial warehouse: draw the tie-line corridor from the parcel to its nearest transmission line and measure how fragmented the land underneath it is. Corridors crossing too many small parcels, or touching homes, water, or protected land, are discarded as unbuildable before a cent is spent.

Only then comes the single paid check — satellite imagery read by Gemini vision — followed by flood and wetland overlays. By the time money moves, there is almost nothing left to spend it on.

A geospatial warehouse that only exists on Saturdays

The warehouse is the one component that cannot scale to zero on its own, so the orchestrator owns its life. The first stage of every run starts the instance and polls until it accepts connections; the last stage stops it after the backup. A stop that fails never fails the run — worst case, the database stays up until someone notices, which is a cost problem, not a correctness problem.

Cold start costs a few minutes at the head of a weekly batch, which is nothing. Idle cost is effectively zero. The documented budget ceiling is fifty dollars a month; actual spend runs at less than four cups of coffee. Those are two different numbers, and both are true.

Changing engines without landing

The pipeline launched on one Gemini generation and now runs on the next. The cutover used a shadow deployment: both models scored the same sixteen live satellite images, landed within a hundredth of each other, and agreed on every development verdict. Only then did the new model take over.

Model names and endpoints are configuration, not code, so the migration shipped as an environment change. No redeploy, no downtime, and a written record of why it was safe.

The warehouse takes questions now

The newest piece isn't a pipeline stage at all. The warehouse speaks MCP — the protocol AI assistants use to reach tools — through a small read-only server I wrote and pointed at the Postgres instance. I ask in plain English; the assistant writes the SQL, runs it against the live schema, and answers with numbers instead of vibes. "How many parcels did the funnel discard for slope this month?" is now a sentence, not a session.

Two choices keep it boring. The database role can only read, enforced three times over — role grants, a server that accepts nothing but SELECT, hard caps on rows and runtime — so the worst outcome of a bad query is a slow one. And it inherits the lifecycle: the warehouse still only exists when a run or I wake it, so an interactive analyst adds nothing to the idle bill.

The weekly digest tells me what the pipeline decided. The MCP server lets me ask why.

A cheap system is not a small system. It's a well-ordered one.

The agent's job was to watch my pipeline for errors. For days in June it was instead the loudest error in it: roughly 850 calls to Gemini every hour, around the clock, each one paying to draft a comment that GitHub had already refused to accept.

What I built it to do

The design is simple. A log sink streams production errors to Pub/Sub, which pushes each one to a small scale-to-zero service. The service normalizes the error, hashes it into a fingerprint, and checks whether it has seen that fingerprint before. New problem: open a GitHub issue, with Gemini writing an advisory root-cause section. Known problem: add a recurrence comment. It has filed nearly all of the four hundred issues in the project's tracker, and most weeks it is a better on-call than I would be.

Five small failures, one loop

No single bug caused the incident. Five conditions had to line up, and the postmortem is blameless because the design permitted every one of them.

A sleeping on-demand database was generating harmless error-severity noise every fifteen seconds or so. Those entries had empty payloads, so they all collapsed into one fingerprint — one ever-growing GitHub issue. The agent ran a Gemini call on every recurrence; only the creation of new issues was rate-capped. Then the issue hit a limit I had never thought about: after two and a half thousand comments, GitHub stops accepting them. The agent treated that permanent refusal as a temporary one and returned an error, so Pub/Sub redelivered the message. Forever. And because the Gemini call sat before the failing GitHub call, every redelivery paid for the model and then failed anyway.

[ DIAGRAM — RUNAWAY AGENT REDELIVERY LOOP VS. DETERMINISTIC GUARDRAIL FLOW ] ↗ click to expand

The part that stings

Detection was me, reading the bill, days after it started. The agent was spending roughly a month's budget every day, and nothing was watching the one metric that costs money. While I read the numbers I was picturing one of those enormous runaway-cloud-bill stories you see in the news.

The blast radius was luck, not design: an internal tool, a small project, a bill big enough to notice. On a larger bill this loop could have hidden for months.

The cage

Every fix was ordinary SRE discipline, applied to a component that happens to think.

Permanent errors are now treated as permanent: the agent acknowledges them, logs them, and never retries. A dead-letter queue parks any message after a handful of failed deliveries, so nothing can loop forever. The recurrence call has a cooldown. The expensive call moved after the fallible action, so a failure now costs nothing. And there is an alarm on the model-call rate itself — the alert I should have written first.

The pipeline's flaky upstreams got the same treatment. The federal wetlands API now sits behind a circuit breaker that trips after three consecutive failures and says so exactly once, instead of once per parcel.

What generalizes

An autonomous agent is a production service with a wallet. Budgets alert monthly; agents fail hourly. If the agent can spend, something must watch the spend at the agent's own timescale.

The deeper rule is about authority. In this design the fingerprint, the caps, and the state store decide whether anything happens; Gemini only writes the prose. That boundary — deterministic control plane, generative narrator — is the reason the agent could be caged with ordinary tools instead of rebuilt.

The model writes the prose. It never gets to decide.

Ethical data extraction at scale is mostly deciding what a system will refuse to collect, publish, and be allowed to do. In this pipeline, the refusals were the hard engineering.

A pipeline that scrapes, parses, and cross-references land records at scale has to answer an uncomfortable question before the first line of code: what will it refuse to do? The AI agents in this system wrote a lot of the code. Every refusal came from me.

Take only what is already public

Every record the system extracts is public or government-published: utility interconnection queues, county GIS portals, federal energy, flood, and wetland databases. None of it sits behind a login. That was a source-selection decision made up front, not a compliance patch made later — the system's appetite was constrained before it existed.

The footprint matches the appetite. The entire pipeline runs as one Saturday-morning batch, so each source is visited once a week. At that cadence rate limits stop being a compliance question — no limit is set low enough to notice the system exists. Not a crawler, a weekly reader: one more restraint that lives in the architecture instead of in a policy.

Filter before you enrich

Data minimization here is not a policy document. It is the execution order of the pipeline.

The assessment funnel only enriches parcels that survive every earlier gate — geometry first, free checks next, paid lookups last. The system never bulk-collects what it can eliminate first, because the architecture won't let it. A policy can be forgotten by the next maintainer. An execution order can't be forgotten without rewriting the DAG.

Telemetry that forgets on purpose

The monitoring agent never stores raw log lines as identity. It strips coordinates, IDs, and other ephemeral values out of each error before hashing what remains into a fingerprint — so its long-term memory holds the shape of a failure, not the data that rode along with it. The same reflex shows up in small places: when the wetlands API circuit breaker trips, it logs its one failure line with the coordinates deliberately removed.

Location data is the sensitive currency of a land pipeline. The operational layer was built to not remember it.

Preparing to publish was the real audit

I got this repository ready to go public, and then I decided not to publish it.

The preparation was worth more than the publication would have been. The secret scanner had already told me the history was clean, and it was right: there were no credentials in it. What the preparation turned up was a different category of thing — the market thesis, my own address stamped on every commit I had ever made, a folder of working files nobody had thought to ignore. None of that is a secret. All of it was mine, and I would not have wanted it read. So I rewrote the history and stripped every trace of it out.

Everything that survived that pass is still in place. Operator email addresses exist only in a gitignored environment file — the deploy scripts refuse to run without it, and the services fail loudly at startup if it's missing. Secrets live in a managed store, never in git, and gitleaks scans the entire history on every push and again weekly. Not because I distrust my own hygiene, but because hygiene that isn't automated is a mood.

One file did go out on its own: the postmortem of the week the monitoring agent became the most expensive thing in the system it was built to watch. The engine stays private, and access to it is by invitation.

Permissions, pedantically

When the orchestrator needed to start and stop the geospatial warehouse, it did not get the broad database-editor role, which also grants deletion. It got exactly one new permission, added to a minimal custom role. That distinction will never show up in a demo. It shows up in the audit.

The monitoring agent's identity is split in two: one service account may only invoke it, another only does its work, and neither can do the other's job. And the agent holds no permission to read logs at all — the log sink delivers each entry to it, so the access was never needed. The cheapest permission to secure is the one never granted.

The uncomfortable finding, after months of watching AI agents write competent code: the governance decisions — what not to collect, what not to publish, which permission not to grant — were the one part of the system no agent supplied.

Governance is the part you can't generate.