Plan-versus-actual records for planning agents

What a usable plan-versus-actual record contains

A usable record holds four linked layers: the baseline, the revision history, the actuals, and the change rationale. A final schedule exported once looks complete but has already overwritten the plan it started from, so it can teach neither estimation error nor replanning.

• Baseline plan. Work breakdown structure (WBS), tasks, durations, dependencies, owners and baseline start and finish dates. Microsoft Project keeps baseline dates in separate baseline fields beside the current schedule, and schedules move between tools as MPP, MPX or XER files that each need their own parser [1].
• Revisions. Each re-baseline or schedule update as its own dated snapshot, with tasks added, split, merged, removed or re-sequenced.
• Actuals. Actual start, actual finish, actual effort, percent complete and status at each reporting date. Primavera P6 XER exports carry activity, WBS and date fields in documented tables [3].
• Reasons for change. Change requests, risk-register entries, status-report narrative or meeting decisions that explain why the plan moved.

The fourth layer is the one most often missing. Without it you have variance but no cause, which is fine for duration estimation and weak for replanning. For records that capture why a business decision was made more broadly, see decision records with rationale.

Where plan, revision and actual data live in source systems

Most plan-versus-actual data lives in scheduling tools, work-management tools and change-control logs, and the export path decides whether history survives. Ask suppliers which system was the system of record for each layer before you discuss volume.

Treat the issue changelog or activity audit table as the primary source for revisions, and the plan file as a convenience snapshot. For multi-system linkage, the cross-system workflow records guide covers joining task IDs across ERP, CRM and ITSM.

Change requests as replanning triggers

Change requests are the cleanest replanning labels because they mark the moment a plan was known to be wrong and record what was done about it. A well-formed change request names the trigger (scope addition, dependency slip, resource loss, defect, client decision), the assessed impact on dates and cost, the approval outcome and the tasks it modified.

For training, each approved change request becomes a supervised example: the plan state before, the trigger, and the revised plan after. Rejected change requests are equally useful as negative examples of replans the organization chose not to make; approval and rejection records covers that label type. SourceX's owner page on project change management describes what these records typically show.

Watch for undocumented replans. Many teams slide dates in a status meeting without raising a change request, so the snapshot diff shows a revision with no trigger. Ask suppliers what share of date changes have a linked change request, and label the rest as "unexplained revision" rather than inventing a cause.

Task granularity and normalization

Task granularity varies widely between teams, so normalize it before you mix sources or compare decompositions. One construction schedule may carry thousands of activities at day-level resolution; a professional-services engagement plan may hold forty milestones; a software team may track two-hour subtasks in Jira.

Practical normalization steps:

• Record the WBS depth and median task duration per project, and keep them as features rather than flattening them away.
• Map task types to a shared taxonomy (design, build, review, approval, wait, handoff) so decomposition quality can be compared across domains.
• Separate work durations from waits. Approval queues and client turnaround dominate many slips; the long-horizon task records page covers measuring horizon length, waits and handoffs.
• Screen schedule quality. The DCMA 14-point assessment, used widely in project controls, flags problems such as missing logic, leads, lags and high float [7]. A plan that fails those checks is weak ground truth for dependency reasoning.

Using the records to train and evaluate decomposition and replanning

Real plan-versus-actual records complement synthetic planning benchmarks by supplying outcomes no simulator knows: what the work actually took and how people recovered. Synthetic planning benchmarks test constraint satisfaction, and the few public schedule files, such as a construction schedule data set on Mendeley Data [4], tend to be single snapshots without full revision history or change reasons. Neither tells you how a 14-week implementation plan really degraded.

Useful task formulations:

1. Decomposition. Input: goal, scope statement and constraints. Target: the baseline WBS. Score structural overlap, dependency correctness and coverage of tasks that appeared later as unplanned additions.
2. Estimation. Input: baseline task. Target: actual duration and effort. Score calibration, not only mean error.
3. Replanning. Input: plan snapshot at time t plus the trigger. Target: the next approved revision. Score whether the agent preserved committed milestones and touched the right downstream tasks.
4. Slip forecasting. Input: snapshot at t. Target: final variance at completion.

The main failure mode is hindsight leakage. Every model input must be an as-of snapshot built only from fields that existed at time t; a "% complete" or task name edited later will leak the outcome. Human-calibrated task suites such as HCAST [5] and time-horizon measures calibrated against human task durations, as in METR's work [6], are a useful way to stratify evaluation sets by how long the work took people. How you define success for each trajectory is covered in task success labels for agent trajectories.

Illustrative record schema for plan, revision and actual layers

A delivery should let you rebuild every plan snapshot and join each revision to its trigger. The schema below shows the minimum structure to request; Parquet is a reasonable delivery format because its footer metadata records column-chunk locations, which keeps wide snapshot tables efficient to scan [9].

Illustrative example: invented to show structure; it does not describe an available dataset.

project:
  project_id: P-0412            # pseudonymous
  domain: commercial_fit_out
  source_system: primavera_p6
  wbs_max_depth: 4
plan_snapshots:
  - snapshot_id: S0
    as_of: 2025-03-03
    type: baseline
  - snapshot_id: S3
    as_of: 2025-05-12
    type: revision
    trigger_ref: CR-017
tasks:
  - task_id: T-118
    snapshot_id: S3
    wbs_path: 2.3.1
    name: "Install ceiling grid, level 2"
    planned_start: 2025-05-19
    planned_finish: 2025-05-30
    predecessors: [{task_id: T-112, type: FS, lag_days: 0}]
    owner_role: subcontractor_ceilings
actuals:
  - task_id: T-118
    actual_start: 2025-05-27
    actual_finish: 2025-06-09
    pct_complete_history: [{as_of: 2025-06-02, pct: 40}]
change_requests:
  - cr_id: CR-017
    raised: 2025-05-08
    trigger_class: dependency_slip
    description_redacted: "Mechanical rough-in delayed by equipment delivery"
    decision: approved
    tasks_modified: [T-112, T-118, T-121]

Acceptance checklist before you sign off a sample:

• Baseline snapshot present and dated before the first actual start.
• At least one revision snapshot per reporting period, not just final state.
• Change requests carry task IDs that resolve against the snapshots.
• Actual dates exist for completed tasks, with null rather than planned dates for unfinished ones.
• Dependency type and lag preserved (FS, SS, FF, SF), not flattened to a task list.
• Free-text fields (descriptions, status narrative) reviewed for names and client identifiers.

Confidentiality, rights and personal data in project plans

Project plans routinely contain client names, contract values, staff names and site addresses, so rights and redaction need as much attention as schema. Professional-services plans are the hardest case: an accounting firm's engagement plan may be confidential client information, and the AICPA rule generally bars members in public practice from disclosing it without the client's specific consent [8]. Similar duties appear in legal, consulting and engineering contracts.

Ask suppliers to confirm who owns each plan (the supplier, its client, or both), whether client consent or contract terms restrict reuse, and how owner and resource names are pseudonymized while keeping role consistency across snapshots. On SourceX, every dataset is rights-reviewed for ownership and consents and delivered under a license that defines records, allowed uses, term and delivery. Names, emails, phone numbers and account numbers are removed or replaced before delivery, the method is recorded and a sample is checked, though no method is perfect.

How SourceX sources plan-versus-actual records

SourceX sources operational datasets from US companies on request and manages the commercial process, including licensing and ongoing purchases. Nothing is held in stock, and a request does not guarantee a match. You describe the data you need, for example "baseline and revision snapshots with linked change requests from commercial construction or IT implementation projects", and SourceX looks for US businesses that hold it. Every release is approved by the supplying company. For the broader capability and adjacent data, see training data for agentic workflow planning, project plans and status reports, the agent data hub and the process mining event logs guide. When your spec is ready, submit a buyer request.

The process runs Find, Assess (data and licensing permissions), Agree (pricing and allowed uses in a license), Transact and Manage, and nothing is contracted until a supplier agrees. Diligence materials covering source, rights, preparation and allowed use are prepared per dataset, and delivery runs through private, access-controlled workflows after an executed agreement and supplier approval.

Request plan-versus-actual data for your planning agent

If your team needs baseline plans, revisions, actuals and change reasons to train or evaluate decomposition and replanning, describe the record layers, domains and source systems you need. SourceX serves AI teams wherever they are based, and its own dataset rights, including any training use, are set out in the signed supplier agreement. Describe your plan and execution data needs.