One Degree Outward

When we started Big Mountain, one of the first things that interested me about large language models was how good they were at structured text.

That sounds boring now. At the time it was astonishing.

Give one a rough technical document and it could clean it up. Give it a description of an icon and it could produce a decent vector drawing. Give it a pile of notes and it could turn them into something another human could actually read. For a small company, where everybody is doing six jobs and documentation tends to be whatever somebody remembers to type before going home, this was immediately useful.

Then agents showed up, and the interesting part changed.

A chatbot can tell me how to troubleshoot a network. An agent can troubleshoot the network.

Give it access to the controller and it can look at the access points. Give it the router and it can inspect routes and interfaces. Give it monitoring and it can look backward in time. Now instead of asking me to paste thirty pages of logs into a chat window, it can go get the logs itself.

The first degree outward is almost embarrassingly obvious.

Give it a tool.

Suppose a customer calls because the Wi-Fi sucks in the back bedroom. The agent checks the AP. Signal looks acceptable. It checks the client history and notices repeated roaming. It checks neighboring APs. One is intermittently disappearing. It checks the switch port feeding that AP and finds errors. Now we aren't troubleshooting the customer's phone anymore. We're looking at a cable.

That's fun.

It is also the kind of thing computers ought to be good at. None of the individual facts are particularly difficult to understand. The tedious part is moving among six systems, remembering what you saw in the last one, and noticing that two things which live on different screens are related.

An agent removes the tedious part.

Once you see that happen a few times, you start looking around for other things to give it.

Imagine we get a convenience store as a client.

The store already has a point-of-sale system. It already has cameras. It has employee schedules, alarm logs, access control, inventory and maintenance records. These systems mostly live separate lives.

One night the register is twenty dollars short.

Normally somebody looks at the POS records. Maybe the manager watches some video. Maybe he checks who was working. If the shortage is small enough, maybe nobody bothers because finding twenty dollars can cost more than twenty dollars.

Our agent doesn't get bored.

It sees a cash transaction at 9:14. At 9:16 the drawer opens without a corresponding sale. It knows which employee was signed into the register. It asks the video system for that time and camera. It sees the employee at the counter.

That's already useful.

Then it notices something odd. The employee doesn't appear to take anything. So it reaches a little farther.

There was a maintenance ticket on that register three weeks ago. The drawer sensor had been intermittently reporting false opens.

Now the employee who looked guilty doesn't.

This is the kind of system I would love building.

There is an annoying problem, though. The store's video recorder only keeps thirty days. If the interesting pattern isn't discovered until six weeks later, the agent can know exactly which footage would answer the question and still be unable to look at it.

So we fix that.

When an event becomes relevant to an open investigation, the system places a retention lease on the corresponding footage. We don't need to keep everything forever. We preserve the parts that become evidentially interesting.

That's better engineering. It also protects employees. If somebody gets accused two months later, the machine may still have the evidence that clears him.

Then the customer buys another store.

And another.

At one store, an employee repeatedly voids transactions near closing. At another, the same thing happens occasionally. Neither pattern is particularly interesting alone. Across thirty stores, however, the agent notices that the events disproportionately occur after one regional manager visits.

Now we're having fun.

Nothing magical happened. We gave the machine access to systems the business already operated and permission to traverse relationships among them.

Retrieve something. Discover a relationship. Follow it. Retrieve something else.

One degree outward.

Eventually, suppose we land a city government.

The first obvious application is a missing child.

Police have a plate number. The city has cameras capable of reading plates at several major roads and intersections. The agent can tell investigators where the vehicle was last observed and in which direction it was traveling.

Nobody has to be talked into this feature.

Build it.

Then somebody gets murdered.

There isn't a plate this time. A witness remembers a dark SUV leaving the area around 11:30.

Fine. Search dark SUVs observed nearby around that time. There are too many.

Which ones appeared only once in the neighborhood?

Better.

Which entered shortly before the murder and left shortly after?

Better still.

Which came from outside the area?

Now we have something worth looking at.

The machine hasn't solved the murder. It has reduced a miserable amount of video review and database work to a manageable list of vehicles an investigator can examine.

This exposes another engineering problem.

Coverage sucks.

We saw one candidate SUV at 11:07 on an arterial and again at 11:41 several miles away. Four reasonable routes connect those observations. There are no readers between them.

At Big Mountain, I know what we call this problem.

Coverage.

If Wi-Fi doesn't reach the back bedroom, we don't sit around contemplating the metaphysics of radio. We figure out whether another access point belongs there. If monitoring loses visibility into a section of a network, we add instrumentation.

The city has the same problem.

Readers are expensive. They need mounting, power, communications, provisioning and maintenance. So we make them cheaper. Lower-power hardware. Cellular backhaul where it makes sense. Solar where it makes sense. Edge processing. Smaller enclosures. Better automated provisioning. Anything that lets one installer deploy more observation points for the same money.

We don't need one on every road. That's wasteful.

Placement itself is an optimization problem.

Put readers at chokepoints. Bridges. Major intersections. Arterials. Places where several possible routes reconverge. A surprisingly small number of observations can eliminate a large number of possible paths through a road network.

The next time we see that SUV, four possible routes become two.

Add another observation point and two become one.

The missing-child searches get better too.

Good feature.

The city buys more readers.

Then another murder happens, except this time nobody saw a useful vehicle.

We still have data.

What vehicles were in the area unusually late?

Which arrived from elsewhere?

Which stayed for twenty minutes and left?

Which have shown similar behavior around other crime scenes?

We have crossed a small boundary here. Earlier, the investigator told the machine which car mattered. Now he is telling it what kind of behavior matters and asking the machine which cars fit.

Still cars.

One candidate keeps appearing.

Who owns it?

That is an easy question. The registered owner has an address.

What other vehicles are registered there?

Easy.

Do any of those vehicles appear near the first one unusually often?

Also easy.

Two cars that repeatedly appear together are, strictly speaking, still cars.

We're not mapping somebody's social network. We're finding statistically interesting co-occurrences between vehicles. It is important to maintain these distinctions.

The system gets better.

It learns that a particular reader is less useful than we expected because most traffic can bypass it. Another intersection turns out to collapse enormous uncertainty about routes. We move equipment. We add equipment. Deployment costs fall.

The map develops fewer holes.

Another city wants in.

Then the county.

The problem is familiar. City A knows something City B doesn't. A vehicle disappears at the city limit and reappears fifteen minutes later in another jurisdiction. Today an investigator can call somebody. He can send an email. He can make a request.

We have spent the entire project eliminating situations where one computer knows something, another computer knows something, and a human being has to carry the answer between them.

So we federate the systems.

The data doesn't necessarily have to live in one giant database. That's crude. Each jurisdiction can retain its own systems and policies. An authorized query can cross the boundary, receive an answer and preserve the provenance of that answer.

Case number.

Purpose code.

Permissions.

Audit trail.

This is better than indiscriminate access. I would want all of it.

Now a county investigator can follow an authorized query across participating systems without spending half the afternoon on the telephone.

Then the state wants it.

That takes some work. Different agencies bought different equipment. Schemas don't match. Identifiers collide. Retention policies differ. One system calls something plate_number, another calls it registration, and a third has managed to encode the same concept in a way which makes me briefly hate whoever wrote it.

Normal integration work.

We fix it.

A stolen vehicle crosses three counties and the state system keeps the thread.

A serial burglar operates in several cities whose departments previously thought they had unrelated cases. The agent notices the recurring vehicle behavior.

A missing person crosses municipal boundaries without disappearing from the investigation every time the map changes color.

This is useful enough that people start trusting it.

Then one of those cross-jurisdiction investigations turns into something much larger.

Several cases that looked local keep touching the same small set of vehicles. A missing-person investigation in one city intersects with a motel incident somewhere else. State police have another vehicle from a stop that didn't look especially important at the time. Another jurisdiction has been working a trafficking case and hasn't been able to push it very far.

The agent sees the overlap because seeing overlap is what we built it to do.

Now we have an interstate trafficking organization.

One van becomes particularly interesting.

We follow it north.

Then we lose it.

Nothing mysterious happened.

It left Georgia.

Our beautiful statewide system has discovered the edge of the state.

An investigator can call Tennessee. Tennessee can search its systems. Somebody can send records back. There are procedures for this because interstate crime did not wait for us to invent software.

But we've seen this problem before.

Our computer knows something useful. Their computer may know something useful. A human being is standing between them.

Meanwhile there may be people in that van.

This is exactly the sort of problem federal law enforcement exists to address.

The feds want in.

Good.

For the first time, the jurisdiction of the customer begins to resemble the jurisdiction of the crime.

We don't hand a federal investigator unrestricted access to every participating state system. He doesn't need that. He needs the system to answer authorized questions for this case.

So we build that.

The query carries the investigation identifier and purpose. The receiving system applies its own policy. The request is logged. The response retains provenance. Access can be revoked. Abuse can be audited.

We're not building a national database. We're building interoperability.

And in this trafficking case, interoperability is fucking wonderful.

The van leaves Georgia.

Tennessee sees it.

Later, Kentucky sees it.

Same object. Same query. You've seen how this works.

The registered owner turns out to be a company.

Fine. Follow that edge.

The company is associated with an address.

Three other vehicles are registered through the same business.

Fine.

One of those vehicles appeared back in Georgia.

Another has been traveling the same interstate corridor as the van.

Now the graph is beginning to close around people who had previously been distributed across several investigations and several jurisdictions.

Nobody had to know the whole organization existed before asking the first question.

That's the point.

The federal investigator has another question. One of the people associated with the company may have crossed an international border recently.

A federal system can answer that under the appropriate investigative authority.

Our agent can't.

Yet.

This is not a reason to dump another agency's records into our database. The source agency already has rules governing access. Keep them.

The agent doesn't need possession of the database. It needs permission to ask the database a question on behalf of someone authorized to ask it.

So we build another controlled query service.

The answer comes back.

Follow the edge.

Eventually the case breaks.

People are recovered. Arrests are made. Prosecutors get evidence with provenance instead of a detective's screenshot of somebody else's screen. Connections that might have taken weeks of phone calls and spreadsheets appeared while they could still matter.

Put that one on the sales deck.

Then someone from a federal fraud unit sees the system.

He has a question.

Can it do this with money?

Of course it can do this with money.

Money is a graph.

His investigation has shell companies, addresses, officers, employees, reported income and identities that may or may not correspond cleanly to actual people. Some of the relevant information sits in one federal system. Some sits in another. Tax information has its own access restrictions. Social Security information has its own. Business records live somewhere else.

Good.

We already built the hard part.

An authorized investigator has a lawful reason to examine a particular person in a particular fraud case. The system asks an authorized question of one source and gets an answer.

Reported income: this.

Employment relationship: this.

Business ownership: this.

Address: this.

Something doesn't fit.

Why?

The agent shows its work.

This person supposedly earns roughly this amount. These businesses are associated with him through these records. This address appears here and here. This identity claims an employment relationship inconsistent with another record.

Maybe there's an innocent explanation.

Ask.

That's good investigative software. It isn't supposed to pronounce somebody guilty. It is supposed to notice the thing a human investigator would notice if he had three uninterrupted days, infinite patience and every relevant record arranged on one desk.

Then the investigator asks whether it can check the other subjects in the case.

Sure.

Then the next case.

Sure.

Then somebody asks a more interesting question.

We know what several fraud networks looked like after investigators unraveled them. Can the system find other structures that look like those?

Now we need to slow down again, because we've crossed the same boundary we crossed with the SUV.

First we asked:

Find this person.

Now:

Find people and businesses that behave like this.

The machinery is already there.

Entity resolution.

Graph traversal.

Pattern matching.

Controlled queries.

Provenance.

Confidence.

We aren't accusing anyone of fraud. We're identifying anomalous relationships for investigator review.

Good feature.

And now we have two extraordinarily capable branches of the same system.

One understands movement.

The other understands institutional relationships.

Somebody will eventually ask whether they can talk to each other.

Of course they can.

Suppose the fraud graph identifies six people worth examining.

Four of their vehicles regularly appear near one another.

Interesting.

Two supposedly unrelated companies share an address.

Interesting.

One vehicle repeatedly appears at locations associated with another subject in the case.

Interesting.

The system is no longer merely connecting records of the same kind. It is connecting different dimensions of the same world.

That makes location data much more valuable.

A vehicle appears at one address most nights.

Probably home.

It appears somewhere else most weekdays.

Probably work.

Every Sunday morning it leaves home, travels into the same part of town and returns about ninety minutes later.

There are several possible destinations in that area.

We don't know which.

That's annoying.

Fortunately, we've been improving coverage for years.

There is an observation on the arterial before the turn.

Another after the next intersection.

The possible destination area gets smaller.

A newer reader eliminates another route.

Now there are only a few plausible destinations.

One is a Catholic church.

We haven't inferred anyone's religion. We have identified a recurring relationship between a vehicle and a religious institution.

The vehicle does it again next Sunday.

And the next.

Just a fascinating automobile.

None of this changes what the cameras collect.

Plate.

Timestamp.

Location.

The camera has never seen a religion.

The integrated system can nevertheless develop a pretty good reason to believe something about the person driving the car that no camera ever observed.

The same automobile has other interests.

Every third Thursday it spends two hours near a medical complex.

The location resolves more precisely.

An oncology practice is there.

Medical information remains completely outside the system. We have location data.

Another vehicle demonstrates a statistically interesting affinity for a union hall.

Another frequently visits a gun range.

Another appears near a campaign office.

Another spends time at an addiction treatment center.

Another sleeps most nights at an address different from the registered owner's home.

We're not tracking people.

We're tracking cars.

At national scale, there are still blind spots. Of course there are. Rural coverage is uneven. Some jurisdictions don't participate. Some systems can't answer certain questions. Some records require authorities that aren't present in a given investigation.

These are constraints.

Engineers like constraints because constraints tell us what to work on.

Readers get cheaper.

Coverage improves.

More jurisdictions participate.

More systems expose controlled interfaces.

Entity resolution gets better.

Policy engines get more expressive.

Confidence models improve.

The system gets better at distinguishing coincidence from relationship.

And the queries get better too.

Find this car.

We've done that.

Find cars that behaved like this one.

We've done that too.

Find people and organizations whose relationships resemble structures from previous successful investigations.

We know how.

Find behaviors that tend to appear before investigators discover a trafficking network.

Interesting.

Find financial structures that resemble fraud cases before anybody has named a suspect.

Interesting.

Find recurring combinations of movement, association and institutional relationships that have historically produced useful investigations.

Interesting.

Nobody asked for a social network. We asked which cars tend to appear near other cars.

Nobody asked for religious affiliation. We asked where the car goes.

Nobody asked for medical information. We asked where the car goes.

Nobody asked the system to decide who is suspicious. We asked it to find patterns associated with investigations that previously succeeded.

These distinctions matter.

Just a fascinating automobile.

There is one more obvious improvement.

So far, a human has decided which pattern to search for.

That creates a bottleneck.

The system has access to the outcomes of previous investigations. It knows which queries produced useful leads and which went nowhere. It can compare successful cases. It can test candidate relationships against historical data. It can rank them. It can tell us which patterns seem unusually predictive.

Why should the investigator have to invent every query?

Let the agent propose some.

It isn't opening a case.

It's suggesting an investigative lead.

It isn't making an accusation.

It's ranking anomalies.

It isn't deciding what behavior is suspicious.

It's identifying patterns correlated with prior investigative value.

The investigator still decides what to do.

We are building useful features for our users.

I can imagine approving every ticket in this project.

That is the part that bothers me.

I can imagine the missing child whose parents do not give a damn about my philosophical reservations concerning plate readers. I can imagine the detective staring at hundreds of hours of useless video. I can imagine the cashier falsely accused of stealing twenty dollars. I can imagine the trafficking victim sitting in the back of that van while two agencies wait for somebody to return a phone call. I can imagine the fraud investigator looking at six shell companies and knowing that the relationship he needs is probably sitting in records he is legally entitled to examine if only he can find it. I would want the audit logs. I would want the purpose codes. I would want strict permissions, retention controls, provenance, confidence scores and every other responsible engineering measure we could put around the thing. I would argue for them in meetings. I would mean it. And then, after years of individually reasonable improvements, I could look up from the ticket queue and discover that we had built a machine capable of reconstructing enormous portions of ordinary human lives and proposing which of those lives the government might find interesting.

There was never a ticket that said BUILD PANOPTICON.

We started with a chatbot.

We gave it a tool.

Then we let it reach a little farther.

One degree outward.