The Order Is the Plan
Nobody sets priorities. They set an order. Priority labels drift the moment everything becomes important -- a queue cannot, there is exactly one first. And once the queue exists, which markets get served, and when, stops being a separate argument: it is read off the order.
Order, date and deployment are three different questions with three different owners. Order is one integer, no ties, authored on the strategy, independent of when it can land. Date is membership conferred by a release -- a thing can be planned third and land first, a signal, not an error. Deployment is what infrastructure a deliverable needs and which loose ends must close before it does, carried by the deliverable itself, and it is the leg most companies never write down, which is why their dates drift invisibly until the drift is large. A date carried by nothing is an aspiration; a date bounded by named infrastructure and open items is a commitment somebody can be held to.
A deliverable carries scope -- what it may touch -- outputs each with a test, authority to approve and, separately, to undo, hours, its own loose ends which must close before it does, and a seal proving nothing shifted. It can exit two ways: reverted, meaning it landed and was rolled back, or superseded, meaning something better replaced it before it ran -- different failures that teach different lessons. Status is read, never typed: progress derives from the work itself, because a plan that carries its own status becomes a second source of truth, and two sources disagree the moment one of them is edited. Dates are negotiable while a release is being bundled and stop being negotiable the moment it locks -- after that, the dates are immutable, the set is frozen, and tracking runs against a fixed target before the work has even started. There is no boolean beside the date: a boolean and a date can disagree with each other, and when they do, one of them is wrong. Every date change is logged -- field, old value, new value, who, when -- append-only, surviving the lock, because most organisations keep the date they landed on and lose every date they abandoned, and that is why they can never audit how their own estimates behave.
Two things cannot both be third. The constraint, not the tooling, is what people negotiate over -- and it is the correct thing to be negotiating over.
A strategy names the cells it serves. The order of the deliverables serving them is what decides which gets there first, and by how much. Nothing has to be kept in sync, because there is only one thing to read.
None of this requires new software. It requires one integer per deliverable, a date that lives somewhere else, and a record of the argument between them. Everything after that is reading rather than reporting.