wherebase

Why a memory layer · why 4D

A layer that remembers where and when, for whatever sees and whatever asks.

Detectors tell you what is in a frame. Maps tell you where things are supposed to be. Neither remembers that the keys were on the hook at eight and in the kitchen at nine, or that a pallet moved overnight, or that a shelf usually holds a red toolbox on Tuesdays. Wherebase is the memory in between: one index over x, y, z and t that any camera can write to and any AI can ask.

What people use it for

Six questions, one memory.

Each of these is a sighting written once and a question asked later. The same rows serve all of them; only the device and the agent change. The full list, in plain language, is on the use cases page.

01 · At home

Where are my keys?

“Last seen on the hook by the door, two hours ago. Before that, the kitchen table.”

A phone, a pendant or a fixed camera notes what it sees; the question comes from a voice assistant, a chat, or the pendant itself. The answer includes the one before it, which is often the one you need.

People who lose things · blind and visually impaired users · elder care

02 · Warehouses and facilities

What moved since the last patrol?

“The pallet in aisle 3 moved four metres. A new box by the loading door.”

A robot on its rounds writes sightings with place and time. The next morning the question is not “what is here” but “what is different”, and that is a comparison the index does in one call.

Mobile robots · inspection drones · facility managers

03 · Fleets

Does every robot know what one of them saw?

“Robot B found the cart at bay 7 at 14:02. Robot A, you are nearest.”

One space, many writers. Each device keeps a cache and syncs by revision, so a sighting by any of them is a memory for all of them, with the time it happened.

Robot fleets · AMR vendors · logistics

04 · Agents

Can my assistant remember my space between chats?

“You put the charger in the desk drawer on Monday.”

Claude, ChatGPT or your own agent gets four tools over MCP: where, remember, changes, ask. The memory outlives the conversation and the model, so switching assistants does not mean starting over.

Anyone with an AI assistant · developers of agents

05 · Care

Is everything where it usually is?

“The walker has been in the hallway since morning. The pill box has not moved today.”

Not surveillance: a timeline of objects, not people. A carer sees what changed and what did not, and the person at home can ask the same memory out loud.

Carers · assisted living · families

06 · Builders

One API for a phone, a pendant and a robot?

“Same rows, same questions, whichever camera wrote them.”

Write sightings from anything with a camera and a clock. Query from anything that can make an HTTP request. The detector is swappable: a tiny on-device model today, a vision language model when you want names like “blue mug”.

Developers · hardware teams · researchers

Why a layer

Cameras change. Models change. Agents change. The memory should not.

Every part of a physical-AI stack is moving. Detectors go from eighty labels to open vocabulary in a year. Assistants go from one vendor to another in a month. Hardware goes from a laptop webcam to a pendant to a robot. If memory lives inside any one of those, it dies when that part is replaced.

So Wherebase is deliberately the thing in the middle: a store with one shape of row, label, place, time, confidence, and one shape of question. Anything that sees can write. Anything that asks can read. The index does not care whether the label came from a 7 MB model on a phone or from Claude looking at a photo, and it does not care whether the question came from a speaker on someone's chest or from a chat window.

That is also why it is a service and not a library you embed: a fleet needs one memory, a household needs one memory, and an agent that runs somewhere else needs to reach it. The open-source engine underneath can still run in-process when that is the right shape.

AsksClaude · ChatGPT · your agent · a pendant · a robot planner
over MCP tools or the HTTP API: where, remember, changes, ask
RemembersWherebase
one index over x, y, z, t · revisions for device sync · spoken answers at the edge · novelty and consolidation from the engine
SeesiPhone · ESP32 pendant · Raspberry Pi depth rig · any robot camera
with any detector: on-device COCO, a vision language model, or your fine-tune

Why 4D

Why not just put detections in SQL?

You can, and for a single camera and simple lookups you should. A table of label, x, y, z, t answers “where was the cup last” with one index on label and time. It stops answering well the moment the question has space and time in it at once, because nearness in space and time is not a column. Here is where the two part ways.

The questionDetections in SQLWherebase
What was near here, around then?A range on x, a range on y, a range on z and a range on t: four conditions, a composite index that favours one of them, and a scan over the rest. Fine at thousands of rows, slow at millions, and the planner's choice changes with the data.Place and time are one address, not four columns. A box in space and a window in time is one lookup, and it stays one lookup at millions of rows. Near in the world is near in the memory.
Where was it, before that?Two queries, or a window function, and you hand-roll the phrasing.Every object has a history, so “last seen, and before that” is one question, and the answer comes phrased for speech.
What changed?A self-join of the table against itself across two time windows, per label, per room. It works, and it is the query nobody wants to maintain.“What changed?” is built in: what is new, what moved and how far, what has not been seen, per room, over any window.
Is this new?Not a query. You would need a similarity search over embeddings and a threshold you tune by hand.The memory knows what it expects to see and scores how surprising a sighting is, so “this is new” and “have I seen this before” are answers, not thresholds you tune.
What does the memory look like after a year?A table that only grows, or a cron job that deletes. Both lose the past.It ages like memory: recent moments stay sharp, old ones become summaries, storage stays bounded, and last year is still answerable.
Ten devices, one memory, patchy networksReplication, conflict handling and caches, all yours to build.Many devices write into one memory. A device that was offline catches up with exactly what it missed, and nothing is written twice.
Different scalesA room and a city need different indexes and different units.One address space from a shelf to a warehouse: the memory sharpens where the data is dense, with no second schema for the city.

Property 1

One address for place and time

Where and when are stored together, at any scale, so a question with both in it is one lookup. Nothing at the edges of a box is missed: the answer is exact, not approximate.

Property 2

Memory that ages, and keeps the past

Recent moments are kept in full; older ones are kept as summaries. Storage does not grow without limit, and the past does not vanish: last winter is still answerable, just less finely.

Property 3

It knows what is new

The memory carries an expectation of what should be there. A sighting that breaks it gets a calibrated “this is new” score: a safety signal for a robot, and the reason a companion can say so instead of silently storing everything.

Where SQL is the right answer. One camera, one room, a few thousand rows, and questions that are always “the latest row for a label”: a table and an index are simpler, and you should use them. Wherebase earns its place when there is more than one device, when time is part of the question, when the memory must outlive the stack around it, or when “what changed” and “is this new” are questions you need to ask every day. The engine is available on request, with its benchmarks, including the cases where it loses.