There is a particular Tuesday morning Jour-fixe, on the third floor of an unfinished office building in München-Sendling, that I would like to describe carefully. The Projektsteuerer is chairing; the Bauleiter is reading a list of overdue items from a paper printout. He pauses on one — a missing fire-stopping detail in the ventilation chase — and says, without looking up, "das machen wir bis Mitte nächster Woche, wenn die Lieferung kommt." The Polier nods. The Projektsteuerer's assistant writes it down. The room moves on.
I want to draw your attention to what just happened. A deadline was set, agreed, and recorded. The deadline is, on paper, "mid next week, if the delivery arrives." If you ask our knowledge graph what that means, it has to make several decisions, and none of them are the kind a database typically makes.
Three deadlines, one sentence
That sentence contains at least three distinct deadline-objects, and they don't agree.
The calendar deadline is "mid next week" — somewhere around Wednesday or Thursday. The contractual deadline, if you read the building contract this defect was logged against, is forty-five working days from the original Mängelanzeige, which puts it more like six weeks out. The operational deadline — what the Bauleiter actually means — is "before Friday afternoon's Bauherrenrunde, because I do not want to talk about this with the client again."
For three months we tried to fold these into one. We picked the most legally binding one and called it the deadline. It was the wrong choice in every single direction. The Bauleiter does not care about the contractual deadline; the client cares only about the contractual one; the lawyer cares about both, but only when something has already gone wrong.1
"In a Pre-Con office and on site alike, a deadline is a small political object. It has authors, witnesses, and a half-life. We were modelling it as a timestamp."
The conditional clause
"…if the delivery arrives." This is the part that broke the most schemas.
In every protocol I have read this winter — Jour-fixe-Protokolle from the Projektsteuerer, Bauprotokolle from site, Vergabevermerke from the procurement desk — roughly one in three deadlines has an explicit precondition. "Wenn das Wetter mitspielt." "Sobald der Statiker freigibt." "Vorausgesetzt, der Auftraggeber bestätigt die Mehrkosten." These are not flavour text. They are the actual contract.
The first version of our model treated them as comments — string-typed metadata on a deadline. Useful for display, ignored by every retriever. Then we tried treating them as boolean flags ("conditional: true"). That was worse, because it threw away the only thing that mattered, which was what the condition was. v0.4 of the schema models them as first-class entities: a Frist can carry a depends_on edge to one or more Conditions, each of which has a status, a responsible party, and its own provenance.
Frist — and seven satellite nodes that together capture what it actually means. The asserting agent and the recording document are both first-class, because the same sentence in a different document means a different thing.
What the field taught us
Six things, roughly in order of how surprised I was to learn them.
- Deadlines are negotiated in the room, not in the document. By the time a Frist appears in a Jour-fixe- or Bauprotokoll it has already been through three rounds of mutual concession. The schema needs to model the concession history, not the result.
- "Nächste Woche" is almost always Thursday. Not Monday, not Friday. Thursday is the day work is delivered before the weekend; Friday is the day to inspect. We learned this from the Polier; we have not yet found it written down anywhere.
- Weather is a first-class condition. About 18% of all conditional deadlines on outdoor work in our corpus are gated by Wetter. Our model now consumes weather forecasts to estimate condition-resolution probability.
- Suppliers are worse than weather. About 27% of conditional deadlines depend on a Lieferung; about half of those slip on first promise.
- The Bauleiter's tone of voice is data we have not figured out how to capture. A deadline said with a smile and a deadline said with arms crossed are not the same deadline. We currently throw the difference away.
- The single best predictor of a deadline being met is not any property of the deadline itself. It is whether the Bauleiter has agreed to the deadline publicly, in front of the Auftraggeber. We have an unvalidated hunch that this generalises beyond our corpus.
What changed in the model
Concretely, two things.
First, every Frist in the production graph now carries up to three interpretations (calendar, contractual, operational), each with its own date, confidence, and asserting agent. Queries can ask for any of them; the default — for the standard "is this overdue?" check — is operational, because that's what the Projektsteuerer actually means.
Second, conditions became their own subgraph. A Condition resolves over time (open → satisfied → failed → cancelled), and the deadline it gates inherits the resolution. We compute "probability the deadline holds" as a function of the condition's resolution status and a small empirical prior. Customers who saw the first dashboard mocking this up said, almost in unison, that this was the first time their software had agreed with their intuition.
A confession
I came onto this project from an academic background in temporal logic. I assumed, embarrassingly, that the gap between formal time and construction-site time was a matter of more formalism — better operators, finer-grained intervals, a richer modal calculus.
It is not. The gap is a matter of provenance. Construction-site time is a chorus of opinionated humans, each with reasons, each with credibility, each with a stake in the outcome. The model gets better not by making the time-points sharper, but by making the singers louder.
— L., Munich · BV Riemerschmidt, 09 February 2026.