Platform
The Plan of Record
The organizational instrument panel. Durable, auditable, and queryable to its rationale.
Without a baseline, you cannot measure deviation.
When there is no durable Plan of Record holding the why behind a decision, all change looks exactly the same.
A brilliant, necessary pivot based on confirmed market data — the right call made for the right reasons — feels exactly the same to an execution team as a toxic executive whim driven by manufactured urgency. Because there is no verifiable baseline, both look like the plan changed again.
The Plan of Record is the instrument panel that makes the difference between those two scenarios visible, nameable, and accountable.
What the Plan of Record holds
The Plan of Record is not a document. It is a durable, API-addressable record of four things:
1. What was decided
The Published Priority List — the only authoritative priority output. Not the session results (informational). Not the catchball loop report (advisory). The Published Priority List, ratified by the Cycle Owner and released as the commitment.
The Published Priority List is immutable. Once published, it does not change — subsequent cycles produce new lists. The organization’s priority history is a sequence of published lists, each of which is queryable in full at any point in the future.
2. How it was decided
The complete decision provenance — every step of the Frame and the Cascade that produced the published list:
| Layer | What is recorded |
|---|---|
| Participation | Who held which role in this cycle |
| Criteria | Which criteria were selected and finalized for each session |
| Values | Which attribute values were accepted and by whom |
| Session results | Tool outputs, rankings, facilitator overrides |
| Catchball | Every exchange, acceptance, and rejection in every loop |
| Governance events | Every major lifecycle action (cycle phase transitions, session publications) |
| Audit events | Every per-item event (shaped, valued, added to pool, ranked) |
3. Why this, and not that
Decision records — the typed, manually- and automatically-recorded decisions that document the choice and its rationale. Decision classes:
force_ranking— a strict total ordering was produced (session published, priority list approved)selection— a bounded set was chosen from candidates (criteria finalized, item pool curated)convergence— uncertain or disputed values were resolved (Catchball proposal accepted)range_selection— ranges, bands, or thresholds were set (scale definitions)review— structured comparison without total ordering (review sessions)
Every auto-generated decision record carries: title, body, decision class, impact, source event, linked objects (items, sessions, cycles), actor, and timestamp. It is immutable. It cannot be retroactively altered.
4. What changed and why
When a priority changes after a Published Priority List exists, the signal must be named.
Was this a signal-informed adjustment? Which signal? What confirmed it?
Was this a restraint pending data? What are we waiting for?
Was this a course correction because prior assumptions were confirmed as wrong? Which assumptions, confirmed how?
This discipline — naming the signal explicitly — ends the era of silent, unaccountable drift. It gives execution teams a way to know whether the change they are being asked to absorb is legitimate. It gives executives a way to demonstrate the rigor of their judgment in real time, rather than asserting it after the fact.
The instrument panel in practice
Consider what becomes possible when the Plan of Record exists:
When a VP returns from a competitor briefing with a new priority: The organization can ask — does this represent a real signal? Is it consistent with the criteria we locked? Has it been evaluated through the authority lane? If the answers are yes, the change is legitimate and the execution team can absorb it with clarity. If the answers are no, the change is visible as a deviation from a documented commitment — and the organization has a mechanism for naming that.
When an auditor asks why Initiative A was funded over Initiative B: The answer is not “because the VP wanted it.” The answer is: here are the criteria, here are the values, here are the session results, here is the Catchball exchange, here is the governance event that authorized it. The entire provenance is queryable via API.
When key people leave the organization: The institutional memory does not leave with them. Every decision they made in Priorities.ai — every rationale they recorded, every override they justified — is on the record. Their successors can read the history and understand not just what was decided but why.
The Planning extension
The Plan of Record extends into the Planning domain — the layer that converts declared priorities into constraint-mediated execution models.
A Plan of Record authorization (POR) locks a specific Plan Version as the organizational commitment. It references a specific Published Priority List, a specific set of constraints (capacity, budget, timeline), and a specific set of authorized commitments.
When execution reality diverges from the Plan of Record — when the sequence in which work is actually executed differs from the priority order — this divergence is detected, recorded, and explained. It does not silently happen. It is named.
This is Rank-Sequence Divergence: a first-class system concept that transforms the conversation from “why is the plan changing?” to “here is the specific divergence and here is its explanation.”
Developer access
The Plan of Record primitives are exposed through:
GET /v1/reports/sessions/:id— session report with full result provenanceGET /v1/reports/cycles/:id— cycle report with all tracks and session statesGET /v1/decisions— decision log (manual and auto-recorded)
Note (Coming soon):
GET /v1/governance-eventsandGET /v1/audit-eventsare planned. The underlying data is captured and stored today — the public API endpoints are on the roadmap.Webhook events
session.published,cycle.transition, andpriority_list.approvedare available today for real-time integration.