Concepts

The ideas the tool is built on, for a scheduler.

Everything here has the same shape. A published standard leaves a question open. Software has to answer it anyway in order to produce a number. Most software answers it silently, in a setting nobody looked at, and the number comes out looking like arithmetic. This tool answers it out loud, or refuses.

You will meet several of these refusals as apparently missing features. Each section below explains why the refusal is worth more to you than an answer would be.

1. The AACE five-layer taxonomy, and why "TIA" is ambiguous

The problem the taxonomy solves

Common names for delay analysis methods are loose and regionally inconsistent. AACE RP 29R-03 says so directly of TIA: it has "a bewildering array of regional variations". So the RP does what Linnaeus did with species — it fixes a taxonomic skeleton, gives every method a coordinate in it, and lets the common names map onto the skeleton many-to-one.

There are five layers.

Layers 2, 3 and 4 together locate a Method Implementation Protocol — a MIP. There are nine, numbered 3.1 to 3.9, and those numbers are the citation a reviewer checks against the document.

Layer 1 is constant across all nine: every MIP in 29R-03 is retrospective. The RP is emphatic about a trap here. An analysis performed after completion is retrospective by point of view, even when the technique it uses is forward-looking. Impacting an as-planned programme six months after handover is not a prospective analysis because it inserts fragnets into a plan. It is a retrospective analysis using an additive technique.

Layer 5 is not a tenth MIP. It is a choice within a MIP, so the tool carries it as an attribute rather than as a coordinate. Promoting it would produce method codes the RP does not recognise, and a report citing "MIP 3.6-stepped" cites something that does not exist. The tool refuses a Layer 5 choice the MIP does not offer: gross and single-base implementations have one period by definition, so asking for a "fixed-period gross analysis" raises an error where it is constructed rather than printing in a report.

The negative space is load-bearing too. Fragnet modelling, bar-charting, Gantt charts, linear graphing and time-chainage are tools, not methods, and the RP excludes them from the taxonomy explicitly. Ask this tool for "a bar chart analysis" and it tells you that it is a presentation layer, with the citation — rather than looking like an unimplemented feature.

Why "TIA" cannot be resolved

Work through the layers for a Time Impact Analysis.

You know it is retrospective (Layer 1, always). You know it is modelled — fragnets are inserted, so the analyst alters the schedule (Layer 2). You know it is additive — delays are added to a plan rather than removed from an as-built (Layer 3). At Layer 4 you stop, because the name does not tell you whether the fragnets went into:

• one base schedule — that is single base, and the MIP is 3.6; or
• a separate contemporaneous update for each event — that is multiple base, and the MIP is 3.7.

Those are different analyses. On the same events and the same project they produce different numbers, because 3.6 measures every event against a plan that never changed, and 3.7 measures each event against the schedule as it actually stood when that event happened.

So resolve("TIA") raises, and the exception carries the question:

'TIA' could mean MIP 3.6, 3.7. Was the delay modelled against one base schedule (3.6) or against a separate contemporaneous update per event (3.7)?

Two other common names are ambiguous in the same way:

Unambiguous names resolve normally. resolve("impacted as-planned") returns MIP 3.6 with the formal name Modeled / Additive / Single Base. So does resolve("3.6").

The small example

You are handed an expert report headed "Time Impact Analysis — 47 days".

Ask one question: which schedule was each fragnet inserted into? If the answer is "the approved baseline" the method is MIP 3.6 and the analysis has ignored every update the project produced — including any showing the contractor already critically late before your event. If the answer is "the update current at the time of each event" the method is MIP 3.7, and the 47 days is measured against what was actually happening.

Both are legitimate methods, and both are defensible on the right facts. But they are not the same finding, and a report that says only "TIA" has not told you which one you are reading. That question is the entire content of the tool's refusal.

2. Why the tool reports two answers to "what is critical"

There is no single definition of the critical path. AACE RP 49R-06 documents four operational methods for identifying it and then declines to endorse one, on the ground that no absolute standard for what counts as a proper CPM calculation procedure exists. AACE RP 10S-90 split "critical path" and "longest path" into separate headwords in its December 2023 revision for the same reason.

Two schools:

• Total float. An activity is critical if its total float is at or below the threshold — usually zero. Reported by the engine as critical_ids.
• Longest path. The critical path is the driving chain, walked back from the activity that sets the project finish. Reported by the engine as longest_path().

Primavera hides this behind a single project-level setting, so a P6 schedule reports one answer and silently discards the other. This engine computes and reports both, and there is a test that fails if the two answers ever collapse into one.

The small example

Two parallel routes between the same two nodes, of exactly equal length:

        ┌── B (10d) ──┐
A (5d) ─┤             ├─ D (5d)
        └── C (10d) ──┘

B and C both have zero total float, so by float, both are critical. But the driving chain that sets D's early start runs back through only one of them — whichever the engine's back-walk lands on. By longest path, one is critical and the other is not.

Neither answer is wrong. They answer different questions. "Which activities have no spare time?" is a float question. "Which work is actually pushing the completion date?" is a longest-path question.

This matters commercially because specifications pick sides. UFGS 01 32 01.00 10 §3.12(f) requires critical activities to be defined as Longest Path, not by total float. A schedule submitted with P6's float setting is non-conformant on that clause, and the tool checks it (rule UFGS-098) by reading the file's own recorded scheduling options rather than the ones the tool would have chosen.

ASCE 67-17 §5.1 makes the same point from the other end: criticality is not equivalent to longest-path membership, and the tool reports when the two diverge in the network as computed (rule ASCE-67-17-5.1, one of only three DETERMINISTIC rules in that pack).

3. Why the data date convention matters

A data date of 1 February means one of two things:

• THROUGH — work is reported through and including 1 February. An actual finish recorded on 1 February is history.
• TO — 1 February is the first day of the next reporting period. Work is reported through 31 January, and an actual finish recorded on 1 February is a claim about work that has not happened yet.

AACE RP 10S-90 records this as unresolved, and it is unresolved in practice: schedulers, specifications and software disagree, mostly without noticing that they disagree.

The failure it causes is quiet by construction. Both readings produce a schedule that looks right. Nothing in a review catches it. The difference shows up as a one-day discrepancy per window boundary between two analysts, which over eleven monthly updates is eleven days of argument generated entirely by an assumption neither of them ever stated.

The small example

Activity FDN-04, actual finish recorded as 1 February. Data date 1 February.

Under THROUGH, FDN-04 is complete, its successor's early start is computed from 2 February, and the window that closes on 1 February owns whatever delay FDN-04 carried.

Under TO, that actual finish is in the future. The engine raises a progress issue (PROGRESS.ACTUAL_IN_FUTURE), FDN-04 is not treated as history at this data date, and its delay lands in the following window.

One day. But the two windows are usually owned by different parties, and the delay has just moved between them.

The tool's position: it does not decide which reading is correct — the RP declines to say, and so does the tool. It requires the reading to be chosen, recorded on the result, and printed in the report as one of the "choices that could have gone the other way". The default is THROUGH, because that matches what Primavera does with an actual finish recorded on the data date: it accepts it. That is a compatibility argument, not a correctness one, and the report says so.

4. Why progress mode changes the finish date

When a successor starts before its predecessor finishes, the field has already worked around a logic tie that the schedule still contains. Primavera offers three ways of dealing with that, and this engine implements all three as a transformation of the link set applied before the forward pass — so the CPM kernel never learns that progress exists, and each mode is testable as "which links survived, and why".

Strictly nested, so finish(override) ≤ finish(actual_dates) ≤ finish(retained) always. That ordering is what makes "this schedule honoured the mandated mode" a checkable claim.

The small example

Three activities, Monday-to-Friday calendar, data date 3 February 2025:

• A — 20 days, actually started 6 January, 10 days remaining, not finished.
• B — 10 days, actually started 20 January (before A finished), 5 days remaining.
• C — 10 days, not started.
• Logic: A → B → C, both finish-to-start.

B started out of sequence. A is still open. What now?

(Finish dates shown as the last worked day; the engine stores finishes as exclusive day boundaries, so it reports 8 March and 22 February respectively.)

Retained logic says: the tie A → B still binds, so B cannot finish until A finishes, C follows, and the job runs two weeks longer. Progress override says: the tie is dead, B runs off its own remaining duration from the data date, and the job is two weeks shorter. Actual dates agrees with override on these facts because A has no actual finish at all — the recorded dates contradict the logic — but it would agree with retained logic on facts where they do not.

Two weeks of project finish, from a setting. That is why UFGS 01 32 01.00 10 §3.12(g) mandates Retained Logic and §3.3.17 prohibits Progress Override on USACE work: a schedule computed under the wrong mode is optimistic by exactly the logic that was dropped. The tool checks the mode as the file declared it (rules UFGS-052 and UFGS-099), not as the tool would have set it, because the question is what the submitter scheduled with.

One caveat, stated because it is load-bearing: ACTUAL_DATES is this project's interpretation of Primavera's behaviour, not a reproduction of it. See LIMITATIONS.md §3.

5. Why concurrency has no single answer

The most argued number in construction disputes, and the one place where the tool most conspicuously declines to give you a figure under US law.

cpmcore will report a concurrency_days residual — the gap between what delay events do individually and what they do together. That number is arithmetic, and it is evidence of concurrency, not a finding of it. A positive residual is equally consistent with two events feeding one successor, or a constraint absorbing both, or (on a multi-calendar network) the day-count basis simply failing to reconcile. It does not tell you the delays were concurrent in any sense a tribunal recognises.

The determination layer is separate, and it returns more than one answer, because there are two live axes and the standards agree on neither.

Axis 1 — what "at the same time" means

• Literal theory. The delays must occur at the same time in the strict sense. Fewer concurrency findings, more compensable delay for both sides.
• Functional theory. They need only fall within the same analysis period — or, in the SCL Protocol's framing at ¶10.4, their effects need only be felt on the critical path at the same time, even where the events arose weeks apart. More concurrency.

AACE RP 29R-03 §4.2.D.1 sets out both without endorsing either, and §4.2.D treats the choice as one for the analyst to make and defend.

The two converge as the analysis interval shrinks to one day. The tool makes that checkable rather than asserting it: analysis_interval_days is an explicit argument, defaulting to 1.

A caveat this project has not resolved. AACE states the literal/functional distinction as one of interval granularity. The SCL Protocol states its ¶10.3 / ¶10.4 distinction as one of events-versus-effects. The tool treats them as the same axis because in practice they select the same two answers on the same facts — but they are not textually the same distinction and no source equating them has been found. A report resting on the difference should cite the paragraph, not this tool.

Axis 2 — which of two overlapping delays is the cause

Where an Employer Risk Event begins after a Contractor Delay to Completion is already running (SCL ¶10.7–10.9):

• Concurrent effect. Older English appellate authority: both are effective causes over the overlap.
• First in time. Adopted by the 2017 Protocol at ¶10.10: only the contractor's delay is an effective cause, because the works were going to complete late regardless. The employer event causes no incremental Delay to Completion — so there is no concurrency at all.

Same facts, opposite answers, and the difference is the whole claim.

What the tool returns

Two theories × two doctrines = four findings, all reported. Then:

• Under UK_SCL, the SCL Protocol governs and has an encoded position, so governing() returns the functional / first-in-time finding.
• Under US_FEDERAL, US_STATE_OR_PRIVATE and NEUTRAL, the first authority in the precedence with a concurrency position is AACE, and AACE has none. governing() returns None, with unresolved_reason explaining which document declined and why.

None is not a gap in the implementation. It is the accurate answer. A tool that picked one to avoid returning None would be manufacturing exactly the certainty that gets an expert excluded rather than merely disagreed with.

The small example — the interval knob

Two delays, both shown to be independently critical:

• OWNER-RFI — owner risk, 2 June to 11 June 2025.
• CONT-CREW — contractor risk, 9 June to 20 June 2025.

They overlap on 9, 10 and 11 June: three days.

At monthly granularity the functional theory buckets both delays into the same period and finds the whole period concurrent. The literal theory does not. One knob, a tenfold difference, and AACE §4.2.D.1 makes that a property of the theory rather than an error.

Under US_FEDERAL, all four findings are reported and governing() returns None. Under UK_SCL, the functional / first-in-time finding governs.

The small example — the doctrine knob

Now change the facts so the contractor is late first, and the owner's event has not been shown to be independently critical:

• CONT-CREW — contractor risk, 2 June to 20 June 2025, independently critical.
• OWNER-RFI — owner risk, 9 June to 18 June 2025, not independently critical.

Ten days of concurrent delay, or none, from the choice of causation doctrine on identical dates. Under UK_SCL the tool selects first-in-time (0 days) and records the other as a divergence, naming both numbers. Under US jurisdictions it selects nothing and reports all four.

What the tool deliberately never computes

• Float ownership. General Principle 3 makes network float shared and consumed first-come-first-served absent contrary contract terms; AACE §4.3.E adds that project float — the gap between the schedule's own last activity and a later contractual completion date — is by default the contractor's, which is a different quantity under a different default. SCL CP8 gives three contractual patterns and says which applies is a contract question. The tool raises the question and never answers it. A tool that assigned float would be answering a legal question with an algorithm.
• Pacing. A contractor who slows work in response to an owner delay is pacing, not delaying, and the difference is the difference between a concurrent contractor delay and no contractor delay at all. Of AACE §4.2.G's three tests, the tool computes only the first (that a parent delay exists and precedes the pacing). The second — contemporaneous ability to resume — and the third — contemporaneous evidence of intent — are not computable from a network. The result is marked HYBRID or JUDGMENT and is never DETERMINISTIC.
• Whose delay it was. party is carried, never inferred.

Two axes of entitlement, not one

Collapsing excusability and compensability into one enum is a common and expensive error. SCL CP12 is explicit that EOT entitlement and compensation entitlement are independent, and CP10/CP14 make the asymmetry operative: once concurrency is established the contractor gets its full extension of time (CP10, ¶10.12, resting on the prevention principle at ¶10.16) but recovers only the costs it can separate from those it would have incurred anyway from its own delay (CP14, ¶14.3). The tool's Entitlement object refuses at construction to be compensable and non-excusable at once.

A unit warning

Every days figure in the concurrency module counts calendar dates in an overlap window, inclusive of both ends. That is the right axis for "over which dates were both parties in critical delay" and the wrong axis for entitlement arithmetic. The modelled-delay EventImpact.days counts working days on a named calendar. The two numbers must never be added to or subtracted from one another. They measure different things on different axes.

6. Which standard governs, and what happens when two disagree

There is no single authority on delay analysis. Four matter, they overlap, they conflict on specifics, and which one governs is a contractual fact about the project, not a preference of the analyst.

The tool's precedence, per jurisdiction:

NEUTRAL is not "no standard". It means no document has been shown to govern yet. It is a prompt, not a default, and the result is flagged assumed=True so the report prints "AACE RP 29R-03 (assumed; no governing document established)" rather than stating a fact nobody established. Treating "we were not told" as "the usual one applies" is how an assumption becomes a finding.

If the contract names a standard the jurisdiction's default order does not put first — a state DOT specification adopting ASCE 67-17 outright, say — pass it as a contract-named authority and it moves to the front, in the order given. A named document beats an inferred one.

Conflicts are recorded, not resolved. Where two governing documents answer the same question differently, the tool follows the one that binds and prints that the other said otherwise. Two conflicts are currently encoded, both located by reading both sources:

1. Which standard governs on US federal work — reported under us_federal and neutral. ASCE 67-17 binds per UFGS 01 32 01.00 10 §3.8.4; AACE 29R-03 is the more widely cited taxonomy and is frequently applied by default, including on federal work where it does not govern. This is the precedence most often got wrong, and it is expensive exactly where it is wrong.
2. Concurrent delay causation — reported under uk_scl and neutral. The SCL Protocol treats true concurrency narrowly and applies first-in-time; AACE presents both theories without endorsing one.

The tool's own governance is itself checkable. UFGS-083 (§3.8.4) is a DETERMINISTIC rule that fails CRITICAL if the configured precedence contradicts §3.8.4 — because an analysis configured under the wrong authority will produce a defensible-looking number, and that is worth checking before anything else in the pack is believed.

7. Validating the inputs before believing them

AACE RP 29R-03 §2 opens with the proposition the whole tool depends on: however reliable a delay analysis method is, and however carefully it is carried out, it still fails if the data it is given is flawed.

The Source Validation Protocols are the least glamorous section of the RP and the one that decides whether anything downstream means anything. Essentially no commercial tool does them.

Validation here is functional, not qualitative: is the schedule computable and usable for CPM analysis? The RP's own test is explicit and is stated here in this project's words rather than its: if the project could be built the way the schedule says and still meet the contract, the analyst makes no subjective change to improve it (AACE RP 29R-03 §2, Source Validation Protocols). Nothing in the SVP module improves a schedule. A tool that quietly optimises the baseline it was asked to validate has manufactured the comparison it then reports on.

Two SVP procedures are worth understanding because they change numbers.

De-statusing (SVP 2.1.D.3)

Used when the baseline itself is missing and the earliest surviving artefact is an update — which happens more often than it should, and is otherwise the point where an analysis quietly proceeds without a baseline at all.

The transform is mechanical: clear actual start and finish, zero percent complete, set remaining duration back to the original duration, move the data date back to the project start.

The trap the RP names is the original duration. It must be the duration that was reasonable at NTP, not the duration the activity turned out to take. Defaulting to the progressed file's own duration field is correct only where the update did not revise it, and nothing in the file says whether it did. So the tool takes the default, names every activity it took it for, and refers the question.

Hindsight and blindsight remaining duration (SVP 2.3.D.1)

These reconstruct what an in-progress activity's remaining duration would have been at a data date for which no update exists.

hindsight:   RD = actual_duration − (DD − AS)
blindsight:  RD = OD − (DD − AS)   where (DD − AS) < OD
             RD = 1                where (DD − AS) ≥ OD

Hindsight back-calculates from how the activity actually went. It produces the schedule the analyst would have written knowing the ending, and it can only be used where the succeeding period is known. Blindsight assumes straight-line progress against the original duration and by construction cannot see forward of the data date. It produces the schedule the project team could have written on the day.

The RP records that there is no prevailing practice on the choice and recommends computing both and comparing where they differ. So the tool computes both, always, and requires the caller to name the one it applies — there is no default and there never will be. Where the two agree, nobody needs to argue it. Where they diverge, the divergence is the finding: it is the size of the advantage hindsight confers, in days, on that activity, and it is reported with both numbers.

The tool resolves two gaps the RP leaves, explicitly rather than silently:

• The RP gives no branch for (DD − AS) == OD. The activity is in progress, so it has not finished, so a remaining duration of zero would be a false statement. The one-day floor applies.
• The RP does not say what a negative hindsight result means. It means the activity was already complete at the data date being reconstructed, so it is reported as zero with a hindsight_clamped flag rather than as a negative duration no scheduler will accept.

Bifurcation (SVP 2.3.D.2)

Splits one update's variance into what the work did and what somebody changed about the plan.

The half-step H1 is the earlier update with only the progress from the later one applied to it — actual dates, increased percent complete, decreased remaining duration — recalculated at the later update's data date. The difference between the earlier update's finish and H1's is what the work actually did. The difference between H1's and the later update's is what somebody revised.

The two components sum to the whole movement exactly, and the tool checks that on the way out rather than trusting it. All three schedules are recalculated with the same options, so a settings difference cannot leak into the decomposition and be reported as a revision.

MIP 3.4 is this procedure applied to every update in the chain, and it is the only observational method that separates the two.

The RP's list of non-progress revisions is stated as exhaustive, and the tool detects: activity added or deleted, link added or deleted, lag changed, constraint changed, original duration changed, remaining exceeding original, remaining changed without progress, remaining increased on an unstarted activity, calendar changed. Activity split and combine is the one item it does not detect as itself — a split produces new activity ids, so it surfaces as an addition plus a deletion. Recognising it as a split needs the mapping between old and new activities, which the schedules do not carry, and inferring one from name similarity would put a guess in the middle of a variance decomposition.

8. The evidentiary record

Two hashes, because there are two objections.

• The file digest is over the bytes as received. It answers "is this the file you were given" and nothing else. It is what makes a schedule file a candidate for self-authentication under FRE 902(14), and it survives the tool being wrong about everything else: an opposing expert who disputes the parse can still verify it started from their file.
• The model digest is over the parsed network — activities, logic, calendars — in a canonical form. It answers a different objection: "you read that file differently than P6 does." Two importers can produce different models from identical bytes (a swallowed calendar exception, a coerced relationship type), and a file digest cannot see that.

Recording only one leaves a real gap. A file digest alone proves custody of bytes nobody has shown you understood. A model digest alone proves you analysed something consistently, with no tie back to the evidence produced in the case.

Gap detection is stated as observation, never as accusation. FRCP 37(e)'s severe sanctions require a finding of intent to deprive, and whether a duty to preserve had attached, whether reasonable steps were taken, and whether anyone intended anything are questions for a tribunal on evidence this tool does not have. So every finding states an observable fact about the documents provided and stops. "Updates 7 and 8 are absent from the set provided" is a fact. "Evidence was destroyed" is an accusation the tool is not entitled to make, and — put in an expert's report by a tool — the kind of overreach that gets the whole analysis excluded. The most common innocent explanation for a missing update is that nobody sent it. Every gap finding says so, deliberately, every time.

What detect_gaps looks for: update numbers absent from the run provided; duplicate update numbers; an unusually long interval between consecutive data dates (relative to the job's own median interval, default ratio 2.0, or a stated submission interval — the softest check, reported as an observation only); a baseline whose data date falls after the earliest update's; and a snapshot with no data date, which under §1.5.B(2) cannot be placed in the chain at all.

The FRE 902(13)/(14) certification the tool produces is a draft for a qualified person to review, adopt and sign. It is not a certification until a person with knowledge signs it, and the tool cannot be that person. Two limits that must not be lost: self-authentication addresses authenticity only, not hearsay — a self-authenticated record still has to get past FRE 802 — and Rule 902(11)'s procedure, which (13) and (14) incorporate, requires reasonable written notice to the opponent and an opportunity to inspect. Missing that step forfeits the benefit.

9. The seven General Principles

AACE RP 29R-03 §1.5.B states seven principles as universal rules rather than method-specific ones, so they belong to the engine rather than to any one method. A conformance finding can cite the principle it rests on instead of asserting a house rule.

Principle 7 is why the command line takes every file you give it rather than a baseline and a current, and why a Submission holds a sequence of snapshots. Discarding the rejected updates loses the evidence a reviewer most often needs.

Principle 3 is why the tool never decides who owns float. That is a contract-derived input, and a tool that assigns it has answered a legal question with an algorithm.

Source: docs/CONCEPTS.md. Source commit date: 2026-09-06.