HoX is a bit of an odd duck. So it's probably time I write about what we do. In short, we build technology to enable Biological Information Networks (BIN). These are digital nervous systems to connect the world's biological information and operations.

My belief is that software and artificial intelligence are the inevitable ways we scale biological understanding and operations. It's becoming a mundane point, but advances in measurement are compounding to where "biobank" now means bits on disks instead of samples in freezers.

Increasingly, questions can be answered by database queries and algorithms instead of specialized lab assays. Combine this with labor constraints lifting as robotics and AI mature, and we can see that the bioeconomy will move away from manual labor and toward being software-native. Maybe eventually its information mass will be most of the internet.

To help speed up this shift, we're tackling two problems: fragmentation, because machines need holistic context to reason about scientific and operational processes; and data scarcity, because even at today's volume, models are orders of magnitude short of data. Intelligent software needs connected data for both doing and learning — lots of it.

We are working on hardware for the data scarcity problem, but we focus first on fragmentation, building a full-stack system for Biological Information Networks. And our goal is to gradually connect the world's biological information for humans as well as our machine assistants.

Integrated Data Networks

There's this moniker "data silos" you hear tossed around — the implication being that if we just moved information into one location, like a common S3 bucket, fragmentation would be solved. But for biodata, even if it all lived in one physical blob store, you'd still have individual data points as silos due to differences in coding, permissions, reference genomes, formats, and so on. There's fragmentation all the way down.

Rather than spell out what we mean by fragmentation, let's just look at an example of integration. The video below shows us switching from a single-cell analysis app to a genomic viewer, just by clicking on a gene. They know how to work together without any extra downloads, data shuffling, or glue.

This is a small example, but the benefit compounds as you add more parts that need to work together. Or more views onto a real-world operation, all of which have to assemble into one coherent picture. This ability to compose comes from making integration a property of the data model itself, rather than something you do after the fact.

Getting into our data stack, it has four layers. The first is the application layer, made up of capability modules that install on the system, like the genomic-alignment viewer you saw earlier. The second holds domain-specific semantics, the types and functions that compose into applications. The third and fourth are our columnar warehouse and blob storage, engineered for search and storage at the scale required.

The domain layer supports a wide range of applications over the same substrate. It holds the types and routines for specific sectors, from biosurveillance and threat characterization to precision-medicine apps like tumor typing and trial matching. People are often surprised at the breadth of applications our technology supports. When we got into biosurveillance, one of our backers said, "I didn't realize we had that in our DNA," but the system is just built to be horizontal and flexible!

Our domain models keep data linked, ensure integrity, and support diverse applications, thanks to a core structure called the resource graph. It encodes higher-level relationships between data objects, enabling automatic workflows and data capture. For instance, it might know that three samples belong to a patient, each sample had two libraries prepared, and each library produced some number of sequencing reads ... you see what I mean.

The resource graph grows as operational processes run. Because each node is backed by our columnar warehouse, we can query the whole picture through HoX Query Language (HQL) with no data engineering. The trick is that single-experiment tables blow up into cross-repository virtual tables on the fly. Letting large-scale health monitoring, population genomics, and longitudinal patient views all run on the same system as single-experiment applications.

What's more, the whole stack is vertically integrated, so we can package it into a server appliance at any size. Because we own every layer, it drops in as one coherent unit instead of a pile of integrations to stand up and maintain. That means fully private deployments, with no cloud provider in the loop and full functionality without internet access, which matters when biological data is too sensitive to leave the building.

And finally, when many of these deployments span geographic and institutional boundaries, they federate into one operational picture. This is the Biological Information Network, where data just has to live on the network to be discoverable and searchable by humans or intelligent machines. Applications deploy over one shared substrate, giving instant interoperability and eliminating the fragmentation problem.

In the future, this network will allow a single programming interface that lets us see, ask, and task across one operational picture. A single, logged, machine-readable, and directable organization where intelligent machines can get holistic context about the scientific operation. An AI-native nervous system for doing science and putting it to work in the real world.

Sometimes we think of this architecture as putting biology on the internet. Perhaps, in the end, it does for the bioeconomy what Amazon did for commerce. But we'll see how far it goes as we deploy applications across biodefense, genomic diagnostics, personalized medicine, drug development, academic research, and others.

We've only covered the data-operations side of HoX here. There's a whole other side of the company working to make that data easier to create from samples — robotics, instruments, logistics networks, and the various technologies and services that fill the information substrate. Below we discuss our defense efforts, and in the next post we'll talk about our network of labs.

Integrated Biodefense Networks

In 2001, the United States possessed many of the clues that would have exposed the September 11 plot. The failure was due to a string of mundane-sounding problems like a lack of information standards, coordination, and visibility. A complex fragmentation problem later tackled by Palantir. In 2020, the United States confronted COVID-19, and a similar list of mundane coordination problems left us more vulnerable than we needed to be.

The Department of War and others have moved to close this gap through modernization. It wants biodefense to be digital, always-on, threat-agnostic, and systematic. Major revamps are underway, along with investments in HPC centers and ML capabilities, with large sums flowing to national labs to stand up the compute and modeling backbone.

My view is these investments are only part of the story and will be ineffective without confronting the fragmentation problems. There needs to be a fabric enabling a common operating picture, something allowing real-time coordination across domain, geographic, and institutional boundaries, where you can ask the entire network any question and act on it in real time.

Today there are two ways of attempting a common operating picture. The first is to send all the data to a single location, like a national lab. This does not work due to the sheer volume and the limited strength of the global internet backbone. The data will not arrive and integrate with command in real time. And much of it can't move at all, since it's sensitive or owned by a different organization.

The second is to process all the data at the edge and only send reports back to command. This also does not work because the goal is to be increasingly threat-agnostic. Defining a report in advance requires a priori deciding what is important, and it leaves the client, not command, directing what gets reported. And because every site runs its own ad hoc client, changing an endpoint or adding one means going out to fix every site, one by one.

HoX uses BIN technology to invert things. We place hardware appliances where necessary, and these appliances sit over the top of local operations, doing integration and standardization. Command can then send HQL down into the appliance, pushing the heavy analytical work out to the edge and only sending light query requests and result sets back. All that is required on the partner side is outbound internet access.

This doesn't require all data to leave the site before it integrates with the picture, and command can ask the network any question in real time, with very little decided about what is important in advance. Command can also maintain the appliance software and integration, dramatically reducing manual coordination. It turns an impossible coordination problem into a single real-time operational picture. Centralized, but everywhere at once.

Our plan with the biodefense BIN is to add many applications over the same network, each for a specific task or role. So for instance, we've already added a biosurveillance module we'll improve over time, and we'll add modules for threat characterization, attribution, and countermeasure design. Since it's all one fabric, we can just drop in new modules.

Each of these can present a different view for a different person, whether a soldier in the field, a scientist at USAMRIID, or a world leader. And because it's all on one fast fabric, an operation can move through it in real time, from detection to characterization to response, with escalation protocols that can work across the network without manual glue.

That's it for now. I'll share more as our software modules and biosensors come online.