Reasoning Across Platforms: When the Answer Lives in Three Systems

Here is a question a development director asked in a meeting recently, and it is worth examining because it is completely reasonable and almost impossible to answer.

Which of our delayed activities have unapproved commitment changes sitting behind them, and what does that do to the cash position this quarter?

Every component of that question exists in a system somewhere. The delay is in the schedule tool. The commitment changes are in the PMIS. The cash position is in finance. Nobody in the room could answer it, and the reason is not that anyone had failed to do their job.

Every component of the question exists in a system somewhere. Nobody in the room could answer it, and the reason is not that anyone had failed to do their job.

Why this is structurally hard

The instinct is to treat this as an integration problem that somebody has neglected. It is not, and understanding why matters before anyone commits budget to solving it.

Each system holds a different identity for the same real-world thing. The schedule knows an activity by its ID and its WBS position. The PMIS knows a commitment by its number and its cost code. Finance knows a vendor by an account reference. The same package appears in all three under three names, structured three ways, at three levels of granularity — because each system was designed for a different question and each is correct on its own terms.

Joining them is therefore not a technical exercise of moving fields between databases. It is a semantic exercise of establishing that this activity, this commitment and this account refer to the same thing. That judgement has traditionally been made by a person, which is precisely why the answer takes a fortnight and arrives as a

The join between project systems is semantic, not technical. That is why integration projects deliver data movement and not answers.

What a layer above the platforms does

This is the second half of the partner layer described in the previous article, and it does two things in sequence.

First it reconciles entities across systems — establishing and maintaining the correspondence between the activity, the commitment, the vendor and the account. Then it reasons over the combined picture, which is only possible once the first step holds.

The ordering is the whole thing. Reasoning applied to systems that have not been reconciled produces answers that look authoritative and are quietly wrong, which is worse than no answer at all. Any product offered at this layer should be asked how it establishes the correspondence and what it does when the correspondence is ambiguous.

The case for developers and PMC firms

The organisations for whom this is most acute are those running a PMIS for commitments, cost and correspondence alongside a scheduling tool for time — which is to say most real estate developers and most project management consultancies in this region.

That combination is not an accident of procurement. It is the right architecture, because a PMIS and a scheduling engine are genuinely different tools and every attempt to make one do the other's job has produced a weak version of both. The consequence is that the two most important dimensions of a project, time and money, live in separate systems by design.

The questions that matter most cross that boundary. Which delays have commercial consequences. Which variations have schedule consequences. Whether the forecast completion and the forecast final account are telling the same story. These are not exotic analytical questions. They are the standard questions of project control, and they are hard to answer because of an architecture that is otherwise correct.

On evidence of scale

One point worth making about this category, because it is young enough that caution is warranted.

Ask for evidence from portfolios comparable to yours in size and complexity. Public infrastructure agencies running large capital programmes are a useful reference class, because their reporting obligations are demanding and their portfolios are genuinely heterogeneous — several delivery partners, several systems, several decades of history. A capability that holds up in that environment has been tested against real conditions rather than a clean pilot.

Anonymised examples are reasonable and should be expected. What you are assessing is whether the volume and structural complexity resemble yours, not whose logo is on it.

This does not require you to change platform

A deliberate point, and the reason this article sits where it does in the series.

A reasoning layer above the platforms is not an argument for replacing them. It works above a PMIS, a scheduling tool and a finance system regardless of which products those are, and the case for it is as strong for an organisation running Oracle Unifier and Primavera, or Procore, as it is for one running PMWEB.

That is the honest position and it is also the commercially useful one, because the question this layer answers is not which platform should we have chosen. It is what do we do about the fact that our data is correctly held in three places.

What to establish before committing

How does it connect — and specifically, does it require a project to move or copy data into a new repository, or does it read the systems where the data already lives? The first creates a fourth system to govern. holds at implementation and degrades over eighteen months is a liability.

And what happens to permissions. A layer that reads three systems must respect the access model of all three, and it is worth testing that a user with restricted access in the PMIS does not gain a wider view through the analysis layer than they hold in the source. The principle PMWEB applies inside its own platform is the right one to require of any layer above it: AI should work under the permission model the owner already administers, not a second one. A reasoning layer with its own access model is a second one by definition, and the time to find that out is before the first board question that relies on it.

The question this layer answers is not which platform we should have chosen. It is what we do about the fact that our data is correctly held in three places.

Next week, closing Part III: twelve questions to ask your PMIS vendor about AI, whichever platform you are running.