Run the next three weeks
without breaking the programme.
Short-interval planning usually means a second copy of the programme in a spreadsheet, and then an argument about which one is right. XO Planner reads the programme and cannot edit it. It holds readiness, constraints, the lookahead and the weekly plan, and writes progress back through a channel where every attempt is recorded and failures are retried.
One owner for the programme
The reason short-interval planning drifts is that the planning tool and the programme both think they are authoritative.
It cannot edit the programme
The Gantt is read-only and structural change deep-links back to XO Prog. There is no second copy of the programme to drift, because XO Planner never holds one.
Every write is a recorded attempt
Progress goes back through an execution client and each attempt is persisted. A background job re-drives the ones that failed, so a lost writeback is visible rather than silent.
The assistant proposes, a person applies
Assistant output is stored as a recommendation and changes nothing until someone with the right permission applies it.
What an additive layer changes
XO Prog stays the single owner of programme structure. XO Planner reads it and never edits it.
Every attempt to write progress back to the programme is recorded, and failures are retried rather than lost.
Constraints are objects with a lifecycle, not a free-text status somebody has to interpret.
Readiness, constraints, and a clean boundary
Deliberately additive. Nothing moves out of XO Prog, and nothing here becomes a second programme.
A writeback channel that admits when it fails
Most integrations tell you a write succeeded and go quiet when it does not. This one persists the attempt either way.
- Every attempt persistedEach writeback attempt is stored as a record rather than a log line that scrolls away
- Failures retried in the backgroundA scheduled job re-drives failed attempts instead of leaving them for someone to notice
- Progress only, never structureWrites back percent complete, actual start and finish, and execution state
Constraints with a lifecycle, not a status field
A blocker written as free text becomes a note nobody can count. A constraint with defined actions can be raised, chased and cleared.
- Six defined actionsRaise, resolve, escalate, waive, close and cancel
- Planner tasks are their own thingA planner task is distinct from a programme activity, by name and by permission
- Readiness is computedReadiness is calculated from the current picture and can be recomputed rather than being set by hand
The assistant proposes into a record
Assistant output does not act. It is stored as a recommendation, and applying it is a separate, permissioned step by a person.
- Stored as a recommendationThe proposal is a record, so what was suggested stays visible after the decision
- Apply is the acceptance stepNothing changes until someone applies it, and that requires its own permission
- Assistant access is separately grantableWhether a person can use the assistant at all is its own permission
Where XO Planner sits
In the project management bundle, alongside XO Time, XO RFI, XO Chain, XO Playbook, XO Meet, XO Threads, XO Analytics and XO Intelligence.
XO Prog
Owns the programme: structure, work breakdown, resources and baselines. Planner reads it and hands back progress.
Constraints across the platform
The thing stopping work is usually an approval, a document or a competency record held somewhere else.
Manager rollups
Rollups for managers refresh on a schedule rather than being assembled on request.
Frequently asked questions
Can XO Planner change the programme?
No. It reads the programme and cannot edit it. Progress goes back as percent complete, actual start and finish and execution state; anything structural deep-links into XO Prog, which stays the owner.
What happens if a progress writeback fails?
The attempt is recorded and a background job retries it. A failed write is visible rather than silently lost, which is the point of routing progress through a recorded channel.
Is a planner task the same as a programme activity?
No, and they are deliberately not interchangeable. A planner task is a separate object with its own permission.
Does the assistant change anything on its own?
No. It produces a recommendation that is stored as a record, and a person with the right permission applies it. Note that assistant access is not company-scoped for staff accounts.
Can we report on every constraint outcome?
Not today. Raise, resolve and escalate emit events; waive, close and cancel have no event schema, so reporting should not assume them.
Does planner activity reach the platform audit record?
No. We make no claim of an auditable or exportable platform trail of planner activity: its events stop at the outbox and none reach the ledger.
Plan the work that can actually happen
See how readiness, constraints and the programme fit together without a second copy.