In the full taxonomy of schedule anomalies — missing logic, excessive lag, high float, constraint violations — retroactive baseline changes occupy a special category. Every other anomaly could, in principle, result from poor scheduling practice, inadequate training, or resource constraints. Retroactive changes, by definition, cannot. They require a deliberate act: going back to a historical record and changing it after the fact. There is no version of retroactive change that is accidental.
This is why retroactive change detection is the highest-confidence manipulation signal in project controls forensics.
What a Baseline Is
The performance measurement baseline (PMB) is the time-phased plan against which earned value performance is measured. It represents the agreement between the performing organization and the customer about what will be accomplished, when, and at what cost. Once established, the baseline is intended to be stable — changes to it should only occur through a formal change control process, with customer notification, and for documented reasons.
The baseline is not a prediction of what will happen. It is a commitment to what was planned. Variance from the baseline is the data. That variance — the difference between what was planned and what actually occurred — is what EVMS is designed to surface, analyze, and report. A baseline that changes to stay close to actuals defeats the entire purpose.
What Retroactive Change Means
A retroactive change is any modification to baseline data that changes the historical record after the fact — adjusting planned values for prior periods, modifying actual dates that have already passed, or altering the recorded status of completed or in-progress activities.
These changes are not just a compliance problem. They are a forensic problem. When a baseline is retroactively modified, performance metrics calculated from that baseline are recalculated as if the modification was always there. Schedule variance that existed last month may disappear entirely this month — not because performance improved, but because the plan was adjusted to match performance. A program that showed a 15% cost variance in March may show a 3% variance in April if the baseline was quietly adjusted during the replan.
EIA-748, the governing EVMS standard, explicitly prohibits retroactive changes except in three narrow circumstances: error correction, routine accounting adjustments, and customer- or management-directed changes. Each exception requires documentation. The prohibition is in Guideline E26 of the current Rev E standard — carried forward from D30 in Rev D — and it is one of the most consistently enforced compliance requirements in DCMA surveillance.
How Retroactive Changes Appear in the Data
In P6 and MS Project environments, retroactive changes leave specific traces in the schedule file. Actual start and finish dates that differ between exported versions of the same schedule, for the same activity, represent a retroactive date change. Baseline finish dates for activities already in progress that change between reporting periods without a formal baseline change request indicate unauthorized replanning. Relationships that appear or disappear between the data date and prior-period exports indicate retroactive logic modification.
The most reliable detection method is not point-in-time analysis but version comparison. A schedule analyzed in isolation reveals only what it contains. A schedule compared against a prior-period version of itself reveals what changed — and whether those changes occurred to historical periods that should have been locked.
The Three Categories of Retroactive Change
Not all retroactive changes carry the same implications. Understanding the category matters for assessing severity.
Error correction. Legitimate retroactive changes occur when a previously recorded actual date was entered incorrectly and is being corrected to reflect the true history. These are permissible under EVMS guidelines but require documentation. An error correction that consistently moves dates in a favorable direction — consistently showing earlier actual starts or later actual completions than previously reported — is a pattern that deserves scrutiny.
Scope realignment. When a control account is formally replanned following a customer-approved scope change, historical periods within the replan window may be legitimately adjusted. The critical question is whether the change followed a documented, approved change control process.
Unauthorized revision. When baseline data for prior periods is modified without documentation, without approval, and without customer notification, the change is unauthorized. This is the category that constitutes genuine manipulation — adjusting the historical record to produce more favorable variance calculations, to reset eroded float values, or to hide accumulated schedule slippage before a surveillance review.
Why This Is the Highest-Confidence Signal
Every other schedule anomaly — high float, excessive lag, missing logic — exists on a spectrum. There are legitimate reasons for lag values, legitimate scenarios for disconnected activities, legitimate programs that carry high float in certain phases. The threshold judgments that separate anomaly from legitimate practice require context.
Retroactive changes to locked historical data have no such ambiguity. The question is binary: was this data changed after the data date? If yes, was it documented, approved, and customer-notified? If no to either, the change is unauthorized. There is no scheduling practice, no program complexity, no resource constraint that produces unauthorized retroactive changes. They are deliberate.
This is why forensic schedule analysts prioritize retroactive change detection above almost every other check. It is the anomaly where the signal is clearest and the noise is lowest.
The Forensic Intelligence Engine detects retroactive changes by comparing schedule versions across reporting periods and flagging unauthorized modifications to historical baseline data — producing findings that are traceable, evidence-backed, and defensible in contract proceedings.