Source validation

Project

GENERATED-CLAIM-DEMO

Date prepared

2026-09-10

Engine

0.3.0

Input digest

sha256:f0fa6e8fc1fcd10460f591b01ca97b126cb84d37dccd2d841d3d81cbf5edd161

Date prepared is a self-asserted local time, read from the clock of the machine that ran this analysis and checked against nothing. It records when this document was produced. It is not evidence that this document, or the files it describes, predate any dispute; only an external timestamp authority is, and this engine wires none up.

Reservation of determination

Whether this submission is acceptable is the determination of the reviewing authority. This report states what the schedule imported from the supplied material contains and what the cited clauses say. It is not an engineering opinion and does not certify, approve or reject anything.

Method

No method has been declared for this analysis. Under AACE RP 29R-03 the method is itself an argument to be made and defended, so this report cannot be presented as a delay analysis until one is stated.

Governing documents

No governing document was established for this project. The analysis proceeds under AACE RP 29R-03, which is an assumption of this report and not a fact about the contract. If another document governs, conclusions resting on the choices disclosed below may change.

1. AACE RP 29R-03
2. ANSI/ASCE/CI 67-17
3. SCL Delay and Disruption Protocol, 2nd ed.

Where the governing documents disagree

which standard governs the analysis on US federal work

• Followed, per ANSI/ASCE/CI 67-17: UFGS 01 32 01.00 10 §3.8.4 provides that where a methodology is chosen from AACE 29R-03 and conflicts with ANSI/ASCE/CI 67-17, ASCE 67-17 governs, on work adopting the section. The clause is conditional on such a methodology having been chosen and is scoped to retrospective analysis; it states no ordering between the UFGS section and ASCE 67-17
• AACE RP 29R-03 instead holds: AACE 29R-03 is the more widely cited taxonomy and is frequently applied by default, including on federal work where it does not govern

concurrent delay: which of two overlapping delays is the cause

• Followed, per SCL Delay and Disruption Protocol, 2nd ed.: the SCL Protocol treats true concurrency narrowly and applies a first-in-time approach, requiring the two delays to be effective at the same time rather than merely overlapping in occurrence
• AACE RP 29R-03 instead holds: AACE 29R-03 presents both the literal and functional theories of concurrency without endorsing one, leaving the choice to be argued

Choices that could have gone the other way

The following choices were made and their effect on this schedule was not measured. Establishing that would mean rescheduling the file under each alternative, which is a separate exercise. They are listed so a reader knows the choice was made, not so a reader can assume it did not matter.

• Out-of-sequence progress: retained_logic — read from the schedule as computed, not from the covering letter
  • Source: UFGS 01 32 01.00 10 §3.3.17
• Lag calendar: predecessor — Primavera's default is the predecessor's calendar unless SCHEDOPTIONS says otherwise
• Data date convention: through — AACE RP 10S-90 records this as unresolved; the two readings differ by one day on every window boundary
  • Source: AACE RP 10S-90

Assumptions

AACE RP 29R-03 governs this analysis

• Why assumed: no jurisdiction was stated, so the tool applied its default order
• Resolved by: --jurisdiction, or the contract clause naming the governing document
• Affects: which protocols apply

Limitations

• Historical day-mode benchmark: agreement with stored P6 values was 67.85% of measured field comparisons — Across 82 projects in the harvested P6 corpus, 396,735 of 584,687 computed dates and floats match the values P6 itself stored — 67.85%. One corpus file carries 134,414 of those comparisons — 23% of the corpus — so the per-project table in engine/oracle/corpus/SWEEP-2.md is the honest presentation. This is the September 2026 day-mode baseline, not a measurement of later minute-mode revisions or of this report's inputs
  • Over the 66 projects whose stored dates reconcile against their own declared calendars the figure is 78.06%; that row is not quoted as the headline because excluding 16 projects holding 239,295 comparisons, 40.9% of the corpus, is how a harness flatters itself.
  • No single cause dominates what is left: the three largest classes of disagreement — sub-day arithmetic, total float, and mid-day instants beyond one working day — are close enough to each other that their order is not a ranking, and engine/oracle/corpus/APPORTIONMENT.md states the counts.
  • This figure rose from 61.89% in five steps, four of them on 2026-09-02 and one on 2026-09-04. The causes differ in kind, so a reader should not take them for one number improving five times; each is stated separately below.
  • First, to 67.50%, on two stored fields the importer was not reading.
  • Second, to 67.54%, on a secondary constraint imported and modelled but read nowhere.
  • Third, to 67.71%, on a change of definition rather than of arithmetic: the longest path is now published as the driving set P6 flags rather than as a single chain, which a chain could only ever under-report.
  • Fourth, to 67.80%, on a constraint stamp read with a start rule where the constraint needed a finish rule. One project fell by one comparison across that step, because two of its rows moved onto P6's own stored answer, and the fall was kept rather than reversed.
  • Fifth, to 67.85%, on the first of the five that is arithmetic: a start-to-finish lag was advanced in start space and read back as a finish boundary, which costs a working day whenever the day before the advanced instant is not worked. Two projects moved on that step and both rose; the corpus carries 106 start-to-finish links in 215,543 relationships, which is why it is worth six hundredths of a point and not more.
  • Agreement with MPXJ, an independent importer, fell over the first of those steps from 99.60% to 99.43%, on 1,408 midnight actual finishes where MPXJ keeps the raw stamp. That arm measures agreement with another importer's convention rather than with P6's stored dates, and it is stated beside the rise rather than after it.
  • The scheduling logic is internally consistent, deterministic and property-checked, which is not the same thing as agreeing with the source software. Figures here should be reconciled against P6 before they are relied on.
  • Removed by: closing the causes attributed in engine/oracle/corpus/SWEEP-2.md and engine/oracle/corpus/APPORTIONMENT.md, and re-measuring
• Activities are named by the Activity ID the file carries, which identifies them in this file and is not guaranteed to identify them in the next one — Every finding names an activity by TASK.task_code -- the Activity ID P6 displays and its filters match -- so a finding can be acted on in P6 without a lookup. Across the 87 projects and 89,596 activities measured in engine/oracle/corpus/IDENTITY.md that value is unique within every project and blank on none. It is the contractor's string, however, and this tool cannot tell from one file whether a code named the same work in the previous submission: a citation by Activity ID is a citation against the file this report was computed from, identified by the input digest above. Where an activity carries no Activity ID the line reads 'task_id N', which is P6's internal key -- shown in no P6 column and reissued whenever a project is copied forward
  • Removed by: citing a finding together with this report's input digest, and re-running against each submission rather than carrying an identifier between them
• Where this report's dates are most likely to differ from Primavera P6's, counted on these schedules — The agreement figure above is an average over a corpus of other people's projects. The entries below are the properties of these files that the corpus work identified as where that disagreement sits, each stated as a count on this schedule and a separate finding about the corpus, with the document that owns the finding named. Every count below runs over all 4 schedules together, so an activity or relationship carried by each of them is counted 4 times. The bases are activity and relationship readings across the series, not the distinct activities and relationships the Schedules considered section states for each file
  • 40 of 72 (55.6%) activities, counted as these files state them, carry a duration that is not a whole number of working days on their own calendar. That is where P6's mid-day instant is made: P6 can finish such an activity part-way through a working day, and cpmcore.timeaxis.Instant indexes whole working days and cannot represent one. On these activities, and on activities behind them, expect a late finish to read up to one working day earlier than P6's. engine/oracle/corpus/FRACDUR.md owns that population and engine/oracle/corpus/MIDDAY-EXPOSURE.md section 4 the measurement: standardising on this one property explains 58% of the disagreement difference between the corpus's worst and best projects.
  • Early starts are the part this does not reach. engine/oracle/corpus/OUT-OF-CONE.md section 3 measured early_start_date disagreeing at 29.79% in the corpus projects most exposed to mid-day stamps against 30.13% in the least, a difference of minus 0.05 points and the only field of seven where the exposed projects did no worse. The same table has late_end_date at 70.75% against 22.68%. So it is the backward pass that is pointed at mid-day instants, not the forward one.
  • This is a convention difference this project has documented and refused to compensate for, not a defect awaiting repair. engine/oracle/corpus/MIDDAY-EXPOSURE.md section 6 states it: P6 stamps an instant inside a working day, this engine's time axis indexes whole working days, and that is not a defect on either side. The sub-day axis that would remove it was refused in SUBDAY-AXIS.md, re-priced and re-refused in SUBDAY-DECISION.md, and refused again in BACKWARD-ONE-DAY.md, because a compensating one-day offset on the backward pass would be tuning to an agreement number.
  • Stored dates in these files that fall inside a working day rather than on one of its boundaries, counted field by field against each activity's own calendar: actual start 0 of 29 (0.0%), actual finish 20 of 25 (80.0%). A stamp counts as mid-day when the clock the file wrote against it is not one of the clocks that activity's calendar begins or ends a working block at. Stamps the file wrote with no clock, and activities whose calendar states no shift, are outside every denominator above rather than counted as boundaries.
  • That is the point at which P6 places a date this engine's time axis cannot: cpmcore.timeaxis.Instant indexes whole working days, so a finish at half past four in the afternoon is read as the day. In validation the late finish was the field this landed on -- engine/oracle/corpus/MIDDAY-EXPOSURE.md measured late_end_date stamped mid-day on 59.4% of cells in the corpus projects that fail its validity gate against 26.0% in those that pass, while early_start_date, carried as the control field, barely moved. So a high share on the late finish above is where to expect this report's late dates to read up to one working day earlier than P6's. It is not an error rate for these files, and the closing paragraph says why none is offered.
  • 25 of 72 (34.7%) activities, counted as these files state them, carry an actual finish. P6 states early dates and a total float on a completed row under two conventions this engine does not adopt, which engine/oracle/corpus/BACKWARD.md section 5 names DATA_DATE_AS_EARLY and LATE_DATES_ON_COMPLETE. In validation, completed rows disagreed at about eighty percent on both sides of the corpus validity gate -- 78.23% among the projects that pass it -- so this is not a property of unusual files. engine/oracle/corpus/UNEXPOSED.md section 3 prices the two conventions at 3.848 agreement points.
  • 40 of 80 (50.0%) relationships in the scheduled network join two activities on different calendars. engine/oracle/corpus/OUT-OF-CONE.md section 4 found the corpus projects that agree worst carry nearly three times the cross-calendar link share of those that agree best, 17.2% against 6.2%, and states plainly that the association could not be separated from project size or from progress on 82 projects and is not claimed to be causal. The calendar's declared day length was excluded as the mechanism. So this count is somewhere to look, and is offered as nothing more.
  • This report does not score this file, and none of the counts above is an accuracy rate for it. They are where disagreement concentrated across 82 validation projects, which is a statement about a population and not about this schedule. engine/oracle/corpus/MIDDAY-EXPOSURE.md section 5 publishes the two projects that break any monotone reading of it rather than trimming them: one project is 94.2% exposed to mid-day stamps and 37.6% of its compared cells disagree, and another is 24.7% exposed and 99.8% wrong. Exposure is neither necessary nor sufficient at the project level.

Findings

Each finding below names a clause of a cited document and states what could be established about it: that the condition the clause states is met, that it is not met, that a condition is stated but not scored, that the evidence is assembled and a person must decide, or that an input the clause turns on was not supplied. Whether the submission is acceptable is the determination of the reviewing authority, in the terms reserved above; a finding that a stated condition is not met is not a determination that the submission is rejected.

The weakest step in the reasoning below is computed_unvalidated. No conclusion drawn from it is stronger than that.

Schedules considered

computed

• GENERATED-CLAIM-DEMO — data date 2026-03-02, 18 activities, 20 relationships, from claim-01-baseline.xer (sha256 4da135cdd041…) (baseline)
• GENERATED-CLAIM-DEMO — data date 2026-04-06, 18 activities, 20 relationships, from claim-02-update.xer (sha256 454caeefbee3…)
• GENERATED-CLAIM-DEMO — data date 2026-05-04, 18 activities, 20 relationships, from claim-03-update.xer (sha256 35447da9d59e…)
• GENERATED-CLAIM-DEMO — data date 2026-06-01, 18 activities, 20 relationships, from claim-04-update.xer (sha256 21b829930b12…)

Every file supplied was read, including any the chosen method does not consume (AACE RP 29R-03 §1.5.B principle 7). Not all of it was read exactly as written. The counts above describe what was imported, which is what every finding in this report is computed over. What the importer could not take literally, and what it did instead:

• GENERATED-CLAIM-DEMO — XER.SCHEDOPTIONS.UNKNOWN_FLOAT_METHOD (warning): unrecognised total-float method 'float_type_finish' — used start float; the source setting was preserved
• GENERATED-CLAIM-DEMO — XER.CALENDAR.PART_DAY (warning): calendar C2: weekday(s) [5] work less than a full 8h day — counted as whole working days; work on them is overstated
• GENERATED-CLAIM-DEMO — XER.SCHEDOPTIONS.UNKNOWN_FLOAT_METHOD (warning): unrecognised total-float method 'float_type_finish' — used start float; the source setting was preserved
• GENERATED-CLAIM-DEMO — XER.CALENDAR.PART_DAY (warning): calendar C2: weekday(s) [5] work less than a full 8h day — counted as whole working days; work on them is overstated
• GENERATED-CLAIM-DEMO — XER.SCHEDOPTIONS.UNKNOWN_FLOAT_METHOD (warning): unrecognised total-float method 'float_type_finish' — used start float; the source setting was preserved
• GENERATED-CLAIM-DEMO — XER.CALENDAR.PART_DAY (warning): calendar C2: weekday(s) [5] work less than a full 8h day — counted as whole working days; work on them is overstated
• GENERATED-CLAIM-DEMO — XER.SCHEDOPTIONS.UNKNOWN_FLOAT_METHOD (warning): unrecognised total-float method 'float_type_finish' — used start float; the source setting was preserved
• GENERATED-CLAIM-DEMO — XER.CALENDAR.PART_DAY (warning): calendar C2: weekday(s) [5] work less than a full 8h day — counted as whole working days; work on them is overstated

Source validation

computed_unvalidated

9 passed, 2 failed of 21 source validation checks. This is not scored, and deliberately: one failure can make every number computed from the schedule unusable, so a rate would average away the finding that matters.

Failures (2)

• SVP-2.1.B.3-PROGRESS AACE RP 29R-03 §2.1.B.3 (critical) — 1 of the 18 activities read carry actual dates or percent complete
  • MOBILISE
• SVP-2.1.B.5 AACE RP 29R-03 §2.1.B.5 (major) — 1 of the 18 activities read have an open end
  • MOBILISE: no predecessor

Observations — worth a look, not a breach (3)

• SVP-2.3.B-PATH:GENERATED-CLAIM-DEMO AACE RP 29R-03 §2.3.B — GENERATED-CLAIM-DEMO at data date 2026-04-06 reroutes the longest path from the update at data date 2026-03-02: 2 activities dropped, 0 picked up, first difference at position 0
• SVP-2.3.B-PATH:GENERATED-CLAIM-DEMO AACE RP 29R-03 §2.3.B — GENERATED-CLAIM-DEMO at data date 2026-05-04 reroutes the longest path from the update at data date 2026-04-06: 3 activities dropped, 0 picked up, first difference at position 0
• SVP-2.3.B-PATH:GENERATED-CLAIM-DEMO AACE RP 29R-03 §2.3.B — GENERATED-CLAIM-DEMO at data date 2026-06-01 reroutes the longest path from the update at data date 2026-05-04: 3 activities dropped, 0 picked up, first difference at position 0

Referred — the evidence is assembled and a person must decide (3)

• SVP-2.1.B.2 AACE RP 29R-03 §2.1.B.2 — 18 activities and 20 relationships to assess. Is the level of detail adequate for the delays being evaluated? Too coarse hides the delay inside a summary activity; too fine is not an error.
  • baseline GENERATED-CLAIM-DEMO, data date 2026-03-02, 18 activities
• SVP-2.1.B.7 AACE RP 29R-03 §2.1.B.7 — terms['contract_milestones'] supplied; the assessment against it is a person's. Do any scheduled milestone dates violate the contract, and is each investigated and documented?
  • baseline GENERATED-CLAIM-DEMO, data date 2026-03-02, 18 activities
• SVP-2.1.B.10 AACE RP 29R-03 §2.1.B.10 — 18 activities and 20 relationships to assess. Did the calendars in the file represent the working days the project expected at the time the baseline was prepared?
  • baseline GENERATED-CLAIM-DEMO, data date 2026-03-02, 18 activities

Not evaluated — one input away from deciding (4)

Run unanswered on the same file to read this list by input rather than by clause. It groups these entries by the thing a person would go and supply, and counts the clauses each one would make decidable — decidable, not passed, because a clause that runs can still fail.

• SVP-2.1.B.1 AACE RP 29R-03 §2.1.B.1 — needs terms['baseline_submittal_log']
• SVP-2.1.B.6 AACE RP 29R-03 §2.1.B.6 — needs terms['contract_scope']
• SVP-2.1.B.8 AACE RP 29R-03 §2.1.B.8 — needs terms['contract_terms']
• SVP-2.1.B.9 AACE RP 29R-03 §2.1.B.9 — needs terms['rectification_log']