That is not a prompt problem. It is a property of the technology, it has a formal name, and the standards bodies have already written it down.

#The failure has a name, and it is not “hallucination”

NIST's Generative AI Profile for the AI Risk Management Framework calls it confabulation: the phenomenon in which systems "generate and confidently present erroneous or false content in response to prompts", noting that these are "colloquially also referred to as 'hallucinations' or 'fabrications'".¹

The word choice matters more than it looks. Hallucination suggests a malfunction — something that happens when the system goes wrong. Confabulation is what the system does when it is working exactly as designed and has nothing to say. It fills the gap, fluently, at the same confidence as everything else. There is no tell.

NIST files the risk against the "Explainable and Interpretable" trustworthy-AI characteristic,¹ which is the useful part: the mitigation is structural, not linguistic. You do not fix confabulation by asking the model to be careful.

#The number that should end the argument

The first systematic study of this on document-grounded professional work looked at law. Asked specific, verifiable questions about real federal court cases, the models tested — GPT-4 among them — "hallucinate at least 58% of the time, struggle to predict their own hallucinations, and often uncritically accept users' incorrect legal assumptions."²

That study is about law, not construction, and we are not going to pretend it measured a schedule. But the task shape is the same one project controls asks for: retrieve a specific fact from a large corpus of dense professional documents and state it precisely. And the second and third findings are the ones that should worry a project team more than the first. A tool with a 58% error rate that knew when it was guessing would be usable. A tool that cannot tell, and that will agree with a wrong premise a superintendent brings to it, is worse than the error rate suggests.

Construction already knows what to do with an assertion nobody can trace. It rejects it.

This is not a new standard the industry has to invent for AI. Forensic schedule analysis has a standards-body recommended practice with a five-layer method taxonomy specifically so that two analysts can say which method they used and be checked against it.³ Schedule quality has named, quantitative checks with published thresholds. The discipline's entire posture toward expert opinion is show your work. Software does not get an exemption for being clever.

#So the gate goes before the output, not after

The design consequence is simple and slightly unfashionable: every candidate finding has to carry a reference into the project record, that reference has to resolve, and a finding whose reference does not resolve does not get published. It is dropped, and the drop is logged against the run so it is auditable rather than invisible.

A finding is therefore one of three things and never a fourth: anchored to a source document, computed from schedule math, or explicitly labelled as an assumption. "The model thinks so" is not on the list.

#What it costs

Dropping findings is not free. Some of what gets dropped is true. A real supply-chain risk the model correctly inferred from something it could not point at gets thrown away, and nobody ever learns it was right.

We take that trade knowingly, because the two errors are not symmetrical. A dropped true finding costs you one insight. A published unverifiable finding costs you the reviewer's trust in every other finding on the page — and once a scheduler has been burned by a confident citation to a drawing that does not exist, they are right never to trust the tool again. The expensive failure is not the miss. It is becoming the thing people stop reading.

The regulators are converging on the same place. ISO/IEC 42001:2023, the first AI management system standard, lists traceability, transparency and reliability among its core benefits.⁴ The EU AI Act requires high-risk systems to be "designed and developed in such a way as to ensure that their operation is sufficiently transparent to enable deployers to interpret a system's output and use it appropriately."⁵ Whatever a construction platform is, "interpret the output and use it appropriately" is unachievable if the output cannot be traced.

How the same principle plays out on a specific problem is in the weather baseline post — where the entire argument is about which records a third party authored — and on the construction delay risk page.

The question is not whether the weather was bad. It is whether the weather was worse than what a reasonable contractor should have anticipated at that location, in that month — and whether the excess landed on work that was controlling the completion date. Those are two arithmetic problems wearing a meteorology costume. Most claims lose on the arithmetic.

A peer-reviewed systematic review puts the exposure plainly: adverse weather delays forty-five percent of construction projects worldwide.¹⁶ Nearly half of all projects meet this problem, and the industry's standard response is to start assembling the record after the days are already gone.

#Start with the clause you are actually arguing under

Weather is not one contractual concept. It is four or five, and they do not agree with each other. Before anyone opens a weather database, find out which one governs.

Two things are worth noticing in that table. The first is that every one of them is a time remedy. Weather almost never buys money. If your claim is built to recover cost, it is built against the wrong clause.

The second is the qualifier. “Unusually severe.” “Not reasonably anticipated.” Those are comparative terms, and a comparison needs two operands. The contract supplies one — the actual weather. You are responsible for the other.

#The baseline: what “reasonably anticipated” means in numbers

Some contracts do the work for you. State DOT specifications frequently pre-tabulate the anticipated adverse weather days for each calendar month, and then grant a time extension only for confirmed adverse days that exceed that monthly figure. Wisconsin DOT's standard specification is a clean example of the pattern: submit a request when the number of adverse weather days exceeds the tabulated anticipated number, supported by monthly submittals showing the controlling item of work was delayed.¹¹

If your contract has that table, your baseline argument is over before it starts. Read the table. Count against it. Nothing else matters.

Most private work has no such table. Then the defensible substitute is the federal climate record. NOAA's US Climate Normals are 30-year averages — currently the 1991–2020 period — published specifically as the reference for what is typical at a given location.⁶ They are free, they are versioned, they predate your dispute, and neither party authored them. That last property is the one that matters. A baseline you produced during the argument is a position. A baseline NOAA published before the project started is a fact.

• Pull the normals for the station nearest the site, not the nearest metro area. A coastal station twenty miles inland is a different climate.
• Convert them into days per month that breach your thresholds, not averages of rainfall inches. A month with normal total precipitation delivered in three storms is not a normal month for a concrete crew.
• Do it at baseline schedule submission, and transmit it. A baseline nobody objected to in month one is very hard to attack in month fourteen.

#Thresholds are a property of the activity, not the project

A quarter inch of rain is nothing to a crew doing interior rough-in and a lost day to a mat pour. “Weather day” is not a project-level concept, and a claim that treats it as one invites the obvious rebuttal: other trades worked.

The good news is that the thresholds mostly already exist, in documents nobody thinks of as weather documents.

A threshold written down after the weather is an opinion. The same threshold written down at baseline is evidence.

#Observations have to come from somewhere you do not control

Daily reports are necessary and they are not sufficient. They are authored by the party making the claim, which is exactly the objection you will hear. Corroborate them with the federal record, which is free and which nobody can accuse you of writing.

Note the split between the first row and the second. The forecast establishes what you reasonably knew and when — which is what makes a mitigation argument possible. The station observations establish what occurred. Claims get muddled when one document is asked to do both jobs.

#A weather day is not a delay until it touches the controlling path

This is where most otherwise-solid records die. Ten excess adverse days on activities with twelve days of float is not a ten-day delay. It is float consumption — real, worth knowing about, and worth nothing as a time extension. EJCDC makes the condition explicit: the entitlement is conditioned on the delay affecting the critical path.⁴ WisDOT asks for the same thing in different words, requiring the submittal to show the controlling item of work was delayed.¹¹

Which produces an uncomfortable consequence: the float you were quietly proud of is the float that pays for the owner's weather. If you absorb weather into float all spring and then hit a genuinely severe week in autumn with nothing left, the autumn claim is the one that gets scrutinised — and the spring absorption is invisible in the record unless somebody was tracking float consumption as it happened.

AACE's recommended practice on the subject is worth reading in full for exactly this reason. Its definition of adverse weather names float directly: normal weather events that negatively affect worker productivity and/or which may affect a project's critical path or consume float.⁵ Float consumption is part of the definition, not an afterthought.

#Notice is the link that fails most often

Every document above conditions the remedy on notice, inside a window, in writing. ConsensusDocs routes weather requests through its notice article.³ A201 ties the extension to conditions documented under a specific claims provision.² The strongest evidentiary package ever assembled is worth nothing filed late, and this is the failure that hurts most, because it is the one that had nothing to do with weather at all.

The practical fix is unglamorous. Notice obligations belong in the schedule as dated activities with the contractual window as the duration, so that a missed filing shows up as a missed activity rather than as a discovery during closeout.

#What this looks like when it is built in rather than assembled afterwards

Every step above is mechanical. Thresholds per activity. A baseline from published normals. Observations from station data. A float test against the current dated schedule. A notice window with a deadline. There is no judgement in the arithmetic — only in setting the thresholds, which is engineering work that happens once.

That is the case for doing it continuously instead of retrospectively. SP4N checks dated weather-sensitive activities against the forecast on each analysis run, fetching National Weather Service data for the project's coordinates at the time of the run, and records overlaps that break an activity threshold as findings with delay-day and probability estimates. Each finding carries a reference into the project record, and a finding whose reference does not resolve is dropped and logged rather than published. You can read how that gate works in why an AI finding without a source is just a rumour, or see the activity-level scoring on the construction delay risk and weather risk pages.

The honest summary is that none of this makes bad weather cheaper. It makes the record contemporaneous, which is the only property of a weather claim that cannot be manufactured later.

The same goes for an unrecorded model number, a warranty with no start date, a redline that never made it into the record set, or an O&M manual that describes a different piece of equipment.

These do not begin as closeout problems. They become closeout problems because the project waited until the end to collect the evidence.

#Test closeout from the receiving team's side

A closeout package should let the owner or facilities team answer practical questions without calling the project team six months later.

What was installed? What changed from the design? How is it operated and maintained? What remains open?

One way to test that breadth is UFGS 01 78 00, the federal guide specification for closeout submittals. It covers revised project documents, warranty management, testing, adjusting and balancing, O&M manuals, and cleanup.¹ Its detailed submittal list includes as-built and record drawings, equipment and material records, warranted equipment, final approved shop drawings, and final specifications.¹

The list makes one point clearly: turnover depends on relationships among documents, equipment, approvals, and field conditions.

#Build the closeout map by system

Organizing closeout only by file type makes handover harder than it needs to be.

Consider one air-handling unit. The useful evidence chain might include:

• Approved product data and shop drawings
• Equipment tag, location, manufacturer, model, and serial number
• Approved deviations or substitutions
• Startup and functional test records
• Testing, adjusting, and balancing results
• Controls sequence and final settings
• O&M manual sections that apply to the installed unit
• Warranty terms, start date, expiration, and service contact
• The final record drawing location

Those files may live in different folders and come from different companies. The closeout map should connect them to the same installed asset or system.

The UFGS closeout template asks for an equipment-and-material record that includes the description, specification section, manufacturer, model and serial number, composition or size, and where the item was used.¹ That is more useful than a drive full of manuals because it gives the next person an index into the evidence.

#Seven document groups to control

1. As-built and record documents

Maintain redlines while the work is active. Capture approved changes, field routing, concealed conditions, and added details in the process required by the contract.

UFGS 01 78 00 defines record drawings as the final compilation of actual conditions reflected in the as-built drawings. Its Army-tailored workflow calls for working as-builts to be maintained during construction and reviewed as the work progresses.¹

The exact definition of “as-built” and “record drawing” varies by contract and jurisdiction. Use the project's terms instead of treating them as interchangeable by habit.

2. Final approved shop drawings and specifications

Retain the approved version, not simply the last file transmitted. Include accepted revisions and make the approval state visible.

A submittal marked “revise and resubmit” does not become closeout evidence because it has the newest timestamp.

Which version governs is the same question a construction document review has to answer earlier in the project — closeout does not get a pass on it.

3. Equipment and material records

For each required asset, capture the fields the facility team will need later: tag, description, manufacturer, model, serial number, installed location, applicable specification, and related drawings.

Match the register against field labels. A correct manual attached to the wrong installed unit is still a bad handover.

4. O&M manuals

Check that manuals describe the equipment actually installed, include required parts and maintenance information, and are organized so a facility operator can find the relevant section.

The UFGS template requires O&M manual files and ties them to an approval process around beneficial occupancy for projects using that specification.¹ Schedule the dates required by your contract.

5. Warranties and service information

Record the warranted item, terms, start and expiration dates, maintenance needed to keep the warranty in force, certificate reference, service organization, and contact information.

The federal template calls for warranty information to be assembled during construction and includes a cross-reference to the pertinent O&M manual.¹

6. Testing, commissioning, and acceptance records

Connect each required test to the system, procedure, result, approving party, and open corrective work. Include testing and balancing, startup, controls, functional performance, inspection, and other project-specific records where required.

Do not call a test “complete” when the report is missing, the result is conditional, or an exception remains unresolved.

7. Open items and final dispositions

Closeout should preserve the status of punch items, review comments, incomplete documents, exceptions, and approved deferrals. Every open item needs an owner, next action, due date, and accepted closure evidence.

An empty “open items” folder is not proof that nothing remains.

#Collect evidence when the work happens

The project schedule should carry closeout activities before the end milestone. The August 2026 UFGS project-schedule template calls for O&M manual and as-built drawing approvals, testing and balancing, commissioning, pre-final inspection, punch correction, and final inspection to appear in the initial schedule and updates.²

A practical collection rhythm looks like this:

1. At award, extract every required closeout deliverable from the contract and specifications.
2. Assign each deliverable to a system, source requirement, responsible party, due event, and approving party.
3. During submittal review, create the expected closeout record for each approved product or system.
4. At delivery and installation, record equipment identity and location.
5. At startup, testing, or commissioning, attach results and exceptions to that same record.
6. During progress reviews, reconcile missing evidence and aging approvals.
7. Before turnover, test the package from the facility operator's point of view.

This is less dramatic than a closeout scramble. That is the idea.

#Use an acceptance matrix

For each required deliverable, retain enough context to verify it:

The “not applicable with basis” state matters. It prevents a blank cell from being mistaken for a deliberate decision.

#Where software helps

A review system can help teams reconcile a requirements list against received records and organize candidate gaps for human review.

SP4N supports that work by keeping candidate findings tied to evidence as they move through reviewer disposition. It cannot walk the site, certify field conditions, interpret the contract by itself, or accept turnover for the owner. See our construction intelligence and project controls overview.

#The owner should not need the project team's memory

Closeout is complete when the receiving team can find the current record, see what it applies to, verify its acceptance, and understand any exception—without relying on the memory of people already moving to the next job.

Before turnover, choose one system and test whether its records tell the whole story. Request a scoped pilot.

The drawings are there. So are the specifications, addenda, scope exhibits, RFIs, submittal log, and schedule. Every file has a name. Most of them even have a date.

That still does not tell the reviewer which revision governs, whether an exclusion collides with a drawing note, or whether a required approval happens before the material is needed.

The review starts with a simpler question: which document actually governs?

#"Complete" is not a file count

A review-ready package lets someone trace a requirement from the question in front of them to the current governing source.

For example: Which drawing shows the detail? Which specification defines the material and testing? Which addendum changed it? Which scope exhibit assigns the work? Which submittal needs approval? Which schedule activity depends on it?

If that chain breaks, the package has an evidence gap—even when every expected folder is populated.

The submittal procedures in UFGS 01 33 00 offer a useful benchmark. The guide calls for each submittal to be complete and detailed enough to determine compliance, for quality control before submission, and for proposed deviations to be clearly identified.¹ Those become requirements when the guide specification is tailored and incorporated into a contract; they are not a universal private-contract rule. Private contracts differ, but the test is useful anywhere: can the reviewer trace the decision to the governing requirement?

#Start with authority and revision, not interpretation

The fastest way to waste a review is to analyze the wrong set.

Before looking for scope gaps, build a short package manifest:

1. Contract and incorporated exhibits
2. Drawing index, issue date, and latest revisions
3. Specification table of contents and revised sections
4. Addenda, bulletins, ASIs, and accepted clarifications
5. Bid forms, allowances, alternates, and unit prices
6. Subcontract scope, inclusions, exclusions, and clarifications
7. Open RFIs and submittals that could change the reviewed work
8. Current schedule file, data date, and relevant procurement milestones

The point is not administrative neatness. It is to establish which document controls each question.

Do not assume every project uses the same order of precedence. Federal Acquisition Regulation clause 52.236-21, for example, gives specifications precedence over drawings for the federal contracts where that clause applies and requires discrepancies to be submitted for a written determination.² Your project may say something different. Read the executed contract before deciding that one document automatically overrules another.

#Review across document boundaries

Many consequential package questions do not live on one sheet.

Take a rooftop unit curb. The architectural detail may show the opening. The mechanical schedule identifies the equipment. The specification adds testing and warranty requirements. The roofing scope excludes patching. The controls scope assumes another trade provides a sensor. The project schedule shows installation but no submittal approval or delivery activity.

No single document has to be obviously wrong for the package to be unready.

The issue sits between the documents.

That is why a useful review compares the drawing, specification, scope, submittal, and schedule as one chain. A sheet-by-sheet review can miss a gap that becomes obvious only when those sources are compared.

#Eight checks that make the package reviewable

The Federal Highway Administration's constructability checklist is unusually concrete. It asks whether bid schedules, quantity tables, material references, plans, and cross-sections agree; whether pay items cover all work; whether major incidental items were overlooked; and whether the schedule includes enough time for submittal review and approval.³

For a trade or document package, turn that discipline into eight checks:

1. Package identity

Can every file be tied to the right project, package, issue, and revision? Quarantine superseded files instead of leaving two plausible "latest" versions in the review set.

2. Governing-source coverage

Can each major scope item be traced to a contract requirement, drawing, specification, accepted clarification, or other governing record? Flag references to missing sections, sheets, exhibits, or attachments.

3. Scope alignment

Compare the work shown and specified with the subcontract inclusions, exclusions, clarifications, allowances, and by-others language. Record the source on both sides of a potential gap.

4. Quantities and units

Check schedules, details, plan tables, scope sheets, and bid forms for mismatched counts, dimensions, units, or locations. Do not convert a difference into a finding until the source and measurement basis are clear.

5. Variations and substitutions

Separate an approved variation from an unapproved assumption. UFGS 01 33 00 calls for proposed deviations to be identified; FAR 52.236-21 likewise requires shop-drawing variations to be described in writing for the federal contracts it governs.¹²

6. Review and approval path

Identify what must be submitted, who reviews it, what status counts as approval, and what remains unresolved. "Sent" and "approved" are not the same state.

7. Schedule and procurement tie

Link critical submittals to approval-needed, material-needed, fabrication, delivery, and installation dates. The federal submittal-register template preserves these ties because a log without timing cannot show whether a decision is already late.¹ The same tie is the subject of a companion post on reading a P6 schedule file for exactly these dates.

8. Ownership and disposition

Every candidate issue needs an accountable reviewer and a recorded outcome: confirmed, dismissed, clarified, assigned, or waiting on evidence. A long issue list without disposition is only a second backlog.

#Use an evidence-gap register, not a red-flag dump

A simple register is enough:

The wording matters. "Missing firestopping" is a conclusion. "Detail A-501 shows a rated penetration; the reviewed Division 07 scope contains no corresponding firestopping inclusion" is a reviewable question. It gives the responsible people somewhere to start.

#What software should—and should not—do

Software-assisted review can help teams compare records, surface candidate mismatches, and keep questions connected to their source context.

At SP4N, candidate findings carry evidence references, missing evidence is made explicit, and the reviewer controls the disposition. The aim is to help a professional reviewer navigate the package—not decide contract meaning for them. You can see that approach in our construction project controls overview.

#The real definition of done

A package review is not complete because every file uploaded successfully. It is complete when the team knows:

• which sources govern;
• what evidence is missing or inconsistent;
• which questions affect scope, schedule, procurement, or closeout;
• who owns each decision; and
• how every candidate finding was resolved.

That is a package someone can act on.

Start with one trade package and one decision deadline. Ask us about a scoped pilot.

A schedule can look busy and still omit the chain that determines when the job finishes.

#Begin with the file's identity

Before reviewing float or the longest path, establish what you actually received.

At minimum, record:

• project and contract identifier;
• schedule type: baseline, recovery, update, or what-if;
• file name and source;
• Primavera P6 version or export compatibility;
• data date;
• reporting period;
• baseline assigned for comparison; and
• the narrative, change log, and reports delivered with the file.

UFGS 01 32 01.00 10 separates compatibility from content. For projects using that federal template, it calls for an importable P6/XER file and separately requires the schedule type, contract number, data date, unique file name, narrative, and reports.¹ A receiving tool parsing an export establishes neither field preservation across systems nor the quality of the schedule inside it.

#1. Does the schedule cover the work?

Start with scope before calculating anything.

The U.S. Government Accountability Office's Schedule Assessment Guide organizes ten best practices under four characteristics: comprehensive, well-constructed, credible, and controlled.² Its first point is the most basic and the most easily skipped: capture all activities needed to complete the work, including work performed by both the owner and contractors.

For construction, compare the schedule against the work breakdown structure and the documents that define delivery. Look for:

• design packages and permits;
• owner, utility, and authority approvals;
• critical submittal preparation, review, resubmission, and approval;
• procurement, fabrication, delivery, and inspection;
• access, shutdown, or seasonal work windows;
• testing, adjusting, balancing, and commissioning;
• O&M manuals and as-built drawings;
• pre-final inspection, punch correction, and final inspection.

UFGS 01 32 01.00 10 explicitly calls for many of these activities in the schedule used under that specification. It also defines "long lead" for its template as a procurement sequence over 90 calendar days.¹ That 90-day threshold is not a universal industry definition. Whatever the contract's threshold, every material or assembly capable of controlling the work needs a visible approval-to-delivery chain.

If switchgear installation is in the file but the approved-submittal, release, fabrication, factory testing, delivery, and setting activities—where required or controlling—are not, the schedule may not be modeling the whole path.

#2. Is the logic a real execution plan?

Dates alone do not explain why one activity follows another.

Trace the major work paths and look for:

• activities without predecessors or successors;
• excessive lags standing in for actual work;
• hard constraints that force a desired date;
• start-to-finish relationships that need explanation;
• out-of-sequence progress left unresolved;
• summary activities used as logic anchors; and
• calendars that make the relationship physically implausible.

The federal UFGS template permits only the first and last activities to remain open-ended and requires other activities to carry predecessor and successor logic.¹ A different contract may set a different rule, but open ends remain a useful diagnostic. An unexplained open end can keep a delayed activity from affecting anything downstream.

Read the logic against how the work will be built. A finish-to-start link from "submit shop drawings" directly to "install equipment" is not enough if approval, procurement, fabrication, delivery, and inspection sit between them.

#3. Can you reproduce the critical path and float story?

"Critical" is not a color applied to a bar. It is the result of the schedule's logic, calendars, durations, constraints, and status.

GAO recommends validating the critical path and checking whether total float is reasonable.² In practice, that means asking:

• Does the longest path run through work that could actually control completion?
• Does it terminate at the contractual completion milestone?
• Do major interim milestones have their own driving paths?
• Did a constraint, calendar, or lag create the result?
• Are high-risk near-critical paths visible, or hidden behind an arbitrary float threshold?
• If the path changed this period, does the narrative explain why?

Do not review total float as an isolated ranking. Two activities with the same float can carry very different field, procurement, and contractual consequences. The number needs its logic and source context.

#4. Do durations and calendars match the work?

A five-day activity means nothing until you know which five days count.

Review base calendars, holidays, shift patterns, weather or seasonal calendars, owner-review calendars, and special shutdown windows. Then inspect whether they are assigned to the right activities.

Durations deserve the same scrutiny. Long activities can hide progress. Extremely short activities can create a false sense of precision. GAO's guide calls for realistic activity durations and resource assignments; the appropriate detail should allow progress to be measured without turning the file into noise.²

For unusual durations, constraints, lags, or calendars, ask for the basis. A schedule is easier to govern when assumptions are written down rather than reverse-engineered after the date moves.

#5. Do the actuals agree with the field record?

The data date divides actual history from forecast work.² Treat it as a hard boundary.

Check actual starts, actual finishes, remaining durations, percent complete, and out-of-sequence work against daily reports, approved pay quantities, meeting records, and other accepted project records. Reconcile exceptions; do not automatically overwrite one source with another.

UFGS 01 32 01.00 10 disallows software defaults that automatically assign actual start and finish dates under its federal contract template. It also requires those dates to match the contractor quality-control reports.¹ A date becomes an actual because the work record supports it, not because the scheduling software needed a value.

#6. Does the update explain its changes?

A monthly file should not arrive as an unexplained replacement for last month's file.

Compare the current update with the prior accepted update and baseline. Review:

• added and deleted activities;
• logic changes;
• duration and remaining-duration changes;
• calendar changes;
• lag changes;
• constraints;
• changed actual dates;
• changed longest path; and
• milestone variance.

The UFGS schedule narrative calls for activity-level explanations of these changes and discussion of out-of-sequence work and longest-path movement.¹ GAO similarly treats regular status updates and controlled baseline maintenance as separate best practices.²

Variance is not automatically a problem. Unexplained variance is.

Retain the evidence behind the review: file identity, a scope crosswalk, logic and path reports, the basis for calendar or duration exceptions, records supporting actuals, and the disposition of each change. That trail turns "the schedule looks wrong" into questions someone can verify.

#Where SP4N fits

SP4N can import supported Primavera schedules, including XER or PMXML files. Compatibility varies by customer environment and file. A reviewer can work through flagged schedule questions with the source context alongside them and record the disposition.

The import does not certify the schedule or make it contract-compliant. Learn more about source-linked construction project controls and construction schedule risk review.

#The file opening is the start of the review

A reliable schedule is a controlled model of the work, the handoffs, the current status, and the assumptions behind the forecast. P6 rendering shows that the file is readable; confidence comes from tracing the forecast through its logic and back to the project record.

Have one schedule update and the records behind it? Talk with us about a scoped pilot.

This happens constantly, and it is not a bug. It is the documented behaviour of the format, and Oracle publishes the list of what it drops. Almost nobody reads that list, which is why this keeps being a surprise.

#It is a database export wearing a text file's clothes

An XER is not a document format. It is a set of relational tables serialised into tab-delimited plain text, one block per table, with a header record naming the export version and the database that produced it. Open one in a text editor and you can read it. That is not an accident of the design — it is the design.

Oracle publishes the table-level map in its XER Import/Export Data Map Guide, which names the tables and every field inside them: TASK for activities, TASKPRED for activity relationships, PROJWBS for the WBS, CALENDAR for calendars, TASKRSRC for resource assignments, and the UDFTYPE / UDFVALUE pair for user-defined fields.¹

#Three tables carry the schedule. The rest describe the world it lives in

TASK holds the activities — ids, durations, dates, constraints, percent complete, activity type. TASKPRED holds the relationships: predecessor, successor, relationship type, lag. Between them you have a network. Everything else is context, and the context is where the quiet failures live.

CALENDAR is the one that catches people. Two schedules with byte-identical TASK and TASKPRED tables and different calendars do not finish on the same day, and calendars are imported by name. Import into a database that already owns a calendar called "5 Day Workweek" and you find out what that database means by it, not what the sender meant.

User-defined fields are split across two tables — UDFTYPE declares them, UDFVALUE holds the values — which is why a naive parser that reads activities and relationships and stops will silently lose every custom field on the project. If your risk register, your responsible party, or your commissioning sequence lives in a UDF, it lives in the table most likely to be dropped by whatever is reading the file.

#What Oracle says it drops

From that guide, in Oracle's words rather than ours:²

• Baselines. "XER does not support the export of baselines. XML supports the export of baselines." The same sentence appears again for import. If your delay analysis needs the baseline, XER cannot carry it — and a schedule without its baseline cannot be measured against anything.
• Risk data. "When connected to a P6 EPPM database: No risk data is exported when using XER format."
• Past-period actuals. On import, "the financial periods in the XER file must exactly match the financial periods in the Financial Periods dictionary. If they do not match, no past period actual data will be imported." Exactly match. Not approximately.
• Secure codes. "When you export project data, secure codes and secure code assignments related to the project are not exported."
• Resource curves, on the Microsoft Project path: "The MPX file format does not support resource curves." Oracle also states plainly that "P6 Professional does not export past period actual data to Microsoft Project."

Every one of those drops is silent. The import reports success.

That is the whole problem in one sentence. A format that failed loudly would be an inconvenience. A format that succeeds while discarding your baseline is a trap, because the schedule you now hold looks complete.

#The settings that travel as a number but not as a behaviour

P6 decides how to handle out-of-sequence progress with a project-level scheduling option. Oracle's definitions are precise: under Retained Logic, "the remaining duration of a progressed activity is not scheduled until all predecessors are complete." Under Progress Override, "network logic is ignored and the activity can progress without delay." Under Actual Dates, "backward and forward passes are scheduled using actual dates."³

Those three settings produce three different completion dates from identical activity and relationship data. Which means the dates in a schedule are not a property of the network alone; they are a property of the network plus a setting somebody chose.

Our reading of Microsoft's published MSPDI schema is that it has no field carrying that setting — and we want to be clear that this is our reading of the schema rather than something either vendor states. MSPDI is a real, published Microsoft schema (mspdi_pj12.xsd, defined for Project 2007 and documented on Microsoft Learn),⁴⁵ but it is Microsoft Project's data model, and Microsoft Project does not have P6's concept. So the setting does not survive the trip, the receiving tool applies its own scheduling behaviour, and the dates change without anything appearing to go wrong.

#Why .mpp is a different problem entirely

XER and MSPDI are interchange formats — one vendor-documented, one schema-published. Binary .mpp is neither. It is Microsoft Project's native store, and there is no published specification for it.

The clearest evidence of what that costs comes from MPXJ, the long-running open-source library that reads project files. Its maintainers, after two decades of reverse engineering, say writing MPP remains out of reach: "the knowledge we have of the file structure is still relatively incomplete, despite the amount of data we are able to correctly extract."⁶ Their support matrix is the practical summary — MSPDI can be read and written, XER and PMXML can be read and written, and MPP is read-only.⁷

This is why serious schedule tooling asks for XER or XML and not for .mpp, and it is why SP4N parses MSPDI XML where it is available and does not parse the binary .mpp directly. Saying so is more useful than implying otherwise: a tool that claims to read .mpp is either converting it first or is going to disappoint you on a schedule that matters.

#What to check on every schedule you receive

There is an off-the-shelf answer for the structural half of this. The DCMA 14-Point Schedule Assessment — Section 4.0 of DCMA-EA PAM 200.1 — defines fourteen named checks: Logic, Leads, Lags, Relationship Types, Hard Constraints, High Float, Negative Float, High Duration, Invalid Dates, Resources, Missed Tasks, Critical Path Test, Critical Path Length Index, and Baseline Execution Index.⁸ They are concrete and quantitative. The Logic check, for instance, flags incomplete tasks missing a predecessor or successor and sets the tolerance at 5% of incomplete tasks.⁸

What DCMA does not check is whether the file you received is the file that was sent. That is the gap this whole post is about, and it needs three questions the 14 points do not ask:

• Did a baseline arrive at all, or only a current schedule? If it came as XER, the answer is no, and no amount of analysis will conjure one.
• Do the calendars in the file match the calendars now applied, by definition rather than by name?
• Which out-of-sequence progress setting was the sender using — and did anyone write it down before the file changed hands?

Then run the structural checks, because a schedule can be intact on arrival and still be unusable. Missing logic and hard constraints are what make float meaningless, and float is what every downstream question depends on — including whether that weather day was a delay or just float consumption. How the same data drives per-activity scoring is on the construction delay risk page.