Machina Ex Machina

I. The world does not keep notes

A municipal water utility will typically produce far more treated water than it ever bills anyone for. Commonly cited estimates put the gap at something like a sixth of output, disappearing through joints and hairline cracks in pipe that was buried before most of the people maintaining it were born. Utilities know this. They have known it for decades. The reason it persists is not that leaks are undetectable — a leak makes noise, changes pressure, cools the ground above it. The reason is that almost nobody is listening, almost anywhere, almost ever.

This is the ordinary condition of the built world. Electric motors consume a startling share of the world's electricity, and most of them run without any instrumentation more sophisticated than a technician who might notice a change in pitch while walking past. Bridges are inspected on a multi-year cadence by people with clipboards. Commercial buildings discover that a damper has been stuck open since March when the utility bill arrives in July. Cold chains are validated by a logger someone remembers to check at the end of the trip.

It is tempting to call this a measurement problem, but that is not quite right. Nearly all of it is measurable, and has been for years, with parts you can buy from a catalog. The actual problem is stranger and more interesting: the physical world does not keep notes. Measurement, where it happens at all, is episodic. Someone shows up, observes, writes it down, and leaves. The record lives in a person, a spreadsheet, or a proprietary cloud with a login that expired when the contractor changed. The thing itself — the pump, the beam, the transformer, the refrigerated trailer — retains nothing.

So we run an entire civilization on machines that cannot tell us what has happened to them. And then we are surprised when it is hard to predict what will happen to them next.

The last fifteen years produced an enormous amount of technology aimed at this gap, and I want to be fair to it: the components got dramatically better. Radios that sip microamps. Microcontrollers with hardware cryptography. Sensors that cost less than the screw holding them on. Battery chemistries that survive a decade of Midwestern winters. Every individual piece of the puzzle is now solved well enough.

And yet the world still does not keep notes. That failure is architectural, and it is worth understanding precisely, because the shape of the failure tells you the shape of the fix.

II. An archipelago of proprietary islands

Walk into any moderately sophisticated industrial facility and count the dashboards. There will be one for the HVAC system, from the company that installed it. One for the chillers, from the manufacturer. One for the compressed air. One for the vibration monitoring on the critical rotating assets, from a specialist vendor. One for the power meters. One for the fire and life-safety systems. If they have done any recent work on sustainability reporting, there is a seventh that tries to scrape numbers out of the other six and mostly fails.

Each of those systems is a complete vertical. The vendor built the sensor, the radio protocol, the gateway, the cloud backend, the data model, and the app. Each one is, taken alone, a competent piece of engineering. And none of them can talk to any of the others without a systems integrator writing custom code that will break the next time anyone upgrades anything.

This is the archipelago. Every island is well built. There are no bridges, no shipping lanes, and no common language, and the maps do not agree on where the islands are.

It would be satisfying to blame this on vendor greed, but that explanation is too easy and it leads to the wrong solutions. The vertical integration is a rational response to a real problem. If you are trying to guarantee that a customer's chiller monitoring works for ten years, and nothing beneath you in the stack is dependable — no common radio you trust, no identity model, no data schema anyone honors — then owning the entire column is the only way to make a promise you can keep. Vertical integration is what engineers build when the substrate is missing.

It is also, of course, where the margin is. The data model is the moat. A vendor who publishes a clean, open, well-documented interface to their sensor data has just made themselves replaceable, and they know it.

The cost of this arrangement is not mainly the licensing fees. It is that the value of sensing is super additive, and the architecture makes addition the most expensive operation available. The insight almost never lives inside one system. It lives in the correlation: the vibration signature that only matters when you also know the discharge pressure and the ambient temperature and that this unit was rebuilt fourteen months ago by a contractor who has since gone out of business. Every one of those facts exists somewhere. They exist on different islands, in different formats, on different clocks, with different notions of what a timestamp means.

We have spent a decade and a great deal of capital building lighthouses. What was needed was a coastline.

III. The trilemma that nobody is attacking head-on

There are three properties that any general-purpose sensing substrate has to have simultaneously. Extremely low power, because the whole point is to put instruments in places where nobody is going to run a cable or change a battery. Real interoperability, because an instrument that only talks to its own vendor's cloud has recreated the island. And meaningful security, because a device that can be spoofed produces data you cannot act on, and a device that can act is a device that can be misused.

All three of these have excellent, serious communities working on them. What almost nobody is doing is attacking all three at once, in earnest, in the same product. And when you look at how each community achieves its wins, you can see exactly why.

The ultra-low-power world buys its numbers by removing generality. Fixed payload formats, proprietary radio protocols, no negotiation, no discovery, minimal cryptography beyond a shared network key. Every one of those choices saves real energy, and every one of them is a small deposit into the interoperability and security debt.

The interoperability world — and there is genuinely good work here, in Matter, in OPC UA, in the semantic web of things — largely assumes devices with mains power, IP stacks, and the headroom to run discovery protocols and hold conversations. The specifications are excellent and the assumed device is a light switch on a wall, not a corrosion sensor on the underside of a bridge deck running on a lithium cell that has to last until 2038.

The security world assumes compute and, more importantly, assumes update infrastructure. Certificate rotation, revocation lists, and TLS handshakes are all reasonable when the device has power and a reliable network. They are luxury goods for something that wakes up for eleven milliseconds a day.

Each community is locally rational. Each is buying its win by borrowing from the other two. And the reason this is not just a coordination failure but an actual technical frontier is that the three problems are not three problems. They are one problem viewed from three angles.

Interoperability, stripped of committee language, means a device can describe itself in a form another system can act on. Security means that description can be believed. Low power is the budget within which the description has to be produced, stored, and exchanged. A self-description you cannot afford to transmit does not exist. A self-description you cannot verify is a rumor. A verified description that costs a joule to produce is a science project.

This is the unglamorous center of the field, and it is where I have decided to spend my time. Nothing above it works until it is solved. Everything above it becomes dramatically easier the moment it is.

IV. Why the instrument must not be the device

Here is the first structural move, and it is the one that makes the arithmetic work.

Most wireless sensor products fuse everything onto one board: radio, microcontroller, power architecture, transducer, analog front end, application logic. For a single product that is the correct engineering decision. It is cheap, it is dense, and it ships. But it means the device and the measurement are the same object, and that identity is what kills the scaling.

Count the combinations. The physical quantities worth measuring across industry number in the hundreds — not just temperature and vibration but dissolved oxygen, soil matric potential, partial discharge, torque, turbidity, strain, gas concentration, hundreds more. Multiply by the environments each has to survive: submerged, buried, food-grade, explosive atmosphere, high vibration, minus forty. Multiply again by power and backhaul variants. Every cell in that matrix, under the monolithic approach, is a separate product with its own PCB, its own RF layout, its own regulatory certification, its own firmware branch, and its own place in a fleet management system that now has to understand four hundred device types.

No organization can carry that. So instead, everyone builds the same eight products — temperature, humidity, vibration, current, pressure, contact, leak, GPS — and the long tail of measurements that would actually change how an industry operates never gets instrumented at all. Not because the physics is hard. Because the product structure cannot reach it.

The alternative is to move the boundary. The long-lived product becomes a compute and radio core: the part that owns the network stack, the local timeline, storage, security, key custody, firmware update, and device management. It goes through certification once. It accumulates field hours. It changes slowly and deliberately. The measurement-specific product becomes a detachable probe carrying the transducer, the analog front end, the excitation, and the mechanical interface to whatever is being measured.

Anyone who has used an oscilloscope already understands this. Nobody re-certifies the mainframe to look at a different signal. You pick up a different probe, and the instrument recognizes what it just received.

The scaling argument is not primarily about bill of materials, though the BOM helps. It is organizational and cognitive. A fleet operator learns one device management model instead of forty. A field technician learns one replacement procedure. A security review covers one core. A new measurement stops being a product program and becomes a purchase order.

And it opens the door to something a single company can never do alone. If the probe interface is genuinely open — mechanically, electrically, and semantically — then the long tail gets built by the people closest to each problem. The person who knows what a dairy actually needs to measure is working at a dairy, not at my desk. There are ten thousand useful measurements in the world and I will personally build perhaps forty of them. The only architecture that reaches the other nine thousand nine hundred and sixty is one where I do not have to.

V. What the best science fiction got right, and what it quietly skipped

I want to make an argument by way of fiction, because I think the fiction has been more clear-eyed than the industry.

Vernor Vinge's novels imagined localizers: sensing elements scattered like dust, cheap enough to broadcast across a room by the handful, self-organizing into a fabric that knows where everything is and what it is doing. Characters in those books do not marvel at the localizers. They use them the way we use pavement. The technology has receded into infrastructure, which is the highest compliment a technology can be paid.

Star Trek's tricorder is, structurally, exactly the architecture I described in the previous section: a general instrument body with a detachable scanner that adapts it to whatever needs measuring. Nobody in that universe carries eleven tricorders.

Iain Banks wrote civilizations where the environment simply answers. You ask a room a question about its own past and the room responds, because the room has been paying attention the entire time and kept a record.

What all of these have in common is worth naming carefully, because the popular reading gets it backwards. We tend to remember the intelligence at the top of these systems — the shipmind, the AI, the drone with a personality. But none of that is what makes the world in those books feel alive. What makes it feel alive is a saturated, trustworthy, interoperable sensing substrate at the bottom, so pervasive and so reliable that no character ever thinks about it. The intelligence is downstream. It has something to be intelligent about.

And here is the thing the fiction skipped, which is the part I find funny and also instructive: nobody in any of these stories ever attends the standards meeting. No one negotiates key rotation. No one asks who owns the data from the sensor on the loading dock, or what happens when the vendor is acquired, or how a device manufactured in 2031 is supposed to describe itself to a system written in 2044. Fiction gets to assume the world already agreed.

We do not. Which means the futures we find most appealing all quietly rest on a solved interoperability problem that nobody has actually solved. That is not a reason to be cynical about the fiction. It is a fairly precise specification of what is missing.

VI. The edge is about to remember

Something is changing in the economics of edge devices that has not fully registered in how we design them.

For twenty years the governing assumption of connected sensing has been that the device is a transmitter of instants. It wakes, measures, sends a number, and forgets. All meaning is assembled elsewhere, in a datacenter, from a stream of numbers that arrive stripped of context. The device is a nerve ending. The intelligence is entirely central.

That assumption was correct when memory was expensive and power budgets were brutal. It is becoming wrong. Non-volatile memory density has continued its slide down the cost curve while the energy cost per stored byte has fallen further. A modern low-power node can carry gigabytes of local storage and write to it for a rounding error against its radio budget. Which means the constraint has inverted: storage is now cheap and radio is the expensive part. Under the old assumption we were optimizing exactly backwards.

So let me propose a different idea of what a sensor is. Not a nerve ending. A keeper of records.

A node with real local memory can hold a continuous, high-rate, compressed account of one specific physical thing over years. Its own timeline, anchored monotonically so the record stays coherent whether or not the network exists. Its own provenance — which probe was attached, which calibration revision, which firmware build. Its own quality metadata, so that a reading from the middle of an outage carries an honest uncertainty rather than a fabricated millisecond. The account of the machine lives next to the machine, in a form that outlasts the network, the vendor, and the contract.

The practical consequence is that you get to ask questions you did not anticipate. This is the single most common failure in industrial data programs: something fails, everyone goes to the historian, and the data is there at fifteen-minute averages because that is what someone configured in 2019, and the event that mattered lasted four hundred milliseconds. The information was acquired. It was thrown away at the edge to save bandwidth. Under an architecture where the node keeps the full-rate record and transmits summaries, the detail is still sitting on the device, and you can go back and get it.

It also changes where analysis lives. A small model running against a rich local history of one asset — its own baselines, its own seasonal behavior, its own quirks — can do things that a central model looking at a thin stream from ten thousand assets cannot. Not because it is a better model. Because it has better context, and context is what most industrial questions are actually short of.

Extend this across a facility and you get something worth being precise about instead of naming with a buzzword. Every significant asset carrying its own account of itself. Those accounts anchored to a common timeline, so they can be laid alongside each other. Each one attributable, so you know which instrument said what and whether to believe it. Collectively that is a running, queryable, verifiable model of a physical place, assembled from the bottom by the things being modeled rather than imposed from the top by a software vendor with a rendering engine.

That distinction matters enormously. A model imposed from above is a document that drifts from reality the day it is published. A model assembled from below is reality reporting on itself, and it drifts only when something breaks — which is the exact moment you want to know.

VII. Interoperability is not a standards committee problem

It is worth being specific about what interoperability actually requires, because the word has been worn smooth.

There are three layers, and we have solved roughly one of them.

Transport interoperability is mostly handled. IP everywhere, IPv6 down to the constrained device, Thread and its relatives for the low-power mesh, MQTT and CoAP above. Getting bytes from a device to a system is a solved problem in the sense that it is well-trodden engineering rather than research.

Semantic interoperability is where things fall apart. When a system receives the number 47.3, does it know that this is degrees Celsius rather than Fahrenheit, that it came from a thermistor with plus or minus 0.5 degrees of accuracy at that point in its range, that the thermistor is bonded to the drive-end bearing housing of a specific motor, that the reading was taken while the motor was running loaded rather than coasting, and that the temperature reference for comparison is a second sensor on a sister unit nine feet away? Almost every practical integration failure lives in that paragraph. And almost every existing answer to it is a PDF and a phone call.

Identity interoperability barely exists as a concept in this market, and it is the one that decides whether the other two are safe. When a device makes a claim about itself, can the receiving system determine who stands behind that claim, and check it? Not who manufactured the device — who is cryptographically attesting to what it says about itself. Without this layer, semantic self-description is a magnificent attack surface: you have built a system that does whatever any device tells it to.

So the test I use for real interoperability is composition without negotiation. Can a system that has never heard of your device do something useful with its output within seconds of that device appearing, with no human writing a mapping, no integration project, and no meeting? If a person has to be involved, you have documentation, not interoperability.

Meeting that test requires the self-description to be a first-class machine-readable artifact that travels with the device — its identity, its channels, its units and ranges, its uncertainty, its power demands, its calibration provenance — and it requires that artifact to be signed, so that trusting it is a decision rather than an assumption.

This is not a committee problem. Committees have produced perfectly good schemas for years. It is an architecture problem: the self-description has to be small enough to fit inside a microamp power budget, and verifiable enough to be worth reading.

VIII. And then things start to move

Everything so far has been about sensing. The stakes change when the same infrastructure starts to act.

A sensing error produces bad data, which is expensive but recoverable. An actuation error opens a valve, energizes a bus, moves a machine while somebody's hand is inside it. The moment a distributed system can do work in the physical world, several things that were nice-to-have become load-bearing.

Capability declaration, so a controller knows what a device can physically do and what it must never be asked to do. Safety envelopes carried by the device itself rather than encoded in the controller, because the device is the thing that knows its own limits and the controller will eventually be replaced by a different controller. Authority, so that the question of who is permitted to command this actuator, under what conditions, is answered cryptographically rather than by network position. And receipts: a tamper-evident record of what was commanded, by whom, on what evidence, at what time.

That last one deserves more attention than it gets. We are heading toward a world where a large fraction of physical actions are initiated by software making an inference. When one of those actions goes wrong, the question that follows is not philosophical. It is a specific, answerable, forensic question: what did the system believe about the world at that instant, where did that belief come from, and was the instrument that produced it trustworthy at the time? A system that cannot answer that question will not be permitted to act in any environment where the consequences are serious. And it should not be.

Which is why I think the accountability layer is not a compliance burden bolted on at the end. It is the thing that determines how far autonomy is allowed to go. Build it into the substrate and the ceiling rises. Leave it out and every deployment stalls at the point where a lawyer gets involved.

IX. Why humanoid robots need a world that remembers

This brings me to the argument I most want to make, because I think it is both the most speculative thing in this essay and the most defensible.

There is an enormous amount of capital and talent currently pointed at general-purpose humanoid robots, and the underlying bet is reasonable: build a body shaped like a person and a model general enough to use it, and you can deploy into a world already built for people, without redesigning the world. I think that bet eventually pays. But I think the timeline is being badly misjudged, and the reason is instructive.

The implicit assumption is that perception is the bottleneck — that once a robot can see and understand a scene well enough, it can operate in it. But consider what even a perfect perceiver actually has when it walks into an unfamiliar mechanical room. It has the present instant, observed through its own sensors, from its own height, in whatever lighting exists, from wherever it happens to be standing. It has no history. It does not know which of the four identical valves was replaced last spring, which pipe is hot on the far side of the insulation, which floor section becomes slick when the compressor above it runs, that the third pump has a known bearing issue and someone has been babying it for a month, or that the panel on the left has been mislabeled since 2011 and everyone who works here knows to ignore the label.

Now notice that humans do not solve this problem by perceiving harder. We solve it with inherited scaffolding. Signage, labels, color coding, maintenance logs, work orders, the tribal knowledge of the person who has been in the building for twenty years and tells you which door sticks. Human competence in an unfamiliar environment is overwhelmingly a function of the environment having been annotated by previous humans. Take that away — put a skilled technician in an unlabeled facility with no records and no colleagues — and their first day is slow, tentative, and occasionally dangerous.

We are asking robots to have that first day, every day, in every building, forever. The tax is rediscovery, and it is paid per robot, per visit, from scratch.

A world instrumented the way I have been describing is that scaffolding rendered in machine-readable form. Assets that carry their own service history, their own operating baselines, their own current condition, with an identity you can verify and a timeline you can trust. A robot entering that space does not have to infer the room. It can ask the room, and get an answer with provenance attached.

There are three further consequences, and each one strengthens the argument.

First, memory has to outlive the robot. If environmental knowledge accumulates only inside a robot's own model weights or local map, it dies when that unit is decommissioned, and it does not transfer to a different unit, and it certainly does not transfer to a unit from a different manufacturer. That is the archipelago again, rebuilt at enormous expense with legs. Persistent knowledge about a place has to live in the place, in an open form, or every deployment becomes a bespoke integration and the economics never close.

Second, the robot's own logs are the least credible possible source of truth about what happened. When something goes wrong in a shared human-robot workspace, a record produced entirely by the system under investigation has an obvious evidentiary problem. Independent instrumentation — devices with their own identity, their own timeline, and cryptographic attestation, that were watching the space and were not party to the decision — is what makes an incident reconstructible. Independent instrumentation is what will make insurers and regulators willing to allow these machines into occupied buildings at scale.

Third, ambient sensing radically lowers what the robot has to carry. If the environment can report its own state, the robot does not need to sense everything itself at every moment, which relieves pressure on its power budget, its onboard compute, and its sensor payload. The cheapest sensor on a robot is the one that is already bolted to the wall.

So the sequencing claim I would defend is this: large-scale humanoid deployment is gated less on robot capability than on environmental legibility. The hard part is not the machine. It is the world the machine walks into, which currently remembers nothing and can describe itself to no one. Build the substrate and the robots arrive faster and safer than anyone expects, because most of what they need to know will already be waiting for them. Skip it and we will spend a decade watching extraordinarily capable machines be defeated by unlabeled valves.

X. Instrumentation that places itself

There is one more constraint that quietly determines what gets measured, and it is not electrical. It is access.

We measure what is convenient to reach. A sensor on a bridge soffit means a lift, a lane closure, a permit, and a crew. A node on a transmission tower means a climb. A monitor inside a live process vessel means a shutdown. The result is a systematic bias in the world's data toward the things that were easy to get to, which are frequently not the things that matter most. And the data that would justify measuring the hard places never exists, because getting it requires measuring the hard places.

Aerial and small-robotic deployment breaks that loop. When a node can be placed, serviced, and recovered by a drone rather than a crew, the cost function changes shape entirely, and measurement stops being an infrastructure project and becomes an errand.

Follow that further and something more interesting appears. If placement is cheap, instrumentation does not have to be permanent. You can saturate. A swarm of small platforms distributing dozens or hundreds of nodes across an area for the duration of a question, then recovering them when the question is answered. A wildfire perimeter instrumented in an afternoon with a moving lattice of temperature, wind, and particulate sensors that fire crews can watch in real time. A flood plain seeded ahead of a crest. A structure after an earthquake, covered in strain and tilt nodes before anyone is asked to walk inside it. A field instrumented densely for the three weeks that actually determine the harvest, then stripped and moved to the next field.

This only works — and I want to be blunt about the dependency — if the nodes describe themselves and keep their own time. A hundred anonymous sensors dropped from the sky, each with an unsynchronized clock and no record of what it is or where it landed, is not a dataset. It is a cleanup project. Every property discussed earlier in this essay is load-bearing here: signed identity so you know what you are reading, monotonic local timelines with anchor-based reconstruction so a hundred devices can be laid on one axis afterward, self-describing channels so an analysis system can compose them without a human writing a mapping for each one.

Get those right, and temporary saturation becomes a normal tool. Instrumentation you deploy for a week because the question is urgent, at a density nobody would ever pay to install permanently. That is a genuinely new capability, and it falls out of the architecture rather than requiring anything exotic.

XI. What it looks like when it works

Abstractions are easy to nod along with, so let me be concrete about who this helps, and how it feels from the inside.

Water. A distribution network where pressure and acoustic nodes are dense enough and cheap enough to sit at every junction, each keeping its own high-rate history. A leak is localized in hours instead of being discovered when the street collapses. The sixth of treated water that currently disappears stops disappearing, along with the energy that was spent treating and pumping it. This is one of the largest, least glamorous efficiency wins available to the developed world, and it is bottlenecked almost entirely on the cost of instrumentation.

The electrical grid. The distribution edge — the transformers, the feeders, the service drops — is nearly unmeasured, and it is exactly where electrification is applying stress it was never designed for. Every heat pump, every EV charger, every rooftop solar array changes local conditions that nobody observes until something fails. Dense, cheap, self-describing measurement at the grid edge is a precondition for electrifying anything at scale without simply hoping.

Agriculture. Soil moisture and matric potential vary enormously across a single field, and irrigation is typically scheduled uniformly because measuring the variation costs more than the water saved. Invert that cost and you irrigate the parts that need it. In water-stressed regions this is not an efficiency story. It is a question of whether the land keeps producing.

Buildings. Comfort complaints are currently resolved by argument, because nobody has data at the resolution of the actual complaint. A building whose zones keep their own thermal and air-quality histories can answer the question honestly, and can also tell you that the west side has been fighting itself since a damper actuator failed eleven weeks ago, which is roughly eleven weeks of energy nobody meant to spend.

Manufacturing and repair. This is the world I work in daily. Electronic modules arrive for repair with no history — no record of the conditions they failed under, no test data from before they failed, nothing but a customer's description and a technician's experience. Modules that carried their own operating and test history would transform the economics of remanufacturing, which is one of the more concretely useful things anyone can do about electronic waste.

Infrastructure. Bridges, dams, retaining walls, and towers are inspected on multi-year cycles by people who are excellent at their jobs and are nonetheless sampling a continuous process at absurdly low frequency. Continuous strain, tilt, vibration, and corrosion monitoring turns inspection from a snapshot into a signal, and turns maintenance from a calendar into a response.

Emergency response. Every scenario above assumes normal operations. The version that matters most is the abnormal one: a chemical release, a flood, a fire, a collapse. Sensing that can be deployed in minutes, trusted immediately, and correlated across agencies whose systems have never met is the difference between coordinating a response and guessing at one.

What unifies these is unremarkable in the best way. Fewer emergency shutdowns. Fewer three-in-the-morning callouts. Less water lost, less energy burned, less food spoiled, fewer people sent to inspect something in conditions they should not be in. Not a dramatic future. A quieter and less wasteful one, which is what good infrastructure has always delivered.

XII. What I might be wrong about

I would rather name the weaknesses in this argument than have a reader find them and conclude I had not noticed.

The surveillance problem is real and it is not a footnote. Instrumentation dense enough to be genuinely useful is instrumentation dense enough to be genuinely invasive, and the same cryptographic machinery that lets a probe prove its identity can just as easily be pointed at enforcing a vendor's control over data the customer generated. Architecture is not neutral here. An identity layer designed so that the operator holds the trust anchor produces a very different world than one where the manufacturer holds it, and those two designs look nearly identical on a block diagram. The decision has to be made early and deliberately, because it becomes nearly impossible to reverse once an installed base exists.

The standards objection is fair. The world does not obviously need another interface specification, and the history of this industry is largely a history of well-intentioned standards that fragmented rather than unified. I do not have a clever answer to this. I have a position: the open side has to be the side that actually matters to an outside builder, the specification has to be published under terms that let someone compete with me, and the thing has to be useful enough that adopting it is easier than not. If it fails those tests it deserves to fail entirely.

I may have the boundary in the wrong place. The core-and-probe split is my best current answer to where a modular instrument should divide, and it is an answer, not a proof. It is possible the durable boundary sits somewhere else, or that it moves as silicon integration continues. I would rather be corrected on this by someone building than defend it out of attachment.

And physics is indifferent to architecture. RF propagates badly through exactly the environments most worth instrumenting. Batteries fail early in the cold. Condensation gets into things. Connectors corrode. Somebody hits it with a forklift. A great deal of what determines whether this works is unglamorous mechanical and environmental engineering that no amount of elegant protocol design can substitute for.

Finally, the timeline is long. This is infrastructure, and infrastructure work is slow, incremental, and mostly invisible until it is finished. Anyone looking for a two-year exit should be doing something else.

XIII. Why this is a good place to spend a career

I want to close by talking directly to people early in this, because I think the opportunity here is being badly underestimated by exactly the people best equipped to take it.

If you are finishing a degree in electrical engineering, computer engineering, physics, computer science, or mechanical engineering right now, the gravitational pull is toward the model layer. That is where the attention is, where the compensation headlines are, and where the largest number of very capable people are currently competing to do variations on the same work.

The layer underneath is close to empty by comparison. Building instruments that are simultaneously low-power, interoperable, secure, and honest about their own uncertainty is a real technical frontier with a fraction of the crowding, and it is upstream of a great deal of what the crowded layer is trying to accomplish. Leverage tends to concentrate in unfashionable places.

The work itself is also, I think, unusually satisfying. It is physical. You can hold it. When you are wrong, a real object in the real world tells you so, quickly and without ambiguity, which is a kind of feedback that is scarce in software and precious once you have had it. It spans layers in a way few domains still do: RF and antenna behavior, analog front-end design, embedded firmware, applied cryptography, distributed systems, mechanical and environmental design, data modeling, and the human factors of a technician wearing gloves at two in the morning. It remains one of the last areas where a single determined person can genuinely understand the entire stack from the transducer to the query, and where knowing all of it makes you dramatically better at each part.

And the applications are not abstract. Water that reaches the people it was treated for. Grids that survive electrification. Bridges that get inspected by evidence. Food that does not spoil in transit. Machines that get repaired instead of replaced. If you want your work to compound into something durable, infrastructure is where that happens, and infrastructure for a world that can describe itself is being built right now by a small enough number of people that showing up matters.

XIV. The crane

Deus ex machina is the oldest cheat in dramatic writing. The plot has become unresolvable, so a god is lowered onto the stage by crane, and the audience is asked not to look at the crane. Our industry has its own version: the system is too complex to reason about, so a model is lowered onto it and declared intelligent, and nobody is invited to inspect the machinery underneath.

Machina ex machina is the inversion. Not a god delivered by a device, but machines that produce the conditions for the next generation of machines. Instruments that characterize themselves and hand their own specifications to the systems that will build their successors. Environments that accumulate a verifiable account of themselves so that anything arriving later — a technician, an algorithm, a robot — inherits context instead of starting over. Knowledge that compounds into infrastructure rather than evaporating into a ticket archive.

None of that requires a breakthrough in intelligence. It requires devices that can say what they are, data that knows when it happened, identity that can be checked at the seam, and interfaces that hold still long enough for other people to build against them. Those are engineering problems. They are hard, they are unfashionable, and they are entirely tractable.

The bottleneck in the physical world is not that our machines cannot think. It is that they cannot remember, and they cannot introduce themselves.

I am building toward the layer that fixes that and I am fully aware that it is a larger problem than any one person or company resolves. That is part of why I wrote this down. If you think I have the architecture wrong, I would like to hear it in specific terms. If you think I have it roughly right, there is a great deal of work here and not nearly enough people doing it.

The crane was never the embarrassing part of the story. The crane is the interesting part. Build it properly, and it builds the next one.

Connecting the digital to the physical.

Contact

Links

wadesthomas1@gmail.com

+12155019211

© 2026. All rights reserved.