One Database, Three Products

Three things people usually find surprising about Axiom: (1) Locus (CRE intelligence) and Overwatch (maritime intelligence) look like unrelated products but run on the same Postgres; (2) the moat isn't any single data source — it's the entity-resolved join between them; (3) the joining standard itself, APRS, is a third product called Codex that we open-source and license separately.

This post explains how the backbone works, what cross-product fusion has produced so far, and why we think the unified architecture is what makes us hard to displace.

The naive architecture for multi-product intelligence platforms is per-product Supabase instances with ETL bridges between them. We tried that early and tore it out. Cross-product joins were always two weeks behind because they ran on stale exports; entity resolution diverged between products; the ETL itself became the largest source of bugs.

The current architecture: a single consolidated Supabase project, with row-level security partitioning what each product surface can read. Locus reads facility, demographic, and permit tables. Overwatch reads vessel, port, and AIS tables. Both read the shared event stream and the shared entity graph.

Every record landing in the shared backbone carries the APRS envelope: a record_id URN (urn:aprs:record:{namespace}:{source}:{id}), a chunk_id for vector indexing, source_system + source_uri pointing back to the original document, schema_version, normalization_version, acl_tier (research / commercial / internal), and the temporal triplet (occurred_at, ingested_at, modified_at). Once you have that envelope, every downstream join becomes possible — including ones nobody designed for at ingest time.

The single highest-leverage table in the entire backbone is axiom_events. Every meaningful action across every source — a permit filed, a vessel arrival, an FDA warning letter issued, a sanctions designation published, an EPA cleanup grant awarded — becomes a row with consistent geometry, consistent entity references, and a precise timestamp.

Why this matters: cross-product analytics that would otherwise require bespoke pipelines collapse to a single SQL query. 'Show me every facility within 5km of a port that had an FDA warning letter within 60 days of a customs hold on imports from the same parent company' is a join. Not a project.

FDA warning letters reference a manufacturing facility by name. Codex's entity resolution joins that name to a Locus facility record with H3 geometry, ownership chain, and operational footprint. When 41% of warning letters precede a Drug Shortage Database entry within 12 months, the signal is the join — neither product alone produces it.

Vessel arrival data tells Overwatch a ship is unloading at Houston. Locus's industrial facility intelligence — refineries, terminals, tank farms with capacity estimates — tells you what's actually moving. Draft survey + facility match → commodity inference at the berth level. Neither product knew it could do this until the backbone existed.

OFAC SDN entries name beneficial owners. Codex's entity graph resolves those to corporate filings. Locus's property ownership tables flag CRE assets in that chain. Overwatch's vessel ownership data extends it to maritime exposure. The output is a sanctions-exposure map that pre-empts the headlines — useful for compliance, useful for short-sellers, only possible if all three datasets are entity-resolved in one place.

Any well-funded competitor can buy permit data, AIS feeds, and FDA dockets. None of that is rare. What's rare is the entity-resolved join, the temporal alignment, the normalized geometry, and the operational track record of running scoring on top of it. Building APRS, the scout agent, and the shared backbone took two years. Replicating that takes longer than most market windows last.