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 Ask of the Data

  • 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?

What Generic AI Misses

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.

What Structured Knowledge Answers

QUESTION

Which activities on the critical path depend on the design release of the curtain walling package, and what happened to completion between revision 6 and revision 7?

ANSWER

In revision 7 the curtain walling design release milestone, activity 1240, drives a chain of six critical activities: fabrication drawings and Status A approval, bracket setting out, unitised panel fabrication, delivery to site, installation to levels 1 to 4, and the weathertight milestone that releases the fit-out on those levels. All six were critical in revision 6 as well. Between the two revisions the design release milestone moved three weeks later and the fabrication duration was shortened by two weeks, so completion moved one week later, from 22 August to 29 August. The shortening of fabrication is not explained in the revision narrative. The early warning register records the design release delay as EW-031, raised against the dates for design information shown in the Accepted Programme, and no compensation event has been notified against it.

SOURCES

programme file, revision 6 and revision 7, activities 1240 to 1310 and completion milestone 9000; revision 7 narrative, section 3; early warning register, EW-031; Accepted Programme, revision 6, information dates; contract, clause 31 and contract data part one.

Illustrative. The project, documents and references are invented to show what an answer looks like; nothing in it is advice.

See it on your data.

See it on your data.

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.

The Data in Context

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.

Related Knowledge

Frequently Asked Questions

Frequently Asked Questions

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?