What would let these clauses be decided

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.

The importer could not read all of the supplied material as written. 5 blocking, and 81% of the 27 clauses that could be decided passed -- which is 24% of the 113 that apply. 63 of the clauses that could not run name a single missing input each. Those are counts of what this engine could decide, not a determination that the schedule conforms; the reservation below and Conformance findings qualify every one of them.

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: every conformance finding, the concurrency doctrine applied

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.

What would let these clauses be decided

computed_unvalidated

68 clauses of the 113 that apply could not be decided, and between them they name 43 distinct inputs. The other 45 were decided, stated as observations rather than scored, or referred to a person. The largest single thing you can do is supply asce.delay_events, which is the only input 12 of them are waiting on. 36 inputs of the 43 listed below would settle a clause outright, reaching 63 clauses between them — decidable, not passing. The five largest reach 31 of those 63 between them. 6 inputs are worth more than one clause and reach 33; the remaining 30 are worth one clause each. The other 7 are each named alongside a further input, so supplying one of those on its own does not reach its clause. 0 are this engine's own limit rather than anything you can send, and 0 record a reason in prose this tool cannot key on.

Under the first heading, each count is a count of clauses that would become decidable if you supplied that input. A clause that can be decided can fail. Under the other headings nothing you supply changes the count, and the wording says so. Nothing here re-runs a rule or changes a verdict; it is the same abstentions the findings above carry, keyed on what they said they were missing rather than on which clause said it.

One limit, on its own face: a rule can only name the input it got far enough to know it wanted. Supplying what it named may reveal a second. These are the counts the recorded abstentions support, not a promise about the next run.

Supply this, and the clause can be decided (43 inputs, 74 clause mentions)

• asce.delay_events — 12 clauses become decidable.
  • A further 1 names it alongside other inputs, so supplying this alone does not reach them.
  • For example ASCE-67-17-4.5, ASCE-67-17-4.7, ASCE-67-17-7.1, ASCE-67-17-7.2, ASCE-67-17-7.4, ASCE-67-17-8.1, and 6 more.
• scl.delay_events — 10 clauses become decidable.
  • The rules ask for it as: terms['scl.delay_events'] -- the delay events in issue
  • For example SCL-CP10-10.10, SCL-CP10-10.11, SCL-CP10-10.12, SCL-CP10-10.3, SCL-CP12, SCL-CP14, and 4 more.
• asce.rectifications — 4 clauses become decidable.
  • For example ASCE-67-17-10.1, ASCE-67-17-10.2, ASCE-67-17-10.3, ASCE-67-17-10.5.
• asce.acceleration — 3 clauses become decidable.
  • For example ASCE-67-17-11.1, ASCE-67-17-11.2, ASCE-67-17-11.3.
• scl.acceleration — 2 clauses become decidable.
  • The rules ask for it as: terms['scl.acceleration'] -- acceleration episodes, with whether the extension dispute was referred to resolution; an empty sequence means none
  • The rules ask for it as: terms['scl.acceleration'] -- acceleration episodes, with the date the basis of payment was agreed; an empty sequence means none
  • For example SCL-CP16-16.1, SCL-CP16-16.5.
• scl.eot_awards — 2 clauses become decidable.
  • The rules ask for it as: terms['scl.eot_awards'] -- extensions awarded, with the resulting contract completion date; an empty sequence means none
  • The rules ask for it as: terms['scl.eot_awards'] -- extensions awarded, in the order made; an empty sequence means none
  • For example SCL-CP2, SCL-CP7.
• asce.contract_completion_date — no clause is one input away from this. 2 clauses name it alongside a further input, so supplying it alone does not reach them.
  • For example ASCE-67-17-4.3, ASCE-67-17-6.2.
• asce.current_adjusted_completion_date — no clause is one input away from this. 2 clauses name it alongside a further input, so supplying it alone does not reach them.
  • For example ASCE-67-17-4.3, ASCE-67-17-4.6.
• asce.scheduled_completion_date — no clause is one input away from this. 2 clauses name it alongside a further input, so supplying it alone does not reach them.
  • For example ASCE-67-17-4.6, ASCE-67-17-6.2.
• aace.analysis_interval_days — no clause is one input away from this. 1 clause names it alongside a further input, so supplying it alone does not reach them.
  • The rules ask for it as: terms['aace.analysis_interval_days'] -- an interval of one day would settle it without the declaration
  • For example AACE-29R-03-4.2.D.1.
• aace.concurrency_theory — no clause is one input away from this. 1 clause names it alongside a further input, so supplying it alone does not reach them.
  • The rules ask for it as: terms['aace.concurrency_theory'] -- 'literal' or 'functional'
  • For example AACE-29R-03-4.2.D.1.
• asce.remedy_granting_clause — no clause is one input away from this. 1 clause names it alongside a further input, so supplying it alone does not reach them.
  • For example ASCE-67-17-9.3.
• asce.time_extension_claimed — no clause is one input away from this. 1 clause names it alongside a further input, so supplying it alone does not reach them.
  • For example ASCE-67-17-6.2.
• The remaining 30 inputs are worth exactly one clause each — one clause becomes decidable for each name below. By kind:
  • analyst declaration — 17 inputs:
    • aace.asbuilt_source_dates (AACE-29R-03-2.2.B.3), aace.contract_specified_method (AACE-29R-03-5.1), aace.corrections (AACE-29R-03-2.3.D.3), aace.float_source (AACE-29R-03-1.5.B.4), aace.pacing_claims (AACE-29R-03-4.2.G), aace.project_float_ownership (AACE-29R-03-4.3.E)
    • aace.quantification_basis (AACE-29R-03-2.4.A), aace.reconstructed_snapshots (AACE-29R-03-2.3.D.1), aace.rectifications (AACE-29R-03-2.1.B.9), aace.schedules_considered (AACE-29R-03-1.5.B.7), aace.subnetwork_conclusions (AACE-29R-03-1.5.B.5), asce.damaged_milestones (ASCE-67-17-5.4)
    • asce.delay_measure_basis (ASCE-67-17-4.4), asce.early_completion_plan (ASCE-67-17-6.1), asce.float_ownership (ASCE-67-17-5.2), asce.method (ASCE-67-17-4.1), asce.schedules_considered (ASCE-67-17-10.4)
  • contract term — 13 inputs:
    • scl.accepted_programme (SCL-CP1-1.55), scl.assessment_date (SCL-CP9), scl.claims (SCL-CP17), scl.disruption_analysis (SCL-CP18), scl.early_completion (SCL-CP13), scl.eot_applications (SCL-CP4-4.1)
    • scl.float_entitlement_rule (SCL-CP8-8.1), scl.method (SCL-CP11-11.8), scl.method_selection_criteria (SCL-CP11-11.3), scl.pacing_claims (SCL-CP15), scl.prolongation (SCL-CP20), scl.records_held (SCL-CP1-B)
    • scl.variations (SCL-CP19)