Same Patient, Different Task at Every Moment
For the same patient, what can be done and what must be done differs from moment to moment. What decides that? The object’s state.
As we said in Part 2, in an ontology an object is not just a bundle of data — it is an entity with state. A patient may be under consultation, or surgery-confirmed, or in the 4th session of a 10-session package. A laser device may be running, or under maintenance, or unusable. And this state is not merely a label. It opens and closes the range of actions available right now. Pre-op checks unfinished — no surgery guidance can go out. A laser under maintenance — no procedure can be booked to it. State is the gatekeeper of action.
We Record State, Not Value
That’s why we record state, not value.
Because whether the accumulated usage of a laser tip is normal or nearing replacement decides the action — more than the raw number does. Because whether filler inventory is sufficient or below minimum decides the order — more than the raw count does. A number has to be re-read and re-interpreted by a person. A state calls the next action by itself. This is why the numbers on the reports you look at every day so often fail to become action. Numbers have no threshold; without a threshold, there is no action.
The Trace of How the State Changed Remains
State-centric records have one more power: the history of how the state changed.
Systems that stack values record “the number was X that day.” Systems that stack state record “at this time, for this reason, it moved from ‘consulting’ to ‘surgery-confirmed,’ or from ‘normal’ to ‘caution.’” A few days later, when something needs to be traced, this difference is decisive. Faced with a list of numbers, interpretation debates start again. Faced with a state history, what the hospital knew and what it did at that moment is right there. The hospital’s days no longer just pass and vanish — they accumulate as a history you can look back on.
How It Runs on the Ground Right Now
This is not abstract. At the T Hospital we support in operations, this is how it runs today.
A patient’s surgery preparation passes through a series of states in order. Guidance is sent, surgery is judged possible, pre-checks are completed, final guidance is sent, confirmation is reached. When the operator advances the state by one step, the guidance matched to that new state goes to the patient automatically. The consultant does not write each text. A state change is the beginning of an action.
Supplies are the same. When the stock of an item drops to the “minimum inventory” state, an order is prepared automatically. Nobody has to check the storeroom and count. The state calls the action first. That is why the supply shelf isn’t empty on the morning of surgery. In your hospital, this place is where the sutures, the fillers, the laser tips will sit.
States That Call Action Exist Outside the Exam Room Too
One more scene familiar to every director. The patient who received a quote and left saying, “I’ll think about it and get back to you.”
Such patients arise every day at every hospital. The problem is what happens next. In most hospitals, this patient lingers in the consultant’s memory, notebook, or somewhere in an Excel file. A busy week passes, they’re forgotten, and weeks later they undergo surgery at another hospital. Ad spend spent to bring them in, an hour spent on consultation, and lost on the last step.
In a state-centric hospital, this patient exists in the state of “awaiting decision.” And that state calls the action. At the predefined moment, a callback task appears for the consultant, and the predefined guidance goes to the patient. Not because the consultant is diligent — because the structure does not forget. The instant work that used to rely on someone’s memory becomes the work of a state, the hospital’s outcomes uncouple from a given day’s mood.
Automation Is Not Guessing
Let us be clear about one thing. What we mean by “automatic” is not AI deciding on its own to move.
Which action goes out from which state is fixed inside the structure in advance, jointly by the hospital’s operators and us. What runs automatically is a judgment a human has already made — never a machine’s improvised guess. The principle of hallucination-free AI from Part 1 applies here too. When a genuinely new judgment is needed, a person always decides. Only the repeated execution of already-made judgments is delegated to the system. Your hospital will never move in a way you did not decide upon.
When state changes, what can be done changes. That is why we record state — not value — and pack the human’s judgment into the structure so the system executes it.