The standards map — what else exists, and what is worth implementing

Date: 2026-09-02, corrected the same day — §7 records which of its claims were checked against the source documents and which held. Status: evidence record and recommendation. It changes nothing in the tree; where it bears on a claim owned by another file it says so and names the file, and where a manifest or a module docstring contradicts it, that file wins.

~~Eleven authority packs exist today: ufgs, asce67, aace29, scl, aace_review, vdot, gao, aace84, caltrans, paseg and nysdot — 311 rules; the 295 figure at docs/CONFORMANCE.md §1 predates nysdot and that file owns its own count.~~ Superseded 2026-09-05: thirteen packs and 331 rules. navfac (15) and wisdot (5) landed after this was written and make up exactly the 20-rule difference; docs/CONFORMANCE.md owns the count and is bound to forensic.rules by a test, so read it there rather than here. The sentence is kept because the count it names is what the ranking below was written against. Superseded again 2026-09-06: fourteen packs and 351 rules, wvdoh (16) being the difference — see §2.7, which is a candidate this ranking never contained and could not have, because the ranking was drawn from RP 26R-21's reference list and West Virginia is not in it. The last four were built from this document on 2 September 2026 (§6, §7, and the row-7 note in §1). DCMA-14 lives in cpmcore/health.py. The GAO Schedule Assessment Guide was being added by another agent while this was written and is deliberately absent from the ranking below; it has since landed.

This document answers one question: what else exists that a serious buyer would expect, and what is the honest priority order?

0. Read this first: the three constraints that shape every answer

0.1 The AACE licence constrains what can be stored and what can be published

The 125 Recommended Practices in aace/ are single-user licensed; copying and networking prohibited. The accessible-format text and markdown copies were made for personal use under 17 U.S.C. §121 and the DMCA §1201 print-disability exemption. They are not licensed for redistribution.

business/OPERATING-MODEL.md §3.4 states the three operating rules and they are not restated here because restating them would create a second copy to go stale. The consequence for this document is narrow and absolute:

• An AACE-derived rule pack may implement the method (17 U.S.C. §102(b)) and must never carry the expression. aace_review.py is the existing precedent and the pattern to copy.
• No AACE text may go into shipped product output — not into a rule's quoted-clause field, not into a generated report, not into a published page. UFGS is a United States Government work and carries no copyright, so ufgs differs structurally from the AACE packs and a report may quote its text at length.
• Free to obtain is not free to redistribute, and this document conflated the two. Corrected 2026-09-02 after the Caltrans pack read the title page: the 2025 Standard Specifications assert "© Copyright 2025 California Department of Transportation. All rights reserved." while this map's rank-4 row read "Free (public spec)" and §6.3 said a report may quote its text. A state or local agency publication is not a US Government work, and 17 U.S.C. §105 does not reach it. The rows for MDOT SHA §109 and NYSDOT Item 639.2X010011 now say obtainability was checked and redistribution was not, because that is what happened; the same caution applies to VDOT, whose special provision is a Virginia agency document that this map previously put in the same sentence as UFGS. Verify the title page before a pack quotes a state specification's text into product output. This is the same distinction §0.1 states correctly for AACE and stated incorrectly one screen later, which is why it is now a bullet in the constraint section rather than a column.
• Internal analysis is the established exception, and it is narrow. Every file in corpus/analysis/ states the same rule — analysis and characterisation with short anchoring quotes only, never reproduction of substantial text — and this document follows it. Two short phrases from 84R-13 and 92R-17 appear below because the exact wording is load-bearing for the argument about what is checkable. That is the limit; it does not extend to a rule pack's citation strings, which are output.
• Nothing here routes around that. Where the licence makes an otherwise-good candidate expensive, the ranking says so rather than pretending it does not.

One clarification worth having, because it is the difference between a dead end and a corpus. corpus/specifications/README.md already establishes that AACE RP 26R-21's reference list is AACE's, but the fifteen agency specifications it points at are US public-agency publications carrying no AACE licence. The list is licensed; the documents are not. The same logic applies to UFGS §1.1's reference list (§3.2 below).

0.2 "Mechanically checkable" is the crux, and it needs a test, not an opinion

Every candidate below is scored on how much of it a program can decide from a schedule file. The three tests used, in order of strength:

1. Normative-language count. Read the document and count shall / should / must. A document with no shall is not a specification. Applied to PASEG in §2.1 with a result that settles the question. Every such count must name the edition it was taken over, and §2.1 records why: the counts this document originally published came from an edition nobody here has ever held.
2. Enumerated-item and quantified-expression count. The method corpus/specifications/README.md §2 used on fifteen agency specifications. Reused rather than reinvented.
3. Field mapping. Does the requirement name a quantity the importer already parses? TT_LOE is parsed (cpmcore/xer.py:100), so "no LOE on the critical path" is decidable today. "Time risk allowance shown separately" names no P6 field, so it is not.

A count of checkable clauses is not a measure of value. corpus/analysis/FIELD-EVIDENCE.md §3.5 establishes that four independent decompositions of schedule review disagree about the mechanical share by a factor of five, and that none of them measures reviewer time. Nothing below converts a clause count into a share of anyone's day.

0.3 Buyer demand here means a procurement record or a contract clause, not a reputation

corpus/analysis/FIELD-EVIDENCE.md §6 measured federal contract awards directly from the USASpending API: Acumen Fuse 75 awards (Navy 21, NASA 15, DOE 15, DCMA 2), and zero to any highway agency; Primavera P6 169 awards including FHWA 28. Those two numbers are the only hard demand evidence this project has, and they say the defence/space EVM world buys schedule-analysis software and the highway world does not. That asymmetry is carried into the ranking explicitly rather than assumed away.

Where no such record exists for a candidate, the demand column says not established and the candidate is ranked as if it were low, because that is what the evidence supports.

1. The ranked list

How this is ordered, and why there is no score. Each candidate carries three ordinal judgements — buyer demand, mechanical checkability, licence freedom — with the evidence for each stated in §2. The order below is a reading of those three columns, not the product of three invented numbers. Multiplying ordinals nobody measured would produce a figure that looks derived and is not, which is the scd_end_date failure mode CLAUDE.md names: a right-looking answer for no reason. The columns are the argument; the rank is a conclusion drawn from them and can be argued with.

Every figure in the Effort column is [EST] — my judgement against the existing packs' sizes, not a measurement of anything. vdot is 26 rules and corpus/specifications/README.md records it as the "lowest effort" of nineteen documents; the estimates below are scaled off that and off aace_review's 61. Treat them as ordering, not as durations.

Rank 3 is a retrieval task, not a build task, and §6's build order therefore reads 1, 2, 4. ER 1-1-11 is ranked third on the strength of where it is cited — UFGS §1.1 incorporates it by reference — and on nothing at all about its contents, which nobody here has seen. It is placed high so that it is fetched early, not so that it is built early. §2.3 says what may and may not be claimed about it.

2. The evidence, candidate by candidate

2.1 NDIA PASEG — the strongest candidate, and the reason is licence freedom

Edition — this section said v6.0 and it was wrong. Corrected 2026-09-02 against corpus/standards/NDIA-PASEG_PROVENANCE.json, which is the owning record for everything in this paragraph. This section originally read "version 6.0, dated 30 September 2025". On 2026-09-02 that URL served version 4.0, dated 12 September 2019 — read off the title page of bytes whose sha256 the manifest records. Four retrieval attempts for a v6.0 are logged there: the hubspot URL (v4.0), an s44115.pcdn.co v6.0 path (404), an ndia.org v6.0 path (200 with a 212-byte non-PDF body), and the ndia.org division-guides landing page (the same 212-byte stub). A copy of v5.0 (12 September 2022) is held at dcma_research/paseg5.pdf. No v6.0 has ever been in this repository. That is a failure to reach and not a finding of absence — a v6.0 may well exist — but nothing in this document was ever read out of one.

What it is. Planning and Scheduling Excellence Guide, National Defense Industrial Association, Integrated Program Management Division. Thirteen sections plus appendices. The version this project holds and forensic/rules/paseg.py is written against is v4.0, from https://f.hubspotusercontent40.net/hubfs/2535991/NDIA%20IPMD%20Planning%20and%20Schedule%20Excellence%20Guide%20(PASEG).pdf, no login and no paywall. Redistribution is granted on conditions — the copyright notice entire, NDIA IPMD named as author, the original's location given — which is why the committed extraction is the whole document rather than a slice.

Who requires it: nobody found, and the document says so itself. No DFARS provision, DID, or agency policy naming PASEG as required was located. The DFARS EVMS text cites only ANSI/EIA-748. This is not an inference from silence — the full extracted text was searched:

v4.0, re.findall(r"\bWORD\b"), case-sensitive, over the committed 14,983-line extraction: shall 0. should 278 (281 case-insensitively). required 93. must 23 (27).

v5.0, same method: shall 0. should 295. required 90. must 24.

Only the zero survives across editions, and only the zero was ever load-bearing. This section originally published "shall 0, should 304, required 99" over "5,701 lines" and named no edition. The zero reproduces exactly. The other three figures do not, the line count does not, and none of them came from a document this project holds — they were measured over a differently-shaped extraction of an edition never obtained (see the edition note above). The map also never mentioned must, which occurs 23 times in v4.0; all 23 were read when the pack was built and none states a requirement on a schedule that a file could be checked against — they are narrative, definitional (P6's Must Finish On constraint), or about program teams rather than schedules.

A document with no shall in any edition this project has held is advisory by its own construction, and that is the whole basis of the pack. Say "PASEG is guidance, and the strongest reason to implement it is that it is free and the buyers already own the tool category" — never "PASEG is required." Nothing may report non-compliance against PASEG, and forensic/rules/paseg.py enforces that structurally rather than by memory: its rule context has no fail and no ok, so a rule body there cannot construct a PASS or a FAIL. corpus/standards/fetch_paseg.py --counts re-runs the count and exits non-zero if shall is ever non-zero, because that is the event that would invalidate this. Absence of a program-specific SOW naming PASEG was not exhaustively disproven.

What is mechanically checkable. Sections 5 (schedule modelling), 9.1 (statusing), 10.1 (critical/driving path), 10.2 (schedule health) and 10.4 (execution metrics — CPLI, SPI, BEI, CEI, TFCI, SPIt). Roughly a quarter to a third of the document by section count; the remainder — leadership, business rhythm, training, contract-phase considerations — is governance and is not checkable by anything.

Four propositions from the source, stated here in this project's words and cited rather than reproduced — and two of the four attributions below were wrong, which is exactly what a citation checker exists to catch. Corrected against corpus/standards/NDIA-PASEG_PROVENANCE.json and the module docstring of forensic/rules/paseg.py, which hold the sentences themselves for a reader with the repository; PASEG's grant is conditional, so the expression stays in those two files and out of anything published.

§5.12, v5.0: schedule float, being a value the forward and backward passes compute, is not to be treated as schedule margin. v4.0 states the same proposition in materially different words — it reaches float through network logic rather than through the two passes. The difference is recorded because a rule quoting one edition's wording against the other would misattribute; the two sentences are in the provenance JSON and are not reproduced here.

§5.12, v5.0 only: schedule margin tasks are not to be resource loaded. That sentence is not in v4.0 at all; v4.0's Things to Promote list opens instead with a different instruction, about margin tasks being accounted for in resource, staffing and EAC planning. A rule citing v4.0 for the resource-loading sentence would cite something v4.0 does not contain. Nothing in the pack rests on it — there is no resource model in this engine.

§10.1: the critical path is defined as the unbroken sequence of tasks that sets the program end date.

§10.1 — not §10.2, as this document said twice — on a credible critical path: it carries no level-of-effort or summary activities, and no unexplained gaps between tasks, the example given being lags standing in for effort outside the performance measurement baseline. §10.2 is Schedule Health Assessment in both editions held. Verified twice: in v4.0 the characteristics list is followed immediately by the figure captioned as an example of a program critical path, and in v5.0 it sits between the §10.1 and §10.2 headings, on the page the table of contents gives for §10.1. The pack cites §10.1.

That pair is decidable today with no new parsing. cpmcore/xer.py:100 maps TT_LOE to ActivityKind.LEVEL_OF_EFFORT and TT_WBS to WBS_SUMMARY, and longest_path() exists. That check is a filter over an already-computed set.

Two cautions that must travel with the pack.

1. Schedule margin is a modelling convention, not a P6 field. PASEG §5.12 describes margin as a task the scheduler creates. Nothing in an XER identifies one. A margin check therefore needs a terms input naming the activity code or ID pattern — the same HYBRID shape vdot.py already uses — and must report NOT_EVALUATED naming the term when it is absent, never PASS.
2. PASEG's GASP tenets and its execution metrics overlap DCMA-14 substantially. cpmcore/health.py already implements the fourteen with the population and denominator questions worked out. The pack's value is what PASEG has that DCMA-14 does not — margin, LOE-on-critical-path, path gaps — not a second implementation of BEI. Duplicating BEI would produce two numbers that must agree and one place for them to diverge.

A third caution, found by building the pack, and it is somebody else's decision to make. PASEG is reachable only through --contract ndia_paseg, and jurisdiction.py:448 puts any --contract name ahead of the jurisdiction's inferred order, because incorporation by name is a term. So on a federal job --contract ndia_paseg makes PASEG governance.primary — head of "Governing documents", above UFGS — and asce67.py:2050 then renders it as "governing authority: PASEG", of a document with no shall that binds nobody. The other route, elected, is not right either: --review's elected packs govern nothing, and PASEG on a contract that names it is more than that. Neither existing category fits a named-but-non-binding document. That is a forensic/jurisdiction.py decision and this map records it rather than resolving it; docs/CONFORMANCE.md §2 records the reader-facing half — the five rules run, and add nothing to either side of the score.

Price: $0.

2.2 AACE 84R-13 — the cheapest real gap, and the tree already names it

Verified locally, from corpus/standards/UFGS-01-32-01.00-10_Project-Schedule.txt §1.1 REFERENCES. UFGS 01 32 01.00 10 normatively incorporates exactly five documents:

AACE 29R-03 (2011) Forensic Schedule Analysis AACE 52R-06 (2006) Time Impact Analysis — As Applied in Construction AACE 84R-13 (2015) Planning and Accounting for Adverse Weather ASCE 67-17 (2017) Schedule Delay Analysis ER 1-1-11 (2017) Administration — Project Schedules

This list is the single best-evidenced priority order in this document, because it is the specification the product already implements naming what it depends on. 29R-03 and ASCE 67-17 are packs. 52R-06 is implemented as the prospective TIA command (forensic/cli.py:2073). 84R-13 and ER 1-1-11 are the two that are not. No search produced a better-grounded statement of what a UFGS buyer would expect next.

The gap is already written down in the code. forensic/rules/ufgs.py, docstring at :1022, rule UFGS-039 on §3.3.9:

"whether the day counts are reasonable is an AACE 84R-13 judgment nothing here makes."

And the field evidence says reviewers issue exactly that finding. corpus/analysis/FIELD-EVIDENCE.md §3.2 quotes WisDOT SE Region's comment library verbatim:

"The Contractor should revise the current four adverse weather days for the month of April to five as per the project Standard Specification."

That is a state DOT reviewer writing a monthly weather-day arithmetic comment as routine practice, and it is a predicate over a calendar plus a table.

What is checkable and what is not — and the split matters. 84R-13 was read in aace/markdown/84R-13.md. Most of it is method: how to obtain NOAA records, what counts as a weather day, how to treat preparation and recovery days, over what period an average is statistically meaningful. None of that is checkable from a file and none of it should be attempted. What is checkable, given the contract's monthly planned-adverse-weather table as a terms input:

• a weather calendar exists and is assigned (already UFGS-039, partial);
• the calendar's non-work day count per month equals the contract table;
• weather-sensitive activities are identifiable as a population at all — 84R-13 asks that weather-sensitive activities be identifiable in a way that lets them be filtered apart from the rest, which is an activity-coding question and therefore the same blocker FIELD-EVIDENCE.md §3.2 identifies as the boundary between mechanical and judgement.

Small pack. Perhaps eight to twelve rules, most of them HYBRID. Its value is not size: it closes a normative reference of the spec the product's federal story rests on, and it upgrades an existing abstention into a decision.

Price: $0 — held under the existing licence. No text may ship.

2.3 USACE ER 1-1-11 — obtain it before ranking it, and say so

The fifth entry in UFGS §1.1, and the only one this project has never read. corpus/specifications/README.md §1 row 1 records it as [UNVERIFIED] — an Akamai edge 403 on every publications.usace.army.mil path including the site index, "neither confirmed live nor dead." That is still true; this pass reproduced the same class of block on .mil hosts (§5).

What may be claimed: it exists, it is dated 2017, it is titled Administration — Project Schedules, and UFGS 01 32 01.00 10 incorporates it by reference. All four are read off the UFGS text held locally.

What may not be claimed: anything about its content, its checkability, or its effort. corpus/specifications/README.md §2 rank 12 records the guess "marginal — UFGS already mined"; that guess was made without the document and this pass did not improve on it.

The recommendation is therefore a retrieval task, not a build task, and it is cheap. A USACE Engineer Regulation is a US Government work — free, and quotable in a report, unlike everything AACE. If it turns out to be an administrative regulation about who signs what, it drops off this list permanently and that is a useful thing to have settled. If it carries schedule content, it is a free federal document normatively bound into the spec the product already implements, which would put it above everything except PASEG.

2.4 AACE 90R-17 and 92R-17 — the densest unimplemented schedule RPs

The aace_review pack implements 78R-13, 53R-06, 48R-06, 38R-06 and 79R-13 (forensic/jurisdiction.py:92). corpus/analysis/AACE-catalogue-survey.md and the four cluster analyses beside it have already surveyed the rest, and this pass adds one measurement rather than a sixth survey.

Method: for each unimplemented schedule-relevant RP, count lines carrying normative language (should/shall/must) and lines carrying a numeric bound. Measured over aace/markdown/:

The measure is crude and its weakness should be visible: a line with should on it may be advice about a meeting. It is a screen, not a verdict, and every candidate below was then read.

90R-17 wins on reading as well as on the count, and it is the update-side complement to the baseline-side rules already built. Its normative content is predicates over actual dates and remaining durations — an activity 100% complete with no actual finish, an actual date on or after the data date, a started activity whose remaining duration equals or exceeds its original duration, fractional remaining durations in a whole-day-reported project, suspension without a resume date, negative progress. Every one of those is a field comparison, and several are the same findings WisDOT and NYSDOT publish: FIELD-EVIDENCE.md §3.2 lists Future Actual Dates as a WisDOT comment category and §6 records NYSDOT reviewers reading "Activities with Actual Date = DD" off P6's own log by hand.

92R-17 is small but carries actual numbers — the 5% rule, a maximum float equal to 50% of the average reporting period, longest-path values within 5% of remaining duration — and it says explicitly that schedulers "should refrain from accepting the default settings." Near-critical logic already exists in forensic/concurrency.py and forensic/tia.py; this would make the threshold choice a cited one.

93R-17 is a trap and naming it is the useful part. Its title is Schedule Logs, and VDOT SP108-000120-01 rejects submittals on what "the Schedule Log shows". These are two different artefacts with the same name. VDOT's is Primavera P6's own Schedule/Leveling report — a machine output, already the basis of the vdot pack. AACE 93R-17's is a register of schedule submittals maintained by a reviewer across the project, with entries for who submitted what and when. Implementing 93R-17 would produce a document-management feature under a rule pack heading. It is not a file check and it should not be built as one.

2.5 The state DOT question — an existing ranking, plus one document it did not contain

corpus/specifications/README.md §2 ranks nineteen agency documents by enumerated items, quantified expressions, explicit thresholds, tool mandate and estimated machine-checkable clause yield, against the benchmark of UFGS's 103 rules. That work was done properly, with a stated method and its weakness declared ([EST] clause counts filtered by judgement, not a rule-by-rule extraction). Its top three are VDOT (built), MDOT SHA §109 2026 ed., and NYSDOT Item 639.2X010011 Type 2, and nothing found this pass reorders those three relative to each other. That ranking stands and is not re-derived here. Two of the three are now built: NYSDOT landed on 2 September 2026 (§2.6), leaving MDOT SHA §109 as the only unbuilt member of that top three.

What this pass adds is a document that ranking never contained, because the corpus it was drawn from — RP 26R-21's reference list — does not cite it. Its absence was a property of the source list, not a judgement about the document.

First — and this is the substantive new finding of this pass — Caltrans §8-1.02C is the most mechanically-decidable state specification anyone here has read, and it partly rescues a business-plan claim the corpus had left stranded.

business/BUSINESS-PLAN.md §8's P3 names Caltrans, TxDOT, WSDOT and GDOT as the state-DOT pack list, and corpus/specifications/README.md §0 records that none of those four is in the 26R-21 corpus and only Caltrans appears in the InTrans study, as a table row. That contradiction stood because nobody had read the Caltrans specification. It has now been read.

Caltrans 2025 Standard Specifications, §8-1.02C "Level 2 CPM Schedule" (dot.ca.gov/-/media/dot-media/programs/design/documents/2025_stdspecs.pdf; a 2026 edition takes effect 19 October 2026 and was not read). Requirements quoted from the section:

"At least 50 but not more than 500 activities unless authorized."

"At least 1 predecessor and 1 successor to each activity except for activities that begin at the project start milestone and activities that end at the project end milestone."

"Activities durations of at least 1 working day and no more than 20 working days for each activity, unless otherwise authorized."

"A total of not more than 50 percent of the baseline schedule activities must be critical or near critical unless otherwise authorized."

"The schedule software must be the latest version of Primavera P6 for Windows or equal."

Four of those five are predicates over TASK and TASKPRED, and the fourth is a population share of a set the engine already computes. The fifth is not, and that was overstated here. §8-1.02C(3)'s "the latest version of Primavera P6 for Windows or equal" is the section's most quotable line and its least checkable: "latest" is a fact about Oracle's release calendar and not about the file, "or equal" is the Engineer's determination, and an XER declares the tool that wrote it, not that its version was current when the schedule was submitted. A rule pack can report what wrote the file; it cannot decide this clause. That is a recorded limitation, not a task.

The other four are a different and stronger shape than VDOT's, which is a list of rejection triggers read off P6's own log. Caltrans states bands — an activity-count band, a duration band, a criticality share cap — which are exactly the rules a reviewer cannot check by eye on a 500-activity schedule and a program checks in milliseconds. It belongs above MDOT SHA in the ranking and the ranking has been changed to say so.

Two further clauses matter and are treated in §4, because they bear on the arithmetic question rather than on rule count: §8-1.02C(2)(12)/(8)(c) defines Department-owned float as "a resource for the exclusive use of the Department", and §8-1.02C(8)(b)(3) defines a time-impact method.

A number this section said did not exist — and the search was one section too narrow. This paragraph read "no numeric total-float threshold for 'critical' was found in §8-1.02C" and advised abstaining rather than substituting an industry default. The advice was right and the premise was wrong. It is true of §8-1.02C and false of the specification, because the definitions are in §1-1.07B, the Glossary of the same document, which this pass did not read (corpus/standards/Caltrans-2025-StdSpecs_PROVENANCE.json, near_critical_finding):

critical path: "Longest continuous chain of activities for the project that has the least amount of total float of all chains."

near critical path: "Chain of activities with total float exceeding that of the critical path but having not more than 10 working days of total float."

So §8-1.02C(6)'s 50 percent cap is fully decidable with no supplied term and no industry default, and caltrans.py's CT-06a implements exactly that pair. §1-1.07B also carries baseline schedule, milestone, data date and total float, all used by the pack. The generalisable lesson is the cheap one: when a clause states a term and no number, read the specification's own glossary before concluding the number is absent.

This creates a conflict worth naming. AACE 92R-17 offers a 5% rule and a maximum float tied to the reporting period (§2.4). On a monthly-updated job that second rule gives roughly ten working days and the two nearly agree; on a weekly-updated job it gives two or three, and they do not. Where §8-1.02C is incorporated Caltrans governs, because it is a contract term and 92R-17 is a Recommended Practice binding only by adoption. No Conflict is recorded in the tree, because 92R-17 is not implemented and a conflict naming code that does not exist would be an assertion about nothing; caltrans.py's docstring is the notice to whoever builds it.

No retained-logic-versus-progress-override statement was found, and that remains a negative over §8-1.02C only.

One constraint on the fetch-and-pin pattern, measured rather than assumed, and it is general. pdfminer's extraction of the Caltrans PDF is not deterministic: four runs over the same bytes in the same process produced four different whole-document digests at identical length, first diverging at character 1,752,498 inside a multi-column acceptance-criteria table whose cells come out in a different order between runs. So the manifest records full_text_sha256: null with that measurement, pins the PDF bytes, and verifies two stable slices (§8-1.02C and §1-1.07B) that reproduced identically across four and two extractions respectively. A whole-text digest is not a usable provenance anchor for a table-heavy PDF — it would fail on the next run and be read as an agency revision. Pin the bytes, and pin slices the pack actually depends on.

And the licence, which is the correction with consequences. §8-1.02C's rank-4 row read "Free (public spec)" and §6.3 said a report may quote its text. The title page reads "© Copyright 2025 California Department of Transportation. All rights reserved." Free to obtain — fetch_caltrans.py retrieves it unauthenticated on the first attempt — is not free to redistribute. The pack is handled on the corpus/analysis/ terms instead: numbers, clause identifiers and rule titles are facts rather than expression (17 U.S.C. §102(b)) and are used freely; short anchoring quotes appear in docstrings; no extraction is committed and no bulk text reaches product output. Whether California could assert that copyright against a bidder over a specification incorporated into public construction contracts is an open question and is not resolved anywhere in this repository; the conservative position costs the project nothing, because what the pack needs is the numbers.

Second, PennDOT is the standing counter-example and it must not be forgotten when a new state is chosen. corpus/analysis/FIELD-EVIDENCE.md establishes from PennDOT Publication 615 (2026 edition, revised January 2026) that PennDOT's current scheduling manual is an Asta Powerproject manual — "Asta" 50 mentions, "Primavera" 3 (all in §8.23.3 "Primavera File Conversions"), "P6" 0 — and that USASpending returns zero federal contracts naming Asta Powerproject. A state being large is not evidence that its schedules arrive as XER files. Confirm the file format from the agency's own current document before scoping a pack.

2.6 NYSDOT — the effort estimate was wrong, because the agency published its own review instrument

Row 7 above estimated 2–3 weeks and rated checkability "High but NYSDOT-shaped". The pack took a day. The reason is a second NYSDOT document that neither this map nor corpus/specifications/README.md contained:

NYSDOT, "Best Practices for CPM Schedule Specification Compliance", 9 May 2016, 71 pages, www.dot.ny.gov/main/business-center/contractors/construction-division/ construction-repository/Best_Practices_for_CPM_Schedule_Spec_Compliance.pdf, sha256:10b01f6e7bec57cd0f5d85929e26f32223f975e544aa37126c901941aa9b0a74. Provenance: corpus/specifications/NYSDOT-CPM-Best-Practices-2016_PROVENANCE.json.

Its Chapter 2 restates Item 639 paragraph I.1's nine Immediate Rejection criteria in a three-column table — criterion, where to identify the deficiency, how to fix it — and the middle column names, for each, the numbered global P6 filter the reviewer applies. It then lists all twenty-nine filters, 01a through 10, with what each selects. Attachment 2 is those twenty-nine filters and those nine criteria as tick boxes on one page. It is the only document reached in this repository that states what an agency reviewer mechanically does, filter by filter, rather than what a contractor must deliver.

It is not a contract term and says so — page 1: "This manual is considered guidance and not official policy." Item 639 is the contract term. nysdot.py cites both and keeps them apart: three of its sixteen rules rest on the manual alone and none of those three can return a FAIL, which a test enforces.

Licence: it asserts no copyright, in the text or in either metadata channel. Zero occurrences of "copyright", "(c)" or "all rights reserved"; the PDF Info dictionary has no rights key and the 3,505-byte XMP packet has no dc:rights. Both were checked, not assumed. That is a finding and not a permission — §0.1's correction applies with full force, because a New York State agency document is not a US Government work and 17 U.S.C. §105 does not reach it. The position is recorded as unresolved, unresolved is treated as restricted, and the Caltrans precedent is followed exactly: nothing is committed but digests.

What the pack refuses, and why the 29 filters do not become 29 rules. Sixteen rules were written. Three of the nine rejection criteria are facts about the submission rather than the schedule — failure to run F9, failure to attach the Schedule Log, failure to attach the Narrative — and no schedule file records them. Thirteen filters key on P6 activity codes (RESPONSIBLE PARTY, TYPE OF WORK) or on the Global/Project calendar distinction, neither of which cpmcore.network.Task carries; one reads a per-activity Expected Finish the model does not carry; one reads three user-defined production-rate fields; and three are keyword filters whose keywords the manual does not print, of which the manual itself says "The Filters are not 100% perfect." Inventing the keywords would attribute this tool's guess to the agency.

The activity-code gap is the single highest-value thing this finding names. Filters 03a, 03b and 04a–04i are twelve of the twenty-nine, they are refused for one reason, and that reason is one missing field on Task. Item 639 F.1(q)–(r) makes the codes contractual. Whoever adds activity codes to the network model unlocks twelve NYSDOT filters at once, and almost certainly the equivalent responsibility-coded checks in every other state pack.

2.7 WVDOH — the requirement is in the standard specification book, not in a special provision

Built 6 September 2026 — forensic/rules/wvdoh.py, 16 rules over two documents. Provenance, digests and the licence position: corpus/specifications/WVDOH-2023-StdSpecs-108-3_PROVENANCE.json.

What is new about this one is where the requirement lives. VDOT publishes its CPM requirement as a special provision that deletes and replaces a numbered section; NYSDOT as a special specification item; Caltrans as a §8 section keyed to a bid item. West Virginia writes it into §108.3 of the standard specification book every contract incorporates, with no tier, no bid item and no threshold beyond a dollar figure: a schedule is required above a $2,000,000 Contract Bid Amount and on every incentive/disincentive, design-build, alternative-delivery and P3 project. There is no Category I to exclude and no bid item to look for, which makes the applicability question simpler here than in any other state pack.

Density. §108.3.2 states fifteen numbered criteria governing how the schedule is built in Primavera P6, and six of them are properties of the exported file. That is comparable with NYSDOT's paragraph I.1 and denser than Caltrans's §8-1.02C. §108.3.1.4 adds three more: the .XER submission format, a fifteen working day soft ceiling on activity duration, and an activity count bounded on both sides — at least ten per million dollars of Contract, at most three hundred.

One clause here was decidable in this tree and undecided everywhere else. Criterion 5 prohibits global calendars. forensic/rules/vdot.py's module comment records the same prohibition at VDOT II.2.A(7)(a) as "decidable and undecided … nobody has written the rule", with the design worked out and nobody having written it. WVDOH-05a is that rule, scoped as that comment says it must be — to the calendars activities actually use, not to every CALENDAR row, because 40% of the corpus's calendar rows are CA_Rsrc and no TASK row references one. Whoever next works on vdot should lift it.

What was checked and what was not. The 2024 and 2025 Supplemental Specifications were both extracted in full and neither revises §108, so the 2023 text is the operative text; the provenance record states the measurement rather than the conclusion. WVDOH's Construction Manual §105.3.2 directs the Project Engineer/Supervisor to review each schedule against the specification within fourteen calendar days and refers that person to internal "project schedule training documents" — which are not published on the agency's website. Every page reachable from the Specifications and Documents and Publications indexes was walked on 6 September 2026. outreach/TARGET-LIST.md's Tier 2 row describes a Primavera P6 training course for WVDOH reviewers; nothing in this pass corroborates a course, and the corroborated claim is the weaker and sufficient one above. That row's evidence should be narrowed to §105.3.2 before it is quoted to anybody.

The second document is the agency's own reviewer procedure, and it is worth more to a WVDOH conversation than the specification is. WVDOH publishes a 342-page Construction CPM Schedule Review Manual — Primavera P6.7.1 training for its Construction Engineers and Area Engineers, built around two schedule review checklists it publishes in full and then walks item by item. It is served from a ContractAdmin path that no index page on the agency's site links, which is why the first pass over the Specifications and Publications indexes did not find it. Its own opening states its goals as increasing those engineers' effectiveness and reducing the quantity and severity of Contractor claims. That is this product's value proposition written by the agency about itself, and whoever approaches WVDOH should quote it rather than anything we have written.

Six rules come from it. Section E of the Original Detailed CPM Schedule Review Checklist has 25 numbered items: three are already decided under the specification clauses they restate, six are implemented — E.2 actual dates in the original, E.3 open predecessors, E.4 open successors, E.8 Longest Path, E.9 negative float, and the resource-calendar prohibition from the contract-conformance topic — and the pack's own comment block gives the reason for each of the sixteen that are not. Every one of the six returns an OBSERVATION at worst, because the manual is training material and not a term of the contract, and a test reads the module source to hold that ceiling rather than trusting a fixture to trip it. That is nysdot.py's two-document discipline, and this is the second pack to need it.

The manual's own specification numbers are stale and this pack does not repeat them. Measured on three references: its checklist item E.1 cites §108.3.1.4, which is correct today; its Dates section cites §108.6.2.1 for the Preliminary Construction Schedule, which is §108.3.1.2 in the 2023 edition; and its P6-administration heading cites "Sec 640", which in the 2023 book is Field Office and Storage Building. So the ten specification rules cite the 2023 book read directly, and the six manual rules cite checklist item labels, which the manual owns and which cannot go stale against a specification revision.

Its behaviour on the corpus, measured rather than asserted. Over the 62 readable corpus files, the pack answers 739 of 992 rule-file pairs (74.5%) — 352 PASS, 195 FAIL, 192 OBSERVATION — and thirteen of its sixteen rules return a verdict on at least one file. The three that never fire name what would decide them: WVDOH-03 wants the Contract Bid Amount, WVDOH-07 wants a Project Award milestone the corpus does not contain, and WVDOH-E2 wants a submission that designates its baseline. engine/quality/VERDICT-YIELD.md §16 is the run, with a control arm at the same revision without the pack.

3. Not worth doing, and why

This section is the more useful half. Each entry names what would have to change for the verdict to change.

3.1 NEC4 — high demand, but the licence and the field mapping both fail

NEC4 is the most commercially interesting thing on this list and it is still a no, for two independent reasons.

Reason one: the text cannot be obtained or quoted at a sane price. NEC prices the ECC at £1,639.00 (NEC Digital Professional), £902.00 (ePrint), £126.00 (paperbound), £125.00 (eView), read from neccontract.com directly. No verbatim clause text for 31.2, 31.3, 32, 62 or 63 was obtained this pass — every description below is a practitioner-guidance paraphrase, and this document will not launder a paraphrase into a clause. A rule pack whose citations are somebody's blog summary of a licensed contract is exactly the artefact corpus/analysis/FIELD-EVIDENCE.md was written to prevent.

Reason two, and it survives buying the contract: clause 31.2's own list does not map onto P6 fields. On the paraphrased content, the programme must show float and time risk allowances as distinct quantities not absorbed into activity durations. P6 has no time-risk-allowance field. Detecting one requires a project-specific coding convention, which means the check is really "did the contractor follow the coding convention we agreed", not "does the programme comply with 31.2". That is a terms-driven convention check dressed as a standards pack.

Who requires it — asked, and largely not established. Direct fetches of National Highways, Network Rail and HS2 pages produced no statement naming NEC3 or NEC4. That is a failure to reach, not a finding of absence, and it must be reported as such. The Cabinet Office Construction Playbook PDF was fetched and could not be extracted. Hong Kong's government-wide NEC adoption rests on a secondary source only; the Development Bureau circular was not reached. Nothing in the NEC demand story is presently sourced to a policy document this project has read.

What would change the verdict: the founder buying the ECC (£126 is the cheap route) and one named procuring body's policy document obtained and read. Both, not either. Until then NEC4 is a plausible acronym, which is the thing this document was asked not to produce.

3.2 PMI Practice Standard for Scheduling and PMI-SP — no requirer, and one finding that cuts against it

No procurement document requiring either was found, and one strong negative was verified: UFGS 01 32 01.00 10 §1.3 PROJECT SCHEDULER QUALIFICATIONS names no certification at all — it requires three prior P6 schedules of similar size and complexity and "comprehensive knowledge of CPM scheduling principles". PMI is absent from §1.1's reference list (quoted in §2.2 above). State DOT specifications were not searched for a PMI-SP or PSP personnel clause (§5), so this is a federal negative, not a general one.

And the credential does not anchor to the standard. The PMI-SP Exam Content Outline was fetched and read; its own introduction states that the role-delineation participants "were not bound by the Practice Standard for Scheduling and/or PMBOK Guide." Its five domains are Schedule Strategy 14%, Planning and Development 31%, Monitoring and Controlling 35%, Closeout 6%, Stakeholder Communications 14%. Nothing there is a file predicate.

The honest state of the Practice Standard itself is: unknown. Its Section 4 component taxonomy and Section 5 "Conformance Index" are the one part of the PMI corpus that is structurally a checklist, and the body text was never read — a paywall, and $63.95 list / $51.16 member (search snippet, pmi.org returned 403 on every fetch). It is ranked low because no requirer was found, not because it was assessed and rejected. Those are different statements and the difference is worth $64 to close.

3.3 EIA-748 and IPMDAR — the checkable part is DCMA-14, and DCMA-14 is built

DFARS 234.201, read from acquisition.gov directly: an EVMS complying with ANSI/EIA-748 is required at $20,000,000, and a system formally determined compliant by the cognizant agency at $50,000,000. Clause 252.234-7002 names sixteen "high-risk guidelines" by number. That is real, clause-level, and it is the strongest demand evidence for anything in the EVM family.

It is still the wrong thing to build, because EIA-748's 32 guidelines are famously terse management-system requirements, not schedule predicates. corpus/analysis/AACE-catalogue-survey.md §5 reached the same conclusion from the other direction, having read the seven AACE RPs written around EIA-748: "none of the seven RPs name DCMA-14 or its 14 specific checks — this cluster is EIA-748/cost-discipline literature that assumes DCMA-14-style schedule health already exists upstream." The schedule-checkable layer of the EVM world is DCMA-14 and PASEG. DCMA-14 is in cpmcore/health.py; PASEG is item 1 above. Buying EIA-748 buys the layer that is not checkable.

Two unresolved items, recorded so nobody re-derives them. (a) A secondary source reports EIA-748-E published around February 2026, reducing the guidelines from 32 to 27; the SAE and ANSI store pages returned 403 and this was not verified — do not cite "32 guidelines" without checking. (b) A secondary source claims a $100M threshold from a 2015 class deviation, which conflicts with the $20M/$50M figures read from the primary regulatory text. The deviation memo was not reached. Use the acquisition.gov figures; flag the conflict.

IPMDAR is ranked 7 and not dismissed, because it was never reached. DI-MGMT-81861C (30 Aug 2021) is well corroborated by filename convention across independent sources; a reported DI-MGMT-81861D (March 2026) rests on a single unfetchable vendor page. acq.osd.mil failed with a certificate error on every attempt and dcma.mil returned 403 on every path. No primary-source content on IPMDAR's schedule delivery format or its data schema was obtained. IPMDAR requires a native schedule file, which would make it the most product-shaped document in the defence world — or it would not, and this pass cannot say which. Obtain it before ranking it.

One new lead worth chasing, and its provenance is now uncertain. This paragraph was written believing the document read was PASEG v6.0; it was v4.0 or v5.0 (§2.1), so which edition's Appendix B was searched is not established and the lead should be re-checked against a named edition before it is acted on. PASEG's Appendix B reference list names the "DCMA EVMS Standard Surveillance (EVAS) Instruction" — not DCMA-EA PAM 200.1. That suggests NDIA treats PAM 200.1 (29 Oct 2012) as superseded in its citation practice. cpmcore/health.py:49 currently describes PAM 200.1 as "the last formally published DCMA statement of the fourteen", and the caveat in corpus/analysis/FIELD-EVIDENCE.md §3.6 records that it was only ever read from a third-party mirror. The EVAS Instruction was not obtained, its number and date are unknown, and whether it restates the fourteen is unknown. If it does, that docstring and that caveat both need revising — by whoever owns health.py, on evidence, not on this lead.

3.4 ISO 21500 / 21502 / 21508 / 21511 — zero checkable content, verified by reading

ISO 21500:2021 was read in full (second edition, 2021-03, twelve pages of substantive content). Its complete clause list: 1 Scope, 2 Normative references (none), 3 Terms and definitions (19 one-line terms), 4 Project/programme/portfolio management concepts, 5 Standards on PPPM, Bibliography. No numbered requirements, no schedule-model attributes, nothing resembling a checklist. That is not an inference from the title; the clause bodies were read.

ISO 21502:2020 (guidance on project management), 21508:2018 (EVM) and 21511:2018 (WBS) were not obtained — iso.org returned 403 throughout — so their content is genuinely unassessed. Prices of CHF 100 (21500) and CHF 225 (21502) come from search snippets and are unverified.

And there appears to be no ISO standard on scheduling at all, though this is an unverified negative: the ISO/TC 258 work programme page could not be fetched, so what exists is "no such standard found", not "confirmed absent".

The verdict does not depend on the gaps. ISO 21500 is the family's anchor and it contains nothing to check. A pack built on the rest would be a governance questionnaire, and CLAUDE.md already names the failure mode: an invariant that cannot fail is not a check, and a boolean published as an audit is worse than no boolean.

3.5 JCT — the finding is that there is nothing to check, and that is worth writing down

JCT clause 2.9.2 requires the contractor to produce a master programme as soon as possible after the contract is entered into. Because it is produced after execution it is not a contract document and adds no obligation beyond the contract. Corroborated by JCT's own published commentary and by independent solicitor commentary; verbatim clause text was not obtained (paywalled), and the clause number was not confirmed against a JCT 2024 clause list specifically.

A programme that imposes no obligation cannot be checked for compliance with anything. There is no JCT pack to build, and the useful output is saying so plainly rather than producing four rules about submission timing.

This is also the sharpest available contrast for the positioning story. UFGS §3.2.3 ties non-acceptance to a 10% withholding and NAVFAC makes baseline acceptance a condition precedent to invoicing (FIELD-EVIDENCE.md §3.6). JCT's programme binds nobody. The product's value tracks the contractual weight of the programme, and that weight is not uniform across jurisdictions. Whoever owns business/GTM.md should have that sentence.

3.6 CIOB — no evidence anyone uses it

The Complex Projects Contract 2013 was renamed the Time and Cost Management Contract (TCM2015) in November 2015. No named project and no procuring body using it was found, and the one source reached notes contemporaneous reviewers saying it would need testing on a live project before its effectiveness could be judged. That is weak evidence of low uptake, not proof of none.

The CIOB Guide to Good Practice in the Management of Time — the item that actually mattered, because it is reported to carry numeric schedule-density requirements — could not be reached at all; every ciob.org and Wiley URL tried returned 404. Nothing may be claimed about its content, its edition, its price or its checkability. This is the largest single gap in the international half of this pass.

3.7 The AACE cost-estimate-classification series — 27 files, zero schedule content

corpus/analysis/AACE-catalogue-survey.md established that 27 of 64 surveyed RPs are Cost Estimate Classification / Basis of Estimate / Code of Accounts variants — the same five-class estimate-maturity matrix restated industry by industry, with schedule appearing only as a yes/no artefact-existence line. All 27 rate NONE or LOW. Four of AACE's five most recent publications are in this series. There is no schedule product in any of them and no further survey is needed.

3.8 The federal and state documents that were reached and found empty

FAR 52.236-15 does not require CPM, and a bar chart satisfies it. Prescribed at FAR 36.515, the clause (Apr 1984 text, current at acquisition.gov) requires a "practicable schedule… in the form of a progress chart" showing percent complete by date, submitted within five days of starting work. No CPM, no network logic, no float, anywhere in the clause. All of FAR Part 36 was walked and 36.515 is the only scheduling section. GSAR 552.236-15 mirrors the same bar-chart language. DFARS Part 236 and PGI 236 were checked subpart by subpart and contain no scheduling text at all.

This confirms the premise the whole product rests on, from the other direction. Any US federal CPM requirement enters through an agency specification — UFGS, a USACE regulation, a state DOT spec — and never through the acquisition regulation. There is no FAR pack to build, and the reason there is none is the reason the UFGS pack matters.

EFARS was not reached, and the limit of the negative should be stated: EFARS is not codified in the CFR — 48 CFR Chapter 2 Parts 254–299 are reserved — so it is a standalone USACE publication outside acquisition.gov, and no working mirror was found. Its scheduling content, if any, is unknown.

FDOT is a null result and naming it saves a fortnight. The current FY 2026-27 Standard Specifications, §8-3 was fetched and full-text searched: zero occurrences of "Primavera", "CPM" or "Critical Path". §8-3.2 requires only a generic schedule showing activity order, interdependence and durations — no activity-count band, no duration limits, no float rule, no named software. FDOT's base book is materially less checkable than VDOT's or Caltrans's, and a Florida pack built from it would be four rules about submission timing. A separate design-build or complex-project CPM special provision may exist and was not located. This is the same verdict corpus/specifications/README.md reached on AZDOT, reached the same way, on a different state.

USACE ECB 2023-13 was reached in full, and it is thinner than its title promises. Engineering and Construction Bulletin 2023-13, CECW-EC, issued 24 August 2023, replacing ECB 2012-21 — and it states its own expiry as 24 August 2025, so its status as a live requirement is unclear and should not be asserted. Its Enclosure 3 "Proposed Project Schedule Checklist" runs to 20 items, of which three are cleanly decidable from an XER alone — every activity has a predecessor and successor except the start and finish milestones; no start-to-finish relationships; all durations in the same time unit — and one or two more given contract data. The remaining fourteen turn on judgement: whether a duration reflects the most likely case rather than the best case, whether site-specific limitations were considered. The checklist also asks for "a clear critical path" without defining it, so it supplies no arithmetic rule of its own. corpus/analysis/FIELD-EVIDENCE.md §3.6 already quotes three of its items; this pass adds the denominator, and the denominator is the finding — 3 of 20.

One small negative about ER 1-1-11 that qualifies its rank-3 placing. ECB 2023-13's own reference list cites ER 1110-1-1300, EP 715-1-7, ER 5-1-11, the RMS 3.0 Manual and UFC 3-740-05 — and does not cite ER 1-1-11. That is suggestive of disuse and it is not proof of it. It is a reason to retrieve the document before scoping work, not a reason to strike it: UFGS incorporates it by reference, and UFGS is the contract term.

FHWA and FTA, because both were asked about. 23 CFR Part 635 contains no CPM, critical-path or network-analysis language; §635.121 requires only that states hold "adequate written procedures for the determination of contract time" — establishing duration, not method. FHWA does not mandate CPM federally, which is consistent with FIELD-EVIDENCE.md §6: the highway world writes its rules into state specifications, which is why the state packs are the highway strategy and there is no federal shortcut. FTA does impose a real requirement under 49 CFR Part 633 — §633.25(c) makes "a construction schedule for the project" a minimum element of the project management plan, §633.27(c)(2) requires periodic schedule updates, and §633.27(d) treats a cost or schedule variance above 5% as a material change — but no CPM method is mandated, only that a schedule exist and be tracked. An FTA oversight procedure on schedule review is a lead, not a citation: a candidate document was located by URL and every fetch returned 403, so its number, edition and content are unconfirmed and it must not be cited until obtained.

GSA, DOE and NASA — one confirmed negative and two unverified leads. GSA PBS-P100 (Facilities Standards, May 2024) was fetched and full-text searched: zero occurrences of "critical path", "CPM", "Primavera" or "P6". It points instead to PBS P-120 / PBS 1000.6B Cost and Schedule Management Policy, which was located but not read — that, not P-100, is where any GSA CPM mechanics would live. DOE Order 413.3B is reported to require a resource-loaded schedule with an identified critical path and an integrated master schedule built to PASEG and GAO-16-89G standards; the primary text was not verified and this must not be cited. If it holds, it is the only located federal policy naming PASEG, and it would raise PASEG's rank from "free and good" to "free, good and named by a federal order" — worth one retrieval attempt before building item 1. NASA/SP-2010-3403 NASA Schedule Management Handbook exists (NTRS, March 2011); its body was not read.

4. The arithmetic question: is there another precedence rule, or a jurisdiction where the calculation differs?

The brief asks whether any standard would change the engine's arithmetic rather than adding rules — the way UFGS §3.8.4 makes ASCE 67-17 govern over AACE 29R-03 on US federal work, which forensic/jurisdiction.py already encodes.

The short answer: no new one was found, and three plausible candidates were checked and eliminated. The two mechanisms that genuinely move numbers are already in the engine.

Already handled, and confirmed this pass by reading the code:

• Retained logic vs progress override. cpmcore/progress_logic.py:222 is described as "the entire implementation of retained logic versus progress override", and p6xml.py:107 parses the declared mode. This is the largest arithmetic fork in out-of-sequence progress and it is modelled, not assumed.
• Longest path vs the total-float definition of critical. cpmcore/xer.py:1113 reads PROJECT.critical_path_type (CT_DrivPath / CT_TotFloat), and corpus/specifications/README.md records that all 92 PROJECT rows in the oracle corpus write the column — 88 CT_TotFloat, 4 CT_DrivPath.
• Concurrency doctrine by jurisdiction. forensic/concurrency.py takes the jurisdiction as an argument; jurisdiction.py:94 states why — SCL first-in-time versus US effective-cause "is not a nuance, it decides cases."

Candidate 1 — PASEG's critical-path definition. Checked; it does not fork. §10.1 defines the critical path as "the continuous sequence of tasks which determines the program end date", which is the longest-path definition. It describes an "Unconstrained CPM" variant in §10.2 where total float never goes negative, but offers it as an optional technique, not a mandate. PASEG does not require one definition over the other, so it adds no precedence rule.

Candidate 2 — out-of-sequence treatment in the defence world. Checked; a clean negative. The full extracted PASEG text was searched: retained logic and progress override each appear zero times. §9.1.1 addresses out-of-sequence only narratively — fix the logic — and names neither calculation mode. This is a searched negative over a document held in full, not silence about a document nobody read.

Candidate 3 — schedule margin. Checked; it changes the model, not the arithmetic. PASEG §5.12 distinguishes margin from float and asks that margin be modelled as an unresourced task. A CPM engine computes a schedule containing a margin task exactly as it computes any other. The forward and backward pass do not change. What changes is the interpretation of the resulting float, and that is a reporting concern.

Candidate 4 — Caltrans's Department-owned float. Checked, and it is the same answer as candidate 3, which is why the answer is worth stating twice. §8-1.02C(2)(12)/(8)(c) makes Department-owned float "a resource for the exclusive use of the Department" and defines early completion time as a resource for the contractor's exclusive use — two named float-ownership categories in a state specification, which is the closest thing to a float-ownership rule found anywhere this pass. But Caltrans implements it structurally: the Department's float is a dedicated predecessor activity to the completion milestone. A predecessor activity is an ordinary node. The forward and backward passes compute it exactly as they compute anything else; what the clause does is fix whose the resulting float is, which is an entitlement question about a computed number, not a change to how the number is computed.

This is the general shape of every candidate examined, and it is worth naming as a pattern rather than rediscovering it a fifth time: the profession expresses float policy by adding activities, not by changing the pass. PASEG margin, Caltrans Department-owned float, and the buffer conventions behind AACE 70R-12 all work this way. A tool that computes CPM correctly and reports float by ownership class serves all of them; a tool that special-cases the arithmetic serves none.

Candidate 5 — Caltrans's time-impact method. Checked; it is the method the engine already implements. §8-1.02C(8)(b)(3) measures a change's impact as the difference between the scheduled completion dates of two schedules, after inserting the change into the accepted schedule closest in time to the event. That is a prospective fragnet insertion — AACE RP 52R-06's procedure, which is forensic/cli.py's tia command. The shape is built. Whether Caltrans's "closest accepted schedule" selection rule differs from what the command does today is a question for whoever builds the Caltrans pack, and it is a rule about which snapshot to impact, not about the impacting.

The one live possibility, and it is unproven: NEC4's compensation-event assessment. On the paraphrased description of clauses 62 and 63, a compensation event is assessed prospectively — actual Defined Cost before a "dividing date", forecast cost after it, with the assessment fixed at that date and not revised later even if the forecast proves wrong. If that is accurate, it is a genuinely different discipline from the retrospective as-built windows methods in forensic/: it asks what a competent contractor would reasonably have forecast at the time, not what happened.

Three reasons not to act on it yet. (a) No clause text was obtained — the description is entirely practitioner-guidance paraphrase. (b) The engine already has a prospective method — RP 52R-06 time impact analysis, forensic/cli.py:2073 — so the shape may already exist and the question is whether NEC4's dividing-date rule differs from it in a way that changes a number. (c) A method that fixes an assessment at a date and refuses to true it up is a contractual rule about revisiting an answer, which may be a workflow property rather than an arithmetic one. Which of those it is cannot be determined without the clause, and the clause costs £126.

Recommendation on the arithmetic question, stated as a negative because that is what the evidence supports: nothing found this pass justifies touching the kernel. The one candidate that could is behind a paywall and is as likely to be a workflow rule as a calculation. Do not modify the calculation on a paraphrase.

5. What could not be reached

Named individually, because a negative result with no document behind it is the thing that vanishes.

Blocked by host, repeatedly and reproducibly:

• acq.osd.mil — certificate error on every attempt. No IPMDAR content of any kind was obtained: not the DID, not the Implementation and Tailoring Guide, not any schedule data schema.
• dcma.mil — 403 on every path tried. No live official copy of DCMA-EA PAM 200.1 was found, independently reproducing the finding already recorded at corpus/analysis/FIELD-EVIDENCE.md §3.6. The DCMA EVAS Instruction was not obtained; its number, date and content are unknown.
• publications.usace.army.mil — ER 1-1-11 (2017) was not obtained, same Akamai edge behaviour corpus/specifications/README.md §1 recorded. Nothing may be claimed about its content.
• pmi.org — 403 on every route. The Practice Standard for Scheduling body text was never read; its component list and Conformance Index mechanics are unknown. The PMI-SP examination fee was not found.
• iso.org — 403 throughout. ISO 21502, 21508 and 21511 clause lists unread; all ISO prices are unverified snippets; the ISO/TC 258 work programme was not obtained, so "no ISO scheduling standard" is an unverified negative.
• SAE and ANSI webstore — 403. EIA-748's current revision letter, guideline count and price are all unverified.
• transit.dot.gov — 403 (Akamai) on the FTA oversight-procedure PDF. The procedure's number, edition and content are unconfirmed and it must not be cited as a source.

State DOT specifications not reached, and this is the largest gap for the highway strategy specifically. Landing pages 404'd or were unreachable on every URL tried for TxDOT Item 8, NYSDOT §108 (the base specification, distinct from the 2017 P6 guide already held), WSDOT Division 1, MnDOT §1803, GDOT, NCDOT and Ohio DOT §108. Two of those — TxDOT and WSDOT — are named in business/BUSINESS-PLAN.md §8's P3 list, and nothing in this pass establishes whether either has a checkable specification. Caltrans's P3 entry is now evidenced (§2.5); GDOT's, TxDOT's and WSDOT's are not, and the difference must not be smoothed over. corpus/specifications/README.md §2's ranking already covers MnDOT §1803 and a superseded NYSDOT §108-01 from documents held locally, so those two are less exposed than the rest.

Not obtained for other reasons: - GSA PBS P-120 / PBS 1000.6B Cost and Schedule Management Policy — located by URL, not read. This is where GSA's CPM mechanics would be, if it has any. - DOE Order 413.3B primary text and DOE Guide 413.3-24 — not verified. The reported PASEG and GAO-16-89G reference is a search-result synthesis and is the single most valuable unclosed lead in this document (§3.8). - NASA/SP-2010-3403 body content; NPR 7120.5 current revision letter. - USACE EFARS scheduling text, and any USACE RMS or quality-assurance scheduling directive. - Caltrans 2026 Standard Specifications (effective 19 October 2026) — the 2025 edition was read; whether §8-1.02C changed is unknown, and a pack must be built against the edition the contract names.

• NEC4 clause text for 31.2, 31.3, 32, 62 and 63 — licensed, £126 minimum. Everything said about NEC4 in this document is paraphrase.
• JCT verbatim clause 2.9.2, and confirmation that the number is unchanged in the JCT 2024 suite specifically.
• CIOB Guide to Good Practice in the Management of Time — all URLs 404. Edition, price, structure and checkability all unknown. This is the largest unclosed gap in the international assessment.
• Cabinet Office Construction Playbook — PDF fetched, text extraction failed. Whether it names NEC by clause is unknown.
• National Highways, Network Rail, HS2 NEC policy statements — pages fetched, no relevant content found. Failure to reach, not evidence of absence.
• Hong Kong Development Bureau NEC circular; NZTA/Waka Kotahi; South Africa — not reached.
• Society of Construction Law Australia — the organisation's own site was not located. AS 4000-1997 and AS 2124 clause text — paywalled, not obtained. Infrastructure Australia, Transport for NSW, Queensland TMR — not reached.
• CCDC 2 (2020) — the schedule clause number was not confirmed from a fetched source. No Canadian delay protocol, Infrastructure Ontario or Metrolinx specification was obtained. Nothing may be claimed about Canada or Australia from this pass.
• State DOT specifications were not searched for a PMI-SP or AACE PSP personnel qualification clause. The UFGS negative in §3.2 is federal only.
• UN/CEFACT and NIEM schedule-exchange standards — not searched. IFC 4.3 IfcWorkSchedule/IfcTask exists and is open, but no document requiring it for CPM schedule interchange was found.

A method note that affects every gap above. The web-search budget for this session was exhausted (200/200) partway through, and most of the international and federal-specification work was done by direct URL fetch, which has a much higher failure rate. Several "could not verify" entries above would likely close in a fresh session for a fraction of the effort. They are recorded as gaps rather than as findings precisely because that distinction is the point of this section.

6. The recommendation, with prices

Build next, in this order — all three were built on 2 September 2026. The packs are paseg (5 rules), aace84 (8) and caltrans (11), counted at docs/CONFORMANCE.md §1. What each pack does and does not implement is in its module docstring, which supersedes the scoping in this section. §7 records what building them proved about the claims below.

1. NDIA PASEG — v4.0, not the v6.0 this item named (§2.1). Free, and the buyers in this population are the ones with a documented history of paying for schedule analysis software. Build the parts DCMA-14 does not cover — schedule margin (HYBRID, needs a terms input), LOE and summary activities on the critical path (DETERMINISTIC today, TT_LOE is parsed), unexplained gaps on the path — and do not reimplement BEI or SPI, which cpmcore/health.py already computes. Cost: $0.

2. AACE 84R-13. Closes a normative reference of the specification the federal story rests on, upgrades an abstention already written into ufgs.py:1022 into a decision, and matches a comment category a state DOT reviewer writes routinely. Small pack, mostly HYBRID on a contract weather table. Cost: $0 — held under the existing single-user licence. No AACE text may ship.

3. Caltrans §8-1.02C (2025 Standard Specifications, checked against the 2026 edition before building). The most mechanically-decidable state specification read by anyone on this project: banded activity count, banded durations, a mandatory predecessor-and-successor rule, a 50% critical-or-near-critical cap, P6 mandated by name, and a float-ownership mechanism. This item said it is "a free public document whose text a report may quote". It is not — the 2025 edition asserts copyright (§0.1, §2.5), and the pack therefore commits no extraction and ships no bulk text. It evidences the one entry in business/BUSINESS-PLAN.md §8's P3 list that this pass could substantiate. Cost: $0.

And one retrieval task that costs an hour and could reorder all three. USACE ER 1-1-11 (2017) is the fifth entry in UFGS §1.1 and the only one never read — a US Government work, free, and quotable in a report as no AACE material is. It sits at rank 3 in §1 on the strength of where it is cited, not on anything known about its content, and §3.8 records a small counter-signal (ECB 2023-13 does not cite it). Retrieve it before scoping anything; if it proves administrative, strike it from this list permanently. The same applies, more weakly, to DOE Order 413.3B: if it genuinely names PASEG, item 1 gains a federal requirer and its rank stops resting on procurement records alone.

Recommended purchases — the founder's decision, not a transaction anyone should execute:

Total to close every cheap unknown in this document: about £126 + $64. Every other gap in §5 is a retrieval problem, not a purchase.

7. What was checked against the sources, and what held

This document is research, and on 2 September 2026 three rule packs were built from it — paseg, aace84 and caltrans. The agents that built them read the source documents rather than this page, and checked seven of its claims against them. Two held and five did not. The corrections are above, each beside the claim it replaces; this section exists so a reader knows the checking happened and how it came out, because a document that drove three packs and was wrong about a licence, an edition, a section number and a threshold is more trustworthy with the record than without it.

The owning records are corpus/standards/Caltrans-2025-StdSpecs_PROVENANCE.json, corpus/standards/NDIA-PASEG_PROVENANCE.json, and the module docstrings of engine/src/forensic/rules/caltrans.py and paseg.py. Where they and this page disagree, they win — they were written with the document open.

The pattern in the five, and it is worth more than the tally. Four of them are the same mistake: a fact about a document — its licence, its edition, its section numbering, the edition a sentence belongs to — asserted from a reading whose provenance was never pinned. None of the four was a mistake about scheduling. The one that was, number 6, was wrong in the cautious direction and cost the project only a narrower search than it should have run.

What that argues for is not less research; it is provenance beside every claim about a document. Every corrected figure above now names its edition, its extraction and its counting method, because a modal-verb count without all three is a right digit over the wrong population — which is CLAUDE.md's standing objection to deriving the number and letting the sentence rot, arriving here from the other direction. And one measurement came out of the checking that constrains this repository's fetch-and-pin pattern generally: pdfminer's extraction of a table-heavy PDF is not deterministic, so a whole-text digest cannot anchor one (§2.5).

Nothing here is legal advice. AACE material referenced in this document is single-user licensed; the accessible-format copies in aace/ were made for personal use under 17 U.S.C. §121 and are not for redistribution. This document characterises methods, which 17 U.S.C. §102(b) does not protect, and contains short anchoring quotes only — never reproduction of substantial text — on the same terms as every file in corpus/analysis/.

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