Early Warning, and the Gate That Has to Stay Closed

This article is about what capital delivery needs from AI-assisted monitoring, not about what any platform ships today. The scenario below is illustrative.

Every system discussed so far in this series waits to be asked. You open a record, you run a search, you request a summary. The system is a resource and you are the one who has to know to consult it.

The next thing worth wanting is a system that raises its hand.

A monitoring capability that watches only the workflow will report a healthy programme right up until the reconciliation.

What has to be watched

Continuous monitoring is usually described in terms of workflow events — an approval overdue, a submission missed, a milestone passed. That is the easy half and it is not where the exposure hides.

The harder and more valuable half is inconsistency in the data itself. A revised document whose terms no longer match the record that governs them. A commitment whose certified value has drifted past its revised value. A vendor appearing under two entities. None of these generates an event. Nothing is overdue. The workflow is behaving perfectly and the underlying position is wrong, and it will stay wrong until somebody happens to look.

A monitoring capability that watches only the workflow will report a healthy programme right up until the reconciliation.

A scenario worth working through

Suppose a contractor on one of your packages enters insolvency proceedings. This is not a rare event in this industry and the sequence that follows is familiar. you formally. The question is how long it takes to establish your position.

What is the remaining balance on their commitments. What change orders are pending against those commitments and at what value. What has been certified but not paid. What bonds and guarantees are in place and are any close to expiry. And the question that is hardest and matters most: where else in the portfolio does this counterparty appear, including as a subcontractor on packages held by somebody else.

In most organisations that exercise takes a fortnight and is assembled from six sources by three people, at least one of whom is on leave. The answer arrives after the commercially useful window has closed.

A monitoring capability worth having connects the external event to the internal exposure and then sweeps the portfolio for the same counterparty — returning, say, six further commitments nobody had connected. Permission- filtered throughout, so nobody sees anything they were not already entitled to see.

Establishing the position in minutes, not a fortnight: the PMWEB 2026 AI Assistant gathers one counterparty’s commitments and

pending change orders across every project. Illustrative data.

You will hear about the event. The capability worth having is the one that tells you what it means to you, this afternoon rather than next fortnight.

The exception layer

The same principle applies to exposure that arises internally rather than externally.

Overbilling against a revised commitment value, with the specific invoices that produced the figure named rather than a percentage asserted. A vendor's insurance or bond approaching expiry, detected before it lapses rather than during the claim that follows. A revised document compared against the record that governs it, with the per cent to five.

Each of these is discoverable today by someone who goes looking. The difference is that nobody has time to go looking at everything, so the looking is sampled, and the exposure that matters is the one that fell outside the sample.

And then the response, which is where the discipline is required

Detection is only useful if something follows, and this is the point at which the design decisions matter most.

A capability that identifies an expiring bond can draft the reminder. A capability that identifies overbilling can propose restricting invoice approval while the position is resolved. A capability that identifies counterparty exposure can propose a payment hold that blocks the workflow and signals the issue across that vendor's other commitments. It can draft the notice to the other project leads affected.

Drafted. Proposed. Prepared. Never done.

The reminder is drafted for a person to review, amend and send. The payment hold is proposed for a person to authorise. As established earlier in this series, the audit trail must name the person, and the more consequential the action the more that matters. A payment hold placed automatically is a commercial position taken by a machine against a counterparty who may be in dispute with you, and it is precisely the kind of action that will be examined line by line later.

PMWEB states the principle behind its Intelligence Control Framework in five words: AI advises, the operator decides. Monitoring is where that principle is tested hardest, because it is where the advice arrives with the most urgency attached.

The objection worth answering

If a person has to authorise everything, what was gained? The system found the problem faster, but a human still does the work.

What was gained is the interval. In the insolvency scenario, the difference between establishing your position on the afternoon of the filing and establishing it a fortnight later is the difference between acting on it and documenting what happened. Nothing about the decision was automated. The decision simply arrived while it was still a decision rather than a record.

That is the honest value proposition for this class of capability, and it is a strong one. It does not require anybody to accept an autonomous actor inside their control environment, and organisations should be sceptical of any version that asks them to.

What to ask for

When this capability is offered to you, three questions establish whether it is the version worth having.

Does it monitor the data or only the workflow? Does the sweep respect existing permissions, including where a result connects activity across records the user reaches separately? And at the end of the chain, when a response has been prepared, what does the system do — and what does the audit trail record?

The answer to the third should be that it waits, and that the trail names a person.

PMWEB's September 2026 checklist adds the detail that makes the third question testable. Every AI interaction should be logged with the user, the timestamp, the query, the response and the resulting action. That matters more for monitoring than for any other class of capability, because the responses it prepares (a payment hold, a restricted vendor's payments were held in March, the record should show what the system flagged, what it proposed, who reviewed it and what they decided.

Nothing about the decision was automated. The decision simply arrived while it was still a decision rather than a record.

That concludes Part II. Part III turns to the layer no PMIS vendor supplies: capture at archive scale, and reasoning that spans the systems a programme actually runs on.