geo.qaHow it’s built.
geo.qa is the premium upgrade over the open emem.dev protocol. Edge encoding on the cameras and sensors you run, satellite facts drawn from that open ledger, a layered representation over real foundation encoders, a fact algebra that never guesses silently, hard per-tenant isolation, and a memory you can train your own world models on.
Chapter I
The encoder runs on the device.
Most platforms ship you the picture and embed it in a cloud you don’t control. For the cameras and sensors you run, geo.qa encodes at the edge of capture, so a frame becomes a latent before it ever leaves the source. Only the latent moves on; a decoder resolves it onto the cell lattice. Satellite scenes arrive already encoded, as emem.dev embeddings.
Capture device
The sensors you run: drones, fixed and mobile cameras, ground sensors, plus satellite feeds from emem.dev. The fleet, not the single feed, is the unit.
→Encode → latent
The encoder runs at the edge of capture. A scene collapses to a latent vector at the source, so bandwidth and exposure both drop before anything is transmitted.
→Only the latent travels
No raw imagery leaves the boundary. What moves to the ground is the compact representation, not the pixels it was made from.
→Ground decoder
On the ground, the decoder resolves each latent onto its cell, its bands and its tslot. One shared, addressable Earth memory.
→File a signed fact
Each value lands with its source, its hash and an ed25519 signature. Nothing is overwritten; the past stays queryable.
The contract the rest of the system depends on is small. A device observes a place at an instant with whatever sensors it carries, and hands back a latent. Everything downstream, from recall to find_similar to the JEPA forecast, reads that latent and the facts it decodes to. None of it ever touches the raw frame.
That single split is what makes the rest possible. Because the picture stays at the source, a tenancy can run sealed and still be audited; because the latent is uniform, twelve different modalities can write into the same address.
# the only signature downstream depends on encode :: Place × Time × Sensors → Latent # where Place = Cell # a stable ~10 m address Time = Tslot # a bi-temporal slot Sensors = whatever the device carries Latent = a vector, # signed beside its receipt # never the raw scene
Chapter II
The representation is layered.
There is no single magic dimension. Different jobs want different geometry, so geo.qa keeps several representations side by side over real, pre-trained foundation encoders, and routes each query to the layer that fits it.
| Layer | Dims | Encoder / source | What it is for |
|---|---|---|---|
| GeoTessera | 128‑D | Sentinel‑1 / Sentinel‑2, 10 m | Similarity at scale. Cosine k‑NN behind find_similar: “show me places that look like this one.” |
| Clay v1.5 | 1024‑D | Sentinel‑2 (CLS token) | A foundation encoder for optical scenes: the dense semantic backbone for a place’s appearance, the 1024-D CLS token over Sentinel-2. |
| Prithvi‑EO‑2.0 | 1024‑D | HLS (Harmonised Landsat–Sentinel), CLS | A second foundation encoder trained on HLS with a different prior. Where it and Clay disagree, the divergence is the signal. |
| BGE semantic | 768‑D | text · captions · reports | Semantic memory search. Free-text questions and human field notes resolve into the same place graph. |
| State cube | 1792‑D | wired bands, packed | The full measured state of a place at a time: the wired bands packed into a 1792-D state vector, the substrate models train on. |
The encoders are stacked, not blended into one number. When you ask for the nearest look-alike of a parcel, the query goes to GeoTessera’s 128-D space, where cosine distance is cheap and meaningful. When you ask what a scene is, it goes to the foundation encoders. When you ask a question in words, it goes through BGE. When you want to predict, the model reads the 1792-D state cube, which holds every wired band for the cell at that instant.
Keeping Clay and Prithvi both around is deliberate. They were trained on different data with different priors, so where they agree you have corroboration, and where they diverge you have a signal worth surfacing rather than averaging away.
Chapter III
One address, three kinds of fact.
Every place resolves to a cell, every measurement to a band, every observation to a tslot. The three compose into a fact. A fact is never a silent guess.
/.well-known/emem.json.Three fact types, and a rule against silence.
delta, mean, trend, rate or anomaly, carrying the CIDs of the primary facts it was computed from. The derivation is itself part of the receipt.outside_coverage, gpu_unavailable, no observation in the window. The absence is the answer, and it is signed too.Chapter IV
Two stores, one shape.
Postgres is the source of truth for what was observed. Vespa is the source of speed for finding it. Facts are written once to truth and projected into the index; the two never disagree about what happened.
truth · Postgres
-- one schema per tenant; RLS below the app CREATE TABLE org_acme.memory ( cell bytea NOT NULL, -- cell id band smallint NOT NULL, tslot bigint NOT NULL, -- u64 slot value double precision, latent vector, -- layered dims prov bytea NOT NULL, -- cbor blob sig bytea NOT NULL -- ed25519 ); ALTER TABLE org_acme.memory ENABLE ROW LEVEL SECURITY;
Each tenant lives in its own schema, org_{id}. Every row carries its CBOR provenance blob and ed25519 signature, so the truth store is self-verifying. Row-level security enforces tenancy below the application layer, not just in front of it.
speed · Vespa
| Reference deployment | value |
|---|---|
| p50 recall | ~2.4 ms |
| p99 recall | ~11 ms |
| index span | ~14 M cells |
| top-k default | 12 |
| distance | angular (cosine) |
| grouping | per-tenant content group |
Vespa keeps the layered vectors hot in a per-tenant content group. Recall runs angular distance over the right layer for the question, returns the top-k cells, and those exact cell ids travel back into the answer and into its receipt. The agent can name every observation it leaned on, by id.
Chapter V
Two fences, no gate between them.
An agent in tenant A cannot reach a cell in tenant B even when it asks for the exact same coordinates. There is no replication path that crosses the boundary, so the only thing that leaves an org is what a human in that org chooses to share.
Chapter VI
Train your own model on it.
The unified memory is not only something to query. Every dated, multimodal fact is supervision for a model you train, own, and deploy: JEPA dynamics, forecasting, detection, all of it learned inside your boundary and never leaving it.
# train a JEPA dynamics model on your own memory (Max plan) curl -s -X POST https://geo.qa/api/world-model/training \ -H "Authorization: Bearer $GEOQA_KEY" \ -d '{ "bands": ["optical","sar_vv","lst","weather"], "horizon": "7d" }' # → { "job_id": "wm_…", "status": "queued" }
The pattern is the same one most world-model labs ship as a single pre-trained model: fuse modalities into one representation, then learn dynamics on it. The difference is ownership. Here you fuse your modalities into your memory, train your model on it, and deploy that model where the data already lives. emem’s public JEPA head is a starting point, not a finished product; the point of geo.qa is that you bring or train your own.
Chapter VII
It speaks emem.dev.
emem.dev is the open, free public Earth memory: a signed, content-addressed ledger anyone can read with no keys. geo.qa is the private upgrade on top, and it extends the same protocol, so public and private facts cite the same way.
| The open protocol, in numbers | count | what it covers |
|---|---|---|
| source schemes | 46 | EO and ground feeds: Sentinel-2 (10 m, ~5 d), Sentinel-1 SAR, MODIS NDVI (8 d), ERA5 (daily), Hansen GFC (annual), JRC surface water (monthly), Met.no, FIRMS fires, CAMS air, SoilGrids, Overture buildings |
| composition algorithms | 160 | indices, fusions and derivations that turn raw bands into facts |
| wired bands | 124 | named measurement slots; 42 callable by name today |
| MCP tools | 81 | emem_locate, emem_ask, emem_recall, emem_find_similar, emem_verify_receipt, domain shortcuts and physics solvers |
| REST paths | 93 | the same surface over HTTP for non-MCP clients |
| topics | 27 | event streams agents can subscribe to |
Where private and public differ, and where they agree.
| aspect | private · geo.qa | public · emem.dev |
|---|---|---|
| representation | layered (128 / 768 / 1024 / 1792) | signed public facts + state cube |
| licence | tenant-private, you own it | open commons, free to read |
| addressing | H3-resolved, per-tenant schema | cell64 (~9.55 m, non-H3) |
| capture | custom devices, encode at source | already-public EO sources |
| hash | BLAKE3 | BLAKE3 |
| signature | ed25519 | ed25519 |
| receipt | canonical CBOR | canonical CBOR |
| verify offline | yes | yes |
Because the receipt format is shared, an agent can cite a private fact and a public one in the same breath, and a third party can verify both offline from the public key. No callback to us. No trust in our servers required.
Read the spec, or build.
The live endpoints, the OpenAPI spec, and the MCP config live in the docs. Anything outside that is a conversation.
geo.qa · a vortx ground decoder · emem.dev open protocol