Data architecture

The database the platform reads & writes

The platform owns its data. It is a Supabase/Postgres database with every application table in the em schema (~80 tables plus their read views), provisioned by the migrations in supabase/migrations/. Skills and the web app never touch a base table: they read through security_invoker views (the *_board / *_current views) and write through security definer RPCs gated by em_private.accessible_write. What follows is the map by domain - the base tables and the main views over them. A handful of things stay external by design; see the last card.

Tasks, plans & autonomy state

The EM's task hub, the daily plan, and the platform's autonomy scratch space.

Table / viewKindWhat it holds
em.taskstableThe task hub - written idempotently by many skills on a source_key
em.task_board / my_task_boardviewActive tasks, quadrant + delay computed; the EM's own slice
em.task_aging / task_backlogviewAging sweep + backlog for the nightly hygiene pass
em.daily_planstableOne plan per EM per day (body_md + sections jsonb)
em.daily_plan_today / daily_plan_logviewToday's plan and the running plan history
em.decision_memorytableDurable decisions the routines remember across runs
em.capture_queue / tracked_itemstableMeeting-capture gaps and observed blockers

Risk

PRINCE2-structured risks with 5×5 scoring and a review cadence.

Table / viewKindWhat it holds
em.riskstableCause/Event/Effect body, probability×impact, lifecycle status
em.risk_boardviewOpen risks with score, band and cadence computed
em.risk_reviews / risk_commentstableThe review log and comment threads

People, 1:1s & feedback

Teammates, satisfaction records, written feedback, wins and growth.

Table / viewKindWhat it holds
em.peopletableTeammates and stakeholders (subtype model)
em.person_profile / teammate_directoryviewThe person read model with recent 1:1s + trend
em.one_on_one_sessionstableScored 1:1 records (deterministic 0-10 satisfaction)
em.one_on_one_notestableOwner-only narrative notes (RLS by owner)
em.one_on_one_wellbeingtablePrivate well-being context, never fed to the score
em.feedback_log_entriestableSBI feedback; read via em.feedback_board / feedback_due
em.wins / growth_pathstableRecorded wins and growth plans
em.coaching_evaluations / coaching_goalstableThe EM's own 1:1-craft coaching program
em.performance_reviews / pulse_surveystableReview drafts and pulse/eNPS runs

Accounts, engagements & conversations

The client side - accounts, engagements, stakeholders, and the audit trail.

Table / viewKindWhat it holds
em.accounts / engagementstableAccounts and their engagements
em.engagement_health / account_healthviewPer-engagement and per-account health read models
em.stakeholder_profilestableClient-side stakeholder profiles + sentiment
em.conversation_log_entriestableClient conversation log; read via em.conversation_board
em.account_comm_plans / account_comm_touchpointstableThe relationship communication plan
em.account_changelog_entriestableAudit rows; em.account_changelog is the view over it

OKRs (mirror of Tability)

Tability stays the system of record; the platform mirrors the quarter for in-product visibility.

Table / viewKindWhat it holds
em.objectivestableObjectives, mirrored from Tability on a source_key
em.key_resultstableKRs with the measurable-target gate enforced
em.objective_board / key_result_boardviewThe /okrs read model

Signals, proposals & routines

The autonomy backbone - what the morning stages and the closer applies.

Table / viewKindWhat it holds
em.signalstablePersisted hygiene / risk / composite signals (signal_board)
em.proposalstableStaged judgment items; read via proposal_board / proposal_ledger
em.proposal_trusttableThe per-action trust ladder (auto / suggest / off)
em.carry_forwardstableDirected follow-ups staged for the next day
em.routine_runstableA row per routine run (routine_run_log)
em.meeting_load_snapshotstableThe EM's own weekly meeting-load reads

Team ceremonies & onboarding

Standups, retros, kickoffs, postmortems and the 30-60-90.

Table / viewKindWhat it holds
em.standup_logs / standup_entriestableDaily standups; read via em.standup_board
em.retro_logs / ceremony_logstableRetros and generic ceremony records
em.project_kickoffs / incident_postmortemstableKickoffs and blameless postmortems
em.onboarding_plans / onboarding_milestonestable30-60-90 plans and their milestones
em.onboarding_checkpointstableDay-30/60/90 (+ vendor Fit) checkpoints

BigMac, reports & platform

The sprint-audit grid, report records, and the identity / settings layer.

Table / viewKindWhat it holds
em.bigmac_runs / bigmac_run_resultstableSprint-audit runs and per-capability results
em.bigmac_capabilities / bigmac_criteriatableThe Big Mac framework definition
em.report_recordstableOne idempotent row per generated report (report_board)
em.em_userstableThe EMs; timezone drives em.em_clock
em.em_settings / em_settings_currenttable/viewPer-EM settings resolved by the app + routines
em.em_account_assignmentstableWhich EM is assigned to which account (the scope spine)

What stays external

Three things are deliberately not modelled in the em schema.

SystemWhat lives thereWhy
NotionThe EM Library (canonical templates / frameworks / FAQs) and its Gaps backlogA curated knowledge base the copilot reads (em-ask / em-howto); the one Notion write is a gap row on a miss
TabilityThe OKR system of recordOKRs are authored in Tability and mirrored into em.objectives / em.key_results for in-product visibility
AirtableThe BigMac best-practices gridThe framework grid is maintained in Airtable; the platform stores per-account run results in em.bigmac_*