Planning Model, Ownership, and Boundaries

[!CAUTION] EPS is Preview. Never substitute a pending proposal or planning estimate for applied EMS, Finance, AMS, or attendee-facing truth.

One event, two stages

flowchart LR
  P["EPS: proposed scope, work, evidence, approvals"] -->|"link once by events.id"| E["EMS: canonical event and operational configuration"]
  P -->|"direct command or approved proposal"| E
  E -->|"same records, read live"| P
  E -->|"applied configuration only"| R["Rego and attendee pages"]

A plan can begin without an event. Linking assigns one canonical events.id. EPS then reads EMS configuration directly and writes through the same command boundary. An EMS edit appears in Planning on the next load because both read the same record. No import, copy, or background synchronization is involved.

Source-of-truth map

Resource	Source of truth	What EPS may add
Event dates, status, rego tiers, inclusions, add-ons, tier/inclusion links, shop config/categories/listings	EMS canonical tables	Owners, requirements, evidence, risks, approvals, proposal state, and deep links
Tasks, milestones, dependencies, calendars, requirements, submissions, meetings, agendas, minutes, risks, gates	EPS planning tables	The authoritative planning record
Attendee registration and public availability	EMS/Rego applied state	No pending proposal may appear
Posted money, settlements, accounting	Partner Finance/EMS finance records	Estimates, requests, approvals, and links only
Asset identity, custody, stock, transit, audits	AMS	Demand estimates and linked requirements only
Managed content	CMS/Sanity	Opaque asset references and protected proxy endpoints
Uploaded bytes	Sanity media bucket	Metadata, checksum, classification, scan state, retention, and access history in Postgres

Accountability

Projects contain departments and effective access. Tasks distinguish the accountable owner from responsible contributors. Requirements may target a department or individual and may name a reviewer. A planning administrator can edit the plan; a canonical command additionally requires EMS edit capability. Change-set approval and application are recorded separately.

Use RACI language consistently:

• Accountable: owns the result and accepts escalation.
• Responsible: performs the work.
• Consulted: contributes before the decision.
• Informed: receives the outcome.

Lifecycle

concept → active → readiness → handed_off is the normal path. paused, cancelled, and archived preserve history. A handoff is not just a status change: open exceptions, accepted risks, final evidence, canonical configuration versions, and approvers must be visible.

Stop and escalate

Stop if the project is linked to the wrong event, the canonical record changed during review, an attendee-facing effect is unclear, required evidence is quarantined, or the approver is also the unreviewed submitter where segregation is required.

Completion check

Every field has exactly one owner, every Planning-to-EMS change has an audit origin, and operators can explain why an unapplied proposal cannot reach Rego.