Knowledge / AEC-native data
Construction programmes
The logic-linked schedule of activities, durations, milestones and float, held in P6, Asta or MS Project and issued as baselines and updates.
Every construction programme is a network: activities with durations, logic links between them, calendars, constraints and float, held in the planning software and issued as a baseline, then as the accepted programme under the contract, then as periodic revisions. What most of the team sees is the PDF Gantt chart, which is a picture of the network with the logic removed. Any construction programme AI worth the name has to read the network, not the picture. Planners and project managers use it to know what is critical, what has moved, and which activities are waiting on design information. Structured knowledge makes the programme file something the team can question alongside the contract and the site record, with every answer traceable to an activity, a revision and a link.
What teams need to ask of it
Which activities are on the critical path in the current revision, and which were critical in the accepted programme?
What moved between the last two revisions: durations, logic, constraints, calendars or the completion date?
Which activities depend on a design release, an approval or a client decision, and what dates does the programme assume for them?
Does the accepted programme show everything the contract requires a programme to show?
Which activities have used float since the baseline, and what used it?
If this early warning becomes a compensation event, which activities does it touch and does it reach completion?
Which activities planned for this period have no matching entry in the site diary?
Why generic AI gets it wrong
A Gantt chart issued as a PDF is a picture. The bars are visible; the logic that connects them is not. A tool reading the PDF sees names and dates, and cannot see that plasterboard follows first fix with a five-day lag, or that a milestone carries a constraint holding the sequence in place. Calendars are invisible too, so working days are read as calendar days. Ask such a tool what is critical and it guesses from the longest bar. Even the native file is a set of tables whose meaning sits in the links between them; read as text, it is identifiers where the planner sees a network.
The second failure is comparison. A programme is never one document. It is a baseline, an accepted programme and a sequence of revisions, and most useful questions are about what changed between two of them. That comparison has to be made activity by activity, impossible from two PDFs and tedious from two native files. A tool given the latest revision reports its dates without knowing which moved, or why, or that the contract sets out what a programme must contain and this one omits it. The answer is a clean list of dates. It reads well enough that the planner may not look further, and the movement that matters stays hidden until the next early warning.
One question, answered
QUESTION
ANSWER
SOURCES
We onboard a focused slice of your project data, configure the ingestion paths, extract a structured context graph, and build a workflow against the resulting structured knowledge layer.
Related to
The programme is read against the construction contracts that define what it must contain and when it must be revised, against the change orders, variations and compensation events that move it, and against the site diaries and daily reports that record what happened each day. Variation and change impact review depends on it to trace a change into time, and contract obligation extraction ties the periods in the contract to the activities they bite on.
Does it need the native programme file, or will a PDF do?
Can it compare two revisions?
How do we see it on our own programme?
Related pages
Change orders, variations and compensation events
Instructed or notified changes to scope, time or cost, and the notices, quotations and assessments that follow under the contract.
Site diaries and daily reports
The daily record of labour, plant, weather, progress, deliveries, instructions and events on site, often the evidence base in disputes.
Construction contracts (NEC, JCT, FIDIC)
The conditions of contract, particulars, amendments and schedules that define obligations, risk allocation, notices and payment between the parties.
Variation and change impact review
Tracing a proposed change through the drawings, specification, programme and contract to identify what it touches and what it triggers.
Contract obligation extraction
Extracting obligations, notice periods, risk allocations and deliverables from the executed contract into a structured register the project team can act on.