Your system of record can't tell you when it's wrong

I left Atlassian this year to join Noah Wasmer as co-founder and CEO of Ontollo. We had built together before, infrastructure systems for F500 at VMware and a project management platform to serve 300K customers at Atlassian. The mission he was already working on was one I'd spent the last six years preparing for without knowing it.

The work I'm proudest of leading at Atlassian is the Teamwork Graph, the context layer underneath Atlassian’s AI offering that lets it reason about how work is connected across functions and different systems of record. Building it with our teams and customers taught me something I haven't been able to stop seeing since. Most large organizations don't have a data problem. They have a system of record compatibility problem, and siloed workflows have relied on human glue for decades until agents came to crash the party.

Illustration of the Atlassian Teamwork Graph (Source)

Meanwhile, Noah was seeing this same challenge but in very different industries outside the Atlassian ecosystem where the work product was physical not digital - energy grids, agriculture, and healthcare,. The AI gains of the last few years have landed almost entirely with people who work in front of screens. The people running sites, plants, farms and fleets are still waiting, and not because AI can't help them, but because AI needs a current picture of what's actually happening, and for most physical businesses that picture doesn't exist in a way agents can access.

I didn't initially have the construction industry on my radar, but that immediately changed when I attended the BuiltWorlds Construction Tech Conference in Chicago last month. I went mostly to learn, and spent two days listening to people describe a problem I had spent six years inside of. Different vocabulary, same shape. Everyone had the data. Almost nobody could act on it.

I'm new to this industry. The operators I talk to every week know things about delivering a project that I may not fully understand for years. But I have built the layer operators across so many industries are now racing to architect and build, and there's a step in the sequence that I keep seeing skipped.

Where systems of record fall short

Construction's systems of record are a real achievement, and I want to be precise about what they're good at, because the argument I'm making isn't that they failed.

A record answers one question extremely well: what happened. Who submitted the RFI, when it was approved, which drawing is current, who signed off. On a project generating tens of thousands of documents, answering that reliably is the difference between a defensible position and a claim you lose. That capability was hard to build and it took a long time to adopt.

It's also, structurally, a description of the past.

The blind spot

Here's the thing about a system of record that took me a while to appreciate at Atlassian, and that I think matters more in construction than it did in software.

A record is only as current as the last person who updated it. And it has no way of knowing when that was long enough ago to matter.

Jira never told us a ticket's status was stale. It told us the status. If a team had stopped updating a board three weeks earlier, that board looked exactly as confident on day twenty-one as it had on day one. The data was clean, the system was working as designed, and the picture was wrong. Nothing in the architecture could flag it, because a record stores what it was told, not whether what it was told is still true.

Construction runs a version of this problem with much higher stakes. The schedule says one thing. The field is doing another. The gap between them isn't a data quality issue, it's a timing issue, and it hides in the open quietly.

The Navigant Construction Forum studied 1,362 projects containing more than a million RFIs, and found that more than one in five never received an answer at all. That research is from 2013 and the tooling has improved a great deal since. But look at what the finding describes, because the shape of it hasn't changed.

Every one of those RFIs sat in a system that knew it existed. It had a date, a recipient, a status. The record was complete and correct by its own standards. What it could not do was tell anyone that one of those open items was holding up a crew, or that its own picture of the project had drifted from what was happening on site.

The missing middle layer

This is where the sequence matters, and where I think the industry is trying to skip a step.

Everyone is now attaching agents to systems of record. That produces something genuinely useful. An agent can search, summarize and draft against what the record contains, and that saves real hours. At Atlassian, that class of automation was the first thing that worked for us - removing the toil from many tasks.

But an agent acting on a record inherits the record's blind spot. It will act confidently on information that stopped being true two weeks ago, and it won't hesitate, because nothing in its inputs signals doubt. Automating action on a stale picture doesn't fix the picture. It gets you to the wrong place faster.

What has to come first is a continuously current model of the work. At Ontollo, we call it a system of reality: a layer that maintains a live picture of what's actually happening, understands how the pieces relate to each other, and, critically, knows where its own picture has gone stale.

Ontollo System of Reality, showing signals, business drivers ,and knowledge being transformed into action

That last part is the piece I'd underline. A system of reality can tell you that the schedule and the field haven't agreed in over a week, that a submittal status hasn't been touched since the material shipped, that this part of the project is currently running on assumptions. A system of record structurally cannot do this. It has no representation of its own currency.

• A system of record tells you what happened.

• A system of reality tells you what's true right now, and where it isn't sure.

• A system of execution acts on that. 

The order isn't a preference. Execution without reality is confident action on outdated facts, which on a jobsite is more expensive than no action at all.

Why this doesn't arrive as a feature

The reasonable counterargument is that the platforms are building this now. Agent builders, custom skills, teach-the-AI-your-process. Give it eighteen months.

Having done it once, I don't think this is mainly a technical problem.

A live model of the work requires deciding what the objects are, which relationships are load-bearing, and what a change in one implies for another. At Atlassian those decisions took us years, and they were specific to how our company operated. Nobody outside could have made them for us, and they wouldn't have transferred cleanly to another company.

The same is true here, only more so. A self-perform contractor and a construction manager at risk don't have the same model of how their work connects. Neither of them has the one that ships in the box.

It also requires capture where the work happens. A picture of reality that depends on someone walking back to the trailer to type is stale before it's entered, which is why voice and scanning on mobile aren't conveniences in this design. They're load-bearing.

So the question isn't whether this model gets built. It's who builds it and who owns it afterward. The firms that get real value from AI on their projects won't be the ones running the most agents. They'll be the ones with a current, connected picture of their own work, owned by them.

Three questions worth asking

If you're evaluating AI products right now, the feature list won't separate the options. Everyone has agents, pre-built workflows and orchestration. These three questions will tell you more than any demo:

1. Can it tell me when its own information is out of date?
2. Can it tell me what a delay on one thing means for the rest of the project, or only that the delay happened?
3. If we move platforms in three years, does the model of how our work connects come with us?

I'd push hardest on the first one, because it's the one nobody expects and the answers are revealing. A system that can't tell you where it's uncertain is asking you to trust all of it equally, and no operator I've met trusts their systems that evenly.

None of this argues against systems of record. They're exactly the right place for records. It argues that a record was never designed to be a live picture of the work, and that treating it as one, then automating on top of it, is how a firm ends up with an immaculate account of a project it can't steer.

That live picture is what we're building at Ontollo, and we think it belongs to the builder.

If any of this resonates or there's something you'd challenge, I'd love to hear your thoughts.