Black-and-white stick comic: four people each hold a torn email corner while the missing CASE center piece blows toward an open window; someone asks for status.

The Case object: durable situation, not a thread

Four threads and no object. A case is one durable situation with evidence, predictions, decisions, verifications — and nobody markets it.

Four threads. No object. That tracks.

A supplier writes on a Tuesday to say the part slipped three weeks. Somebody replies, noted. The mail gets forwarded twice. A project manager pastes the paragraph into a group chat. A scheduler asks whether the client has been told and gets no answer, because the person who would know is on site. A purchaser opens a separate thread about whether to reorder from the second supplier, and that thread never mentions the client at all. Someone updates a row on a board to amber. Six days later the site foreman finds out, from the delivery driver.

Nobody did anything wrong. There were four threads and no object.

So fix the threads, right?

That is the reflex. Better search. Memory on the assistant. A channel for the project so everything lands in one place. All of that helps a little and none of it touches the actual defect, which is that the situation — this part, this slip, this client, this schedule — was never a thing the system could hold. It only ever existed as the overlap between four people's inboxes.

Here is the turn. The unit that is missing is not a better conversation. It is an object with a life of its own.

Call it a case. One durable situation, opened by an observation rather than by a person deciding to file something. It carries the evidence that arrived, kept separate from the interpretations laid on top of it. It carries what the system predicted and when it predicted it. It carries the proposals made, the decisions taken with the name of whoever took them, the executions attempted, and the verifications that came back — or did not. It does not close because somebody is tidy. It closes when the thing is actually resolved and something independent confirms it.

Threads cannot do this and it is structural, not a matter of polish. A thread belongs to its participants; add a person and they inherit a wall of scrollback with no state. A ticket belongs to a queue and closes when the queue is satisfied, which is a different event from the world being satisfied. A workflow run belongs to a definition and ends when the definition ends, even though the situation it was handling is still going. All three are containers for work. None of them is a container for a state of affairs.

Why is that hard to market?

Across two hundred and twenty vendor pages, not one markets a case object as a first-class surface. Zero. It is, by our reading, the largest single opportunity in the corpus and also the least marketable thing we have found, because a case does not photograph well — it is a timeline, and a timeline is boring next to a chat box that talks.

The interesting technical detail — the part that decides whether this survives contact with reality — is that a real situation is never about one object. That supplier mail touches a procurement process, an action taken by a person, a document with a date in it, and a permit or approval downstream. Hang all of it off one identifier and you have made a choice about which of those four is the real one, and you will be wrong within a month. Then somebody writes a script to stitch the other three back together and the ledger stops being trustworthy. The event shape has to carry the relations natively: this happened, and here are the several things it is about.

The near misses are instructive though. Of the seven hundred and twelve product screens we labeled, a hundred and nineteen lead with a domain-object workspace: a schedule, a drawing, an invoice grid, a case dashboard. That family is the closest the market gets, and it is the right family. One security vendor shows cases with a review-required lane. A documents vendor shows a case file where every summary links back to the source page. A construction inspection product shows a finding as an object — drawing snippet, code citation, severity — which is very nearly a case that has only learned one trick. A reconciliation product shows exceptions with an average age in days, which is a case with a clock and no memory.

Each of them has built a case for exactly one kind of situation and stopped. That is not a criticism; it is how good products start. But the thing that makes an operating layer an operating layer is that the object is general — the same shape holds a late part, a stalled approval and a permit that expires in nine days, because the company's problems do not arrive sorted by department.

One clear claim, then. If a product cannot name the object that a situation lives in, it does not have shared truth, whatever its memory does in the demo. Ask for the object. Ask what opens it, what closes it, and who can be wrong inside it.

Thanks for not sanding it down.

Done for today. Ask for the object.

Research base: minimum-os-surfaces E2 · T44 OCED case events · gov-run enforced-vs-asserted (Case object absent) · market-patterns-from-labels domain-object workspace · peer-shelf YC addendum · captures-surface-labels rollup

In this research

Catalog entities mentioned in the post or its research notes.