The map is not the receipt

Picture a procurement lead, call her Devi, with a supplier plot open on one screen and an AI assistant on the other. The supplier swears the cocoa came from land that has not been cleared since before the cutoff. Devi asks the agent. It comes back fast and sure of itself: forest loss looks clear in this area - no recent deforestation detected.

Good answer. Useless answer.

Because the next person in the chain, an auditor, a customs officer, a lawyer, asks Devi one flat question: how do you know? And "the AI looked at it" is not something you can put in a file. She cannot point to which patch of ground the agent checked, what data it read, when that data was captured, or whether the same question tomorrow returns the same answer. The agent produced a sentence. What Devi needed was a fact she could hand to someone else and have them land in the same place.

A coordinate is not evidence until it can be replayed.

That gap, between an answer that sounds settled and a fact you can stand behind, is what a small open-source project called emem is built to close. It is worth understanding not because every operator needs to adopt it this quarter, but because it names an artifact most real-world AI workflows are missing: the field-fact receipt.

What emem actually changes

The project's own README puts the problem better than I can: "Ask an AI agent what is on the ground at 19.07° N, 72.87° E and it will guess." A language model knows a lot about places in general. It does not know what is true at this place, right now, in a way it can prove.

emem's move is to stop treating a location as loose text and start treating it as an address with a paper trail. It cuts the Earth into fixed cells, each about 9.55 meters across at the equator, and gives every cell a stable handle. Instead of arguing about decimal places in a coordinate, a place becomes a named thing two systems can agree on.

A measurement at one of those cells becomes a fact: an elevation reading, a rainfall total, a forest-loss flag, or a satellite embedding. The fact is built from open data, then named by the BLAKE3 hash of its canonical bytes. Same bytes, same name, every time. The responder signs that fact with an ed25519 key and hands back a receipt. A client can check the signature offline, without calling home and without opening an account.

There is a detail in the agent guide that matters more than it looks. emem keeps two clocks. One is when the world was observed. The other is when the system signed off on it. So you can ask not just "what is true here" but "what did we believe about this place on the day we made the decision," then replay the answer later. If you have ever tried to reconstruct why a call was made six months ago, you know why that second clock is the whole game.

None of this is magic. It is plumbing. The point of the plumbing is that the agent stops being the source of truth and starts being a thing that cites one.

The field-fact receipt

We have written before about giving agents receipts for the work they do. This is a cousin of that idea, pointed at the physical world. The receipt for customer work answers "what did the agent do." The receipt for a field fact answers something harder: "what is true about this piece of ground, and what is that truth allowed to decide."

That is the artifact to carry out of this whole conversation. Before you let an agent use real-world data to make a call, write down the receipt it has to produce.

Scroll sideways to see all 2 columns.

Field	What it pins down
Place handle	The stable cell or parcel ID, not a loose lat/long that drifts by source
Upstream source	Which open or licensed dataset the fact came from
Observed fact	The measurement itself: forest-loss flag, elevation, rainfall total
Observation time	When the world was actually seen
Signing time	When the system committed to this being its answer
Fact identifier	The content hash, so two parties can confirm they are looking at identical bytes
Signing key	Whose key signed it, so you know who is accountable
Verification method	How a third party checks the signature, ideally offline
Allowed decision	The one business call this fact is permitted to support, and nothing past it

That last row is the one people skip, and it is the one that saves you.

A forest-loss flag might be perfectly good for "flag this plot for human review" and completely unfit for "auto-clear this shipment through customs." Same fact. Different blast radius. If the receipt does not say which decisions it backs, someone will eventually stretch it to cover one it never should have.

You can build a receipt like this without emem. emem just happens to give you most of the columns for free, with the hash and the signature already done. The discipline is the deliverable here, not the tool.

Where this matters, and where it does not

The obvious home is deforestation due diligence. emem has a dedicated endpoint that produces a signed, Annex II shaped Due Diligence Statement for operator-supplied plots under the EU's deforestation regulation. Geolocation and the forest-loss read become signed and replayable. If you are staring down EUDR-style obligations, a signed geospatial fact beats a screenshot and a vibe.

But the same documentation is careful about the boundary. The Earth-observation part can tell you whether the ground changed. It cannot tell you whether the activity on that ground was legal. emem surfaces that as an explicit legality disclaimer and leaves the judgment to the operator. That is the right instinct, and it generalizes well past EUDR. A signed satellite fact is excellent input to a compliance decision and a terrible substitute for one.

The same logic travels:

• Insurance and claims. A signed elevation and rainfall fact for a flooded address is a strong piece of a claim file. It is not, by itself, a payout decision.
• Facilities and field service. "Was this site accessible after the storm" is a good question to answer with replayable ground data, then route to a human dispatcher.
• Site due diligence. Comparing two parcels for a buy decision is where a stable place handle and a timestamped fact earn their keep, as evidence under the analyst, not as the analyst.

Underneath all three: let the signed fact be the input to a decision a person or a policy still owns. The moment the fact silently becomes the decision, you have rebuilt Devi's problem with extra steps and a nicer-looking PDF.

How to pilot it without making a mess

Do not roll this across the org. Take one workflow where a wrong real-world answer actually costs something, then wire up exactly that.

Start by writing the receipt before you write any integration. Which place handle. Which source. Which decision it is allowed to touch. If your team cannot agree on the allowed-decision row, that is not a tooling problem, and no signature will fix it.

Then mind how you ask. emem's privacy docs note that GET query strings are logged for 30 days with a hashed IP, while POST bodies are not logged. If the place name itself is sensitive, such as a supplier you have not announced or a site you are quietly evaluating, send it in a POST, not strung into a URL. This is the same hygiene we wrote about with research-agent query trails: the thing you search for can leak as much as the thing you find. The read endpoints do not need an account or an API key, which is convenient and is exactly why you should think about what you put in the request line.

Define verification as a real step, not a checkbox. Someone other than the agent should be able to take the receipt and confirm the signature. If nobody ever checks, the signature is decoration.

And keep a record of what the agent believed and when. We have made this case for agents in general, that they need a state ledger before they get more context, and it is doubly true when the state is a claim about the physical world that someone may litigate. emem's two clocks give you this if you keep the receipts. The broader version of this thinking lives in our AI workflow controls notes.

One workflow. One receipt shape. One decision the fact is allowed to support. Then widen.

Devi's problem was never that the AI was wrong. For all she knew it was right. Her problem was that "right" was not something she could hand to anyone else. A map told her what the place looked like. What she needed was a receipt that told her, and the auditor after her, what was true, where, when, and on whose signature.

If you have an agent reaching into the physical world to make calls, supplier land, flood claims, site checks, field operations, the useful first move is not picking a tool. It is mapping the field-fact receipt for one real workflow before the agent decides anything. If that workflow is already creeping into your backlog, BaristaLabs can help turn it into a narrow process automation pilot with the evidence boundary defined first.

Map a field-fact receipt for one real-world workflow