Program master schedules

A program master is a real project that also holds mirrors of other projects. The mirrors are read-only by construction — every write path in the product refuses them — so the master can never become a second, quietly diverging copy of someone else's plan.

Attaching a member

Attaching creates an anchor summary task and mirrors the member's current structure and actuals beneath it. Deliberately not mirrored: baselines, scenarios, history, resources. Those stay the member's business.

Both plans must agree on their default calendar — otherwise a working day means two different things and every rolled-up date is a lie. A mismatch is refused at attach time with an explanation, and once attached the calendar is locked on both sides.

Linking across projects

On the master you add what only the program manager can see: dependencies between one member's milestone and another's task, and program-only tasks that belong to no member. These enter the master's critical path calculation like any other link. You link leaves and milestones — an anchor or a mirrored summary is not a valid endpoint.

Publishing, not leaking

Member edits do not flow upward as they happen. The member publishes, deliberately, and what travels is the net difference: change a date and change it back and nothing publishes at all. Until then, work in progress is invisible to every master. Preview before you publish shows exactly what will be sent.

The gate

Each arriving change is evaluated against the master:

• No impact on the critical-path set or the finish date — it applies automatically, with an indicator and an audit entry. It never enters your undo history; it wasn't your edit.
• Impact — it queues for your decision, with a preview computed as a real scenario overlay. What you accept is byte-for-byte what you were shown.
• Blocked — the change would break something structural on the master, such as deleting a task you cross-linked, or closing a dependency cycle. It waits rather than crashing the master, and becomes decidable again once you remove the conflicting link.

A batch containing both kinds splits: the harmless parts apply while the impacting parts queue. Changes that depend on each other are held and decided together — accepting a link whose task you rejected is refused, naming what else you would need to accept.

Edit the master after a preview was computed and the preview goes stale; it must be recomputed before the decision counts. "Accept temporarily" stages the pending changes into a real master scenario, so you can live with them for an afternoon — discard and the master is untouched, promote and that constitutes acceptance.

Rejection, drift, and the way back

Rejecting leaves the master unchanged and the difference visible as drift against the plan of record. A persistent alert lands on the member's own task, naming the master that refused it and visible to every editor on that project — it does not clear until the member reverts and re-publishes, or supersedes the change with a new edit, which is judged afresh.

Two things that are never up for review

• Actuals. A task that started on Tuesday started on Tuesday. Actuals always apply, even when they move the critical path — you get an acknowledgeable alert, not a veto.
• Duration uncertainty. Estimate changes sync to the mirrors, so a Monte Carlo run on the master uses the same distributions the member is using.

Scale

A project can belong to several masters at once, with independent verdicts — one may accept what another rejects. Masters can themselves be attached to larger masters; acceptance into a mid-tier master does not reach the one above it until that mid-tier explicitly publishes. Membership cycles, however indirect, are refused. Detaching removes the cross-links and freezes the mirrors; deleting a member cleans every master the same way and preserves the review history.