1,262 product safety profiles across 7 consumer apps, on one ALETHEIA integration

The thesis

GeodesicNexus's bet is that consumer safety doesn't actually need separate engineering for every domain. A pet-safety app and a baby-safety app and a food-safety app all do the same three things: resolve a product to its compound list, surface the regulatory record for those compounds in the right exposure context, and compare or rank. The difference between them is what they pre-load: which contexts they default to, which product categories they show first, which language they use to describe risk.

So instead of building seven apps, GeodesicNexus built one engine and seven entry points. The engine is a 46 KB JavaScript module, gdn-core.js, served from the hub. Every subdomain loads it. Every subdomain calls ALETHEIA underneath. The differences between apps are configuration, not code.

The seven apps + hub

Each subdomain pre-loads filter defaults appropriate to its domain (e.g. pets.geodesicnexus.com defaults context=dog with a cat toggle), but every subdomain serves the full 1,879-compound corpus on demand — users can search across domains from any entry point.

Subdomain product counts are domain-mapped primaries; some products appear in multiple apps via secondary domain mapping, so the column does not sum to 1,262.

What the integration looks like

gdn-core.js is loaded once from the hub and shared across all subdomains via standard CORS. Inside, it exposes a thin client over the ALETHEIA REST API plus three rendering primitives that every app reuses: search, comparison, and basket.

// User on baby.geodesicnexus.com clicks a product tile
const id = "hq-p-chd-000017";  // Conventional infant formula
const ctx = baby.activeContext;  // "human_infant"

// gdn-core.js calls ALETHEIA
const product = await ale.product(id, { context: ctx });

// Renders aggregated risk + per-compound classifications
gdn.render.product(product, { lifestage: ctx });

The same call works from any subdomain — only the default context changes. A user on pets.geodesicnexus.com sees the same product profile rendered through context=dog; a user on outdoor.geodesicnexus.com sees context=human_adult; the underlying ALETHEIA call is one endpoint, one parameter difference.

The numbers

Three architectural moves worth stealing

1. One shared module, loaded from the hub

gdn-core.js lives at the hub and every subdomain loads it via standard <script src>. CORS handles the rest. New features, bug fixes, or rendering tweaks ship to all 7 apps simultaneously the moment the hub deploys. There is no per-app build pipeline, no per-app version drift, no per-app dependency upgrade cycle.

2. Domain-mapping JSON as the only per-app config

Each subdomain reads a domain-mapping.json manifest at boot — 1,262 entries assigning each product ID to a primary domain (personal_care, child_products, pet_products, etc.) plus optional secondaries. The manifest is the only thing distinguishing the apps. Adding an 8th app is a config change, not a build.

3. Context as a first-class URL parameter

Every page deep-links its full filter state via the URL: ?mode=compare&ids=hq-c-org-000001,hq-c-org-000033&context=human_adult. Users can share a specific compound comparison from baby.geodesicnexus.com with the infant context selected and the recipient sees the same view, on the same subdomain, with the same data — no auth, no session, no JavaScript state to reconstruct. ALETHEIA's context parameter is built for exactly this; GeodesicNexus just forwards it transparently to the URL.

What's not in this story

ALETHEIA didn't write GeodesicNexus's filter UX, didn't design the comparison-card interaction, and didn't pick the seven domain splits. Those decisions are GeodesicNexus's product choices — the API just made them cheap to ship. If you're evaluating ALETHEIA for a similar architecture, the work you'll still own is the same work GeodesicNexus owned: how your users navigate from intent to answer.