Generating a schedule is easy. Defending it is the job.

Say a tender closes in nineteen days, and a junior planner pastes the scope of a tank terminal into a chat assistant to ask for a programme. Forty seconds later there are two hundred and twelve activities on the screen, in a tidy work breakdown, with durations, links and a finish date that lands, conveniently, a fortnight inside the client's. It looks like three weeks of work. The lead planner scrolls to line 118, Hydrotest, tank T-101, 6 days, and asks one question: where does six come from?

Nobody in the room knows. The assistant does not know either, though if you ask it, it will give a reason, fluently and at once. A reason is not a source. A source is something you can open: the clause in the specification that sets the fill stages and the hold, a past tank of the same size whose hydrotest really took nine days, a production rate from the estimate. The reason the assistant gives is a sentence about what hydrotests usually involve. It may even be right. It cannot be checked, and in a tender, a programme review or a delay claim, a figure that cannot be checked counts for very little.

This post is about that gap. Generating schedules with AI is here, it is useful, and within a few years it will be ordinary on every bid. But the hours that make a schedule worth anything were never spent typing activities. They were spent establishing why each activity is there, why it takes as long as it does, and why it comes after what it comes after. A generated draft that skips that work has not saved it. It has moved it to the reviewer, who must now reconstruct the reasoning backwards, which is slower than writing it forwards. What follows is a long look at the alternative: drafts in which every line arrives with its source, the evidence on what machines miss, the checks every draft must pass whoever wrote it, and what all of that does to the planner's job.

The typing was never the expensive part

Ask an experienced planner what building a tender programme involves and the answer is mostly reading. The contract sets the frame: the start, the access dates, the key dates and sectional completions, the restrictions on working hours, the time the client takes to review a submittal, the completion the damages hang on. The specification adds the sequence the client insists on: hold points, inspection and test plans, cure and test periods, the order in which systems are handed over. The bill of quantities gives the size of each piece of work, which only becomes a duration once someone divides it by a production rate they believe. And the organisation's own history says how long the last tank really took, which is rarely how long the last bid said it would.

Only after all of that does anyone open a scheduling tool. The activities, links and durations on the screen are the residue of the reading, and the reading is recorded, when it is recorded at all, in a document AACE International calls the basis of schedule. Its recommended practice on the subject, 38R-06, lists what that document should hold: the planning basis, the execution strategy, the assumptions, the exceptions, the reconciliation of baseline changes, and the project team's buy-in. It also notes that the basis may be used in claims situations, which is a dry way of saying that the basis is what a schedule falls back on when somebody challenges it.

That is why a schedule drafted in forty seconds is not three weeks of work saved. The typing was perhaps two days of the three weeks. The rest was establishing the basis, and the draft does not contain one. Worse, it looks as though it does. Every line has a duration, every duration looks deliberate, and nothing on the screen distinguishes a duration copied from a clause from a duration the model found plausible.

A schedule without a basis is not a draft. It is a list of claims waiting for someone to check them.

What the research says machines miss

The evidence on language models drafting construction schedules is still thin, and it is worth reading closely, because it is consistent about where the misses fall.

In a 2023 study published in Buildings, Prieto, Mengiste and García de Soto had ChatGPT produce six schedules for one small job: a new partition across a four-metre room, with one wooden door. The schedules were coherent and followed a logical approach, in the authors' words. None of the six included the door frame or its protection before painting. Three included demolishing an existing wall that was not there. Three included a foundation. None appeared to allow for drying times. The six participants who assessed them gave accuracy and reliability the lowest scores of any criterion.

The models have improved a great deal since January 2023, and nobody should read that study as a measure of today's tools. What has not changed is the shape of the misses. The door frame is obvious to anyone who has hung a door, which is precisely why no document mentions it. The drying time is physical, which is why it lives in a specification or in a foreman's head rather than in the scope. Language models learn from what is written down. What is too obvious to write down is what they leave out.

Two more recent results sharpen the point. At the 2025 International Symposium on Automation and Robotics in Construction, Singh, Pal and Hsieh fine-tuned small language models on two residential projects of about 1,500 activities and 1,375 predecessor and successor pairs. The best reached 83.69 per cent accuracy on sequencing, which still leaves roughly one pair in six in the wrong order. And R-ConstraintBench, a 2025 benchmark of scheduling constraints by Jain and Wetter, found strong models near their ceiling on networks of simple precedence, while their ability to produce a feasible schedule collapsed once downtime, time windows and disjunctive constraints interacted. Disjunctive is the formal word for two things that cannot happen in the same place at the same time: two lifts on one crane, two crews in one tank.

Notice that the right-hand column is not a call for a better model. Each catch is a check that works on any draft, generated or not, and most of them depend on knowing where each line came from. That is the thread through the rest of this post.

Two machines that share one name

First, a distinction the market blurs. Two quite different machines are sold as generative scheduling, and they fail in opposite ways.

The drafter is a language model that reads a scope, a contract or a brief and writes a structured list of activities, often backed by a database of durations from past projects. Its strength is breadth: it can produce a plausible skeleton for almost anything in minutes. Its weakness is the one above. It can leave out what is obvious on site and add what is typical elsewhere.

The optimiser is a constrained search over a schedule you have already built and parameterised: crews, production rates, equipment, work areas, calendars, costs. It tries a very large number of sequences and crew mixes and returns the best options it found against objectives you rank. The underlying problem, resource-constrained project scheduling, is proven to be strongly NP-hard, so best found is the honest phrase. On the standard benchmark library's own scoreboard, as of October 2026, only 89 of its 600 test projects with 120 activities have a proven optimal schedule. An optimiser's answer is the result of a search budget, not a proof.

The optimiser cannot invent work, but it has a trap of its own, and it is subtle. Much of the speed it finds comes from removing what AACE calls preferential logic: sequencing the contractor chose rather than sequencing the work demands. AACE's own examples of preferential logic are equipment restraints, crew movements and form reuse. In other words, the link a planner added so that two lifts would not need the crane at once is exactly the kind of link the search is invited to remove. Remove it without modelling the crane as a resource and the resulting option is feasible in the model and impossible on site. In the only published comparison we found of algorithm-generated schedules against conventional critical path schedules on real projects, a 2014 Stanford thesis, the critical path schedules came out shorter for precisely this reason: they did not model the space the work needed.

So the drafter can miss what nobody wrote down, and the optimiser can remove what somebody wrote down for a reason they did not record. Both failures have the same cure. Every element of the schedule carries the reason it exists, in a form a person can open.

Provenance: five answers to one question

Provenance is the record of where something came from. For a generated schedule it means that every activity, every duration and every link arrives with an answer to the lead planner's question, and that the answer is honest when it is “nowhere”. In practice there are five answers, in descending order of how far they can be trusted.

The last row deserves a paragraph of its own, because it is the failure people least expect. Language models are fluent with references. Asked to back a duration with a source, a model will sometimes produce one: a clause number, a section heading, the name of a past project. Usually the reference is real. Occasionally it is a plausible reference to a clause the document does not contain. If the review screen shows every row that has a citation in the same way, a fabricated citation looks exactly like a verified one, with a confident badge and a link that leads nowhere. So citations have to be checked by the system, not by the model: the clause looked up in the attached document, the quoted text found in it, the library record found in the library. A citation that fails the lookup is not shown as a source. It is shown as what it is.

The order of the tiers matters too. A project's own documents come first, because they are what the contract will be read against. The organisation's own library comes second, because its own crews and its own suppliers produced those durations. A general benchmark comes after both, and published best practice after that. A draft that reaches for a generic rate when the organisation has done the same work twice before has picked the wrong source, even if the rate is reasonable.

And a library should hold what happened, not what was promised. Many template libraries are built from baselines, and baselines are bids. A duration taken from a past baseline inherits the optimism of the tender it was written for. A duration taken from a past as-built record inherits what the crews actually did. The difference between the two is often most of a schedule's contingency.

An example: a tender programme with its sources

Take, for example, the tank terminal from the top of this post: four storage tanks, a marine berth and a pipe rack, with delay damages tied to mechanical completion. Suppose the invitation to tender asks for a programme with the bid, showing the access dates, the key dates, the order and timing of the operations and the principal resources, in the manner clause 31 of the NEC4 contract sets out for an accepted programme, and the contractor has nineteen days.

The lead planner sets the chat draft aside, keeping its list only as a reminder of things not to forget, and attaches three documents to a drafting request instead: the contract with its contract data, the technical specifications for the tanks and the berth, and the bill of quantities. The request asks for a skeleton of about eighty activities from those documents and the organisation's schedule library, and for nothing to be invented without saying so.

Six rows of the eighty show the range of what comes back.

• Access to berth area, a milestone, from the contract data, part 1, access dates. The date is not a guess and not a pin. It is the client's obligation, and the berth work is linked to start after it.
• Shell erection, tank T-101, 34 days, from the library: a past tank of the same diameter, erected by the same method, recorded as it was built. The planner checks the analogue. If the past tank was inland and this one is on the coast, the question for the construction manager is whether wind stand-downs on the shell need an allowance of their own.
• Hydrotest, tank T-101, 9 days, from the tank specification, clause 3.8: its fill stages, settlement readings and hold. This is the line that said six days in the chat assistant's draft at the top of this post. The specification makes it nine.
• Cable pulling, MCC building, 12 days, best practice. The sequence, trays then cable then terminations then loop checks, is sound everywhere. The duration has no project-specific basis, so the electrical estimator's rate replaces it.
• Marine piling, berth, 41 days, no source. No attached document gives a piling rate, and the organisation has never built a berth. The draft says so instead of hiding it. The planner asks the piling subcontractor for its method statement; its production rate makes the activity 38 days, and the row now carries the method statement as its source.
• Pre-commissioning, T-101, 6 days, unverified citation. The draft cites clause 14.2 of the tank specification, and the specification has no clause 14.2. The row is unticked, and pre-commissioning is rebuilt from the commissioning engineer's list of systems.

None of those six decisions needed a planner to type anything. Each needed a planner, or someone the planner called, to know something. That is the shift in miniature: the machine produces the list and the evidence, and the people spend their time on the lines where the evidence is weakest.

Which lines are those? Across the whole draft the provenance is not evenly spread, and the spread is the most useful thing the draft produces.

Of the eighty activities, twenty-five trace to the project's documents, twenty-six to the library, seventeen to best practice, and twelve to nothing. The twelve are not scattered. Five are on the marine berth, which the organisation has never built, and three are in commissioning, about which the contract says little beyond the milestone. The tanks, which the organisation has built many times, have one line without a source out of twenty-two. A draft without provenance would present all eighty lines with the same confidence. A draft with provenance is a map of where the organisation's knowledge runs out, and it tells a lead planner with nineteen days where to spend them.

It also tells the bid director something about risk before any risk workshop. A berth programme with five unsupported lines out of twelve is a berth programme the contractor does not yet know how to price. That belongs in the risk register and the tender's qualifications, not only on the planner's list.

Seven checks, whoever drafted it

Provenance answers where a line came from. It does not answer whether the schedule as a whole is sound. That takes the checks every competent planning team already runs, and the point to hold on to is that a generated draft is exempt from none of them. If anything it needs them more, because it looks finished sooner.

Three of these deserve a closer look when the draft was generated.

Constraints. A model asked for a schedule that meets a client's key dates has an easy way to oblige: put the dates on the activities as constraints. The result meets every milestone and means nothing, because the dates no longer come from the logic and the float that would show the problem has been absorbed. The Society of Construction Law's Delay and Disruption Protocol asks for the opposite. Manually applied constraints such as must-start and must-finish dates, and other techniques that stop a programme reacting dynamically to change, should be avoided or, if unavoidable, explained in the narrative. A generated draft should carry the contract's dates as milestones the logic has to reach, and a check should count every hard constraint it contains.

Logic. The fourteen points of the DCMA assessment are the best-known logic health check in the industry: missing logic, leads, lags, relationship types, hard constraints, high float, negative float, high duration, invalid dates, resources, missed tasks, a critical path test, and two indices of how the schedule is performing. The GAO is careful to say the thresholds are not compliance triggers, and they are not. They are a spell-check. A spell-check is still worth running on every draft, and it takes seconds.

Owned. This is the check no machine can pass on anyone's behalf. The GAO's guide puts it plainly: the managers responsible for resources should approve the areas of the schedule they are committed to support, and the experienced people who will perform the work are the best source of its estimates. A programme assembled by a planner and a model, however well sourced, is not owned until the construction manager, the piling subcontractor and the commissioning engineer have looked at their parts and agreed. The contractual consequence is real. Under NEC4 a project manager may decline to accept a programme that does not represent the contractor's plans realistically. Under the SCL Protocol, acceptance means the programme is a reasonable, realistic and achievable depiction of the work, without being a warranty that it can be achieved. A programme the site will not follow is a contract problem waiting for a date.

The round trip into the scheduling tool

Most generated drafts end up in Primavera P6 or Microsoft Project, because that is where the contract programme lives and where the client's reviewer will open it. The round trip is where good drafts quietly lose information, and a team that knows the failure points can avoid them.

• P6 Professional imports a spreadsheet only into a project that already exists, from sheets with fixed names and fixed column headings. Oracle's own route is to export a template from P6, fill it, and import it back. A file in any other shape is rejected or misread.
• On a spreadsheet import, calendars, codes and resources that are not already in P6's dictionaries are not added, an activity whose WBS element does not exist does not come in, and a blank duration becomes the administrator's default. A draft can lose its calendars without an error message.
• Importing an XER over an existing project keeps relationships the new file no longer contains unless the delete option is chosen. A revised draft imported over the old one can bring the old logic with it.
• The SCL Protocol settles the rest: no version of any programme should be overwritten. Import each draft as a new or what-if project, compare, and keep every version.

XER and XML exports avoid most of the spreadsheet problems because they carry the network as a network. They do not carry provenance unless someone maps it into user-defined fields or notebook topics, and few teams do. The basis has to travel separately, as the narrative and basis of schedule, or it does not travel at all.

Who does what, once drafts are generated

Put together, the work divides cleanly. The machine is quick at producing lists and evidence. The tools are good at arithmetic. People are good at knowing what is not written down, and they are the only ones who can take responsibility.

Where it goes wrong

The illusion of completeness. A generated draft looks finished hours after the request, and people approve what looks finished. This is automation bias, and it is the largest risk on this list. What catches it: the provenance mix shown before anything else, so the unfinished parts are visible at a glance, and an approval that cannot be given silently when nothing selected traces to the project's own data.

The wrong analogue. The library offers a tank that took thirty-four days. That tank was inland, on a different foundation, with a bigger crane. The duration is sourced and wrong. What catches it: library entries that carry their context, such as size, method, location and crew, and a reviewer whose task for every library line is to judge the analogue, not to accept the number.

The baseline posing as history. The library was built from past bids rather than past as-builts, so every sourced duration carries the optimism of a tender that was won partly by being optimistic. What catches it: a library fed from approved actuals, with each entry saying which of the two it is.

The fabricated citation. Covered above, and worth repeating, because it is the failure that defeats a careless review: a confident reference to a clause that does not exist. What catches it: the system looks up every citation, and a failed lookup is labelled as unverified and treated as unsupported.

Too much detail too soon. Five hundred activities from a forty-page scope is not precision. It is invention at a finer grain. AACE's schedule levels exist for a reason, and a tender skeleton at level two or three is what the documents can support. What catches it: drafting to the level the evidence supports, and leaving the detail to the people who will plan the work they are going to do.

The optimised-away crane. When a draft is later optimised, preferential links that stood for a shared resource are removed, and the resource itself was never modelled. What catches it: links that carry their reasons too, links that stand for a resource replaced by the resource before any optimisation, and a site review of the fastest options with the most suspicion, because the fastest option is the one most likely to be impossible.

What changes for each person

The lead planner stops building the skeleton and starts directing its review. The nineteen days go to the twelve unsupported lines and the analogues, not to typing eighty activities. The skill that matters most becomes knowing which proposals are nonsense, which is the skill that took fifteen years to acquire and was always crowded out by the keying.

The junior planner loses the old apprenticeship of building programmes by hand and gains a new one: checking a hundred sourced lines a week, and learning the project from its evidence rather than from the keyboard. It works only if someone senior teaches them what a bad analogue looks like.

The construction manager and the specialists are asked earlier and more pointedly. Instead of reviewing a finished programme in the last week of the bid, they are sent the lines in their area that have no source, on day three. Their knowledge goes into the record as a source with their name on it.

The bid director gets a risk signal before the risk workshop. The provenance map shows which parts of the scope the organisation has done before and which it has not, and that is the first draft of the tender's qualifications.

The client's reviewer gains the most and is mentioned the least. Under NEC4 a project manager has two weeks to accept a programme or give reasons for not accepting it. A programme whose lines carry their sources turns that review from a reconstruction into a check: open the clause, open the as-built, ask about the unsupported lines. Owners can reasonably start asking for it.

What you can do on Monday

1. Add a source column to your next programme, generated or not: document and clause, library project, rate, or “none”. It is tedious by hand for a week. After that it is how you think.
2. Ask any AI-drafted schedule for its sources, then check three of them. If one does not resolve, treat every citation in that draft as unverified until the tool can show you how it looked them up.
3. Start a library from as-builts, not baselines. Take your last three completed projects, export the actual durations of the activities you repeat most, and record the context of each: size, method, location, crew.
4. Run the logic checks before anyone sees the draft. Every scheduling tool can count open ends, lags and hard constraints in seconds. A draft that fails them is not ready for a human review, let alone a client's.
5. Send each specialist the unsupported lines in their area on day three, not the finished programme on day eighteen.
6. Import every version as a new project and keep it. The draft you overwrite is the version you will need in the dispute.

Where this stands

Verian is a project controls service run on Verian's own AI platform. Today, Verian's team drafts a first schedule for a client on that platform, from the documents the project already has, such as the contract, the specification and the bill of quantities, and from the schedule library. The draft is a skeleton of the work breakdown, the activities and their links, up to a few hundred activities, and nothing in it enters the schedule until a person approves it.

Every proposed activity carries its provenance. A line traced to a document names the document and the section, and quoted text is checked against that document. Otherwise a line says whether it comes from the client's own schedule library, from Verian's activity library, from best practice, or from nothing. A citation the platform cannot find is marked as an unverified citation and treated as unsupported, and when nothing selected traces to the client's own data, the approver has to acknowledge that before committing. The platform runs the DCMA 14-point assessment on the schedule, and the approved schedule exports to Primavera P6, as XER or XML, and to Microsoft Project XML. The client's planners log in, see every line with its source, and decide what goes in.

The direction is the one this post argues for: a library that grows from each project's as-built record rather than its baseline, so that the tenth draft leans on what the first nine actually did. The rule underneath does not change on the way there. The machine drafts and shows its sources; a person decides, with a name and a time. Generating a schedule is easy. Defending it was always the job, and it still is.