Every order knows its state

On 4 September 2026 at 13:27, a customer fetched the analysis report on his genome. Two seconds after we sent the message, his mail server had confirmed delivery; a minute later he was logged in, then he had viewed the quotation, then he had fetched four files. Every one of these actions was in our database before anyone asked about it.

Nine days earlier, the same order looked exactly the same from the outside: sent. The recipient was abroad, the access link expired after 72 hours, and by the time he opened it, it was dead. Nobody knew – not he, that he was clicking into an empty address; not we, that he was locked out. We found out because he wrote to us. Those nine days are the reason for what is described here.

The front part of the chain has been described: from question to quotation, from quotation to confirmation, from sample to run, from run to released delivery. At its end stands a message to the customer – and that is where what the system knew used to end. Once the message had left, guesswork began, and it ended only when the customer got in touch.

Anyone who runs a lab knows what follows. “Have you received and secured the data?” is asked by email, answered by email, and the answer goes into a file. Not because anyone wants it that way, but because the system that delivered the data cannot see whether it arrived. The state of an order was kept by hand, in inboxes, with memory as the database.

That gap is closed. The contact history extends the chain from send to action – and turns the state of every order into a fact in the system instead of a question to a person.

Until now the first link was the only one: sent. Now five more follow, each with a timestamp and a person.

• Delivered – the recipient’s server has accepted the message. Evidence, not a hint.
• Access link – issued, valid until, used on. A link that expires before anyone opens it appears as its own entry in the timeline. That is exactly the line that was missing in the case above.
• Logged in – the person is in the portal.
• Viewed – quotation, report, document.
• Fetched – which file, when, by whom.
• Acted – quotation accepted, signature given, task completed.

In between lie opens and clicks. We show them, but we label them for what they are: hints. In a single month, our sending tool counted more opens than messages – mail filters at clinics and institutes open messages and follow links long before a human sees them. An open proves nothing. A login proves everything. A system that treats both alike tells a story that is not true; that is why the history separates evidence from hint, visibly on every line.

Tracking messages is not a new idea. Every sending tool has reported opens and clicks for fifteen years, and anyone content with that needs nothing new. The difference is not whether tracking happens, but what is tracked.

A mail tool measures the message. It knows neither the order the message belongs to, nor the quotation it announces, nor the file behind it. It sees the first link of the chain and calls an open a read. The other five links happen where a mail tool never reaches: in the portal. And the portal belongs to the lab that runs Atlas OS under its own domain.

Atlas OS measures the order. The message is one entry of six, and the unit of truth is not “was the email opened” but “what state is this order in, and what is the next step”. That is the difference between a tool that delivers statistics and a layer that knows the operation.

Two things follow that are worth more to a lab than any open rate. Silence becomes legible: “has read it and is thinking” and “never received it” used to look identical – now they are two states with two answers, follow up or leave alone. And the history is evidence: with genetic data, the question of who fetched which finding and when is not a convenience but what an ISO 15189 audit or a data-protection request demands. Whoever runs Atlas OS has the answer without ever having kept it.

Atlas OS is built for agents and readable by humans. That is not a phrase but an order of operations: the same events a human sees on the order as a timeline are the state from which the agent derives the next step.

Every state has a next logical step. Results ready, not fetched for fourteen days: remind. Invitation delivered, link expired, no login: issue a new link. Quotation viewed, not signed, deadline in three days: follow up. Report fetched: do nothing, the order is on its way. The agent reads the history, recognises the state and prepares the step – the message as a draft, the link as a proposal, the reminder as a task.

Then comes the human. They do not write, do not search, do not ask. They triage: is the step recognised correctly, is it prepared correctly, does it go out. Every writing action shows its preview before execution and waits for a yes. What has disappeared is the handling and the guessing. What remains is the decision – and it should remain.

That is why the contact history is not built as a report but as an event stream. A report is read. A stream is processed.

Every fetch of a result file leaves a line: time, person, file, route. The same applies to the large data packages the portal authorises rather than transports – the address is created at the click, is valid for a limited time, and the click is in the history.

The feedback from the sending route is stored event by event, never overwritten: delivered, deferred, rejected, opened, clicked, with timestamp and raw event. The technical traces of an open – the recipient’s address and mail program – are personal data and are deleted after twelve months; the event line remains, because it belongs to the order, not to the person. An access token never passes through a third-party redirect: messages carrying a key are exempt from link tracking, automatically, because the rule hangs on the content and not on a list.

That is bookkeeping, and it is meant to look like bookkeeping. Whoever wants to know in two years when a finding went to whom and when it was fetched gets a line as the answer, not a recollection.

The occasion was an order of our own. A result delivery, invited three times, every invitation accepted – and still the recipient could not reach his data for nine days, because a link expired while he was travelling. The history would have said on day three: delivered, link expired, unused, no login. The answer to that is a new link, not a question.

Since the history has been in place, delivery, login and fetch have run through the same order – the chain from the beginning of this text. The delivery confirmation arrived two seconds after the send. Between login and the first fetch lay seventy minutes in which the customer was reading. We know that because it is written down.

What is not here is absent on purpose. No customer is named, no finding appears, and results from ongoing joint projects are shown only once the parties release them. Whose data we process decides when it is talked about.

Atlas OS today keeps three ledgers per order. The run: which tool, which version, which checksum, from when to when. The delivery: which file, released by whom, to whom. And since this week the contact: what reached the customer and what they did. Together they describe an order from the arrival of raw data to the recipient’s hands without a gap in which anyone would have to guess.

That is the ground on which agents can work. An agent needs no interface and no summary; it needs the state, and it needs it complete. Three ledgers that interlock are that state. What comes in the next few weeks follows from the same structure: every outgoing message sets an expectation with a deadline, and whatever misses the deadline reports itself – on the operator’s start page and in the agent’s list. Customers’ replies attach themselves to the order instead of sitting in an inbox. The history becomes two-sided.

Every lab that runs Atlas OS under its own domain has this history for its own customers – in the layer it owns, not in a tool beside it.

The ambition is the same as for the run, so it is stated here once more: no order should stand for longer than a day in a state nobody knows. The agent sees it first. The human decides.

Order, run, delivery and contact history live in the portal at app.atlasbiolabs.com. How the path from raw data to released result works is described here.