B2BEA.org V1 Permission + Lifecycle Matrix

Source of record: RedKey Supabase Studio artifact.

• Project: B2BEA.org Rebuild
• Project ID: a820dd0c-6cef-4133-bfbd-d802fd806e44
• Artifact: permission-lifecycle-matrix
• Artifact ID: dcfc8620-9f28-4019-aeeb-de3e279fd7a7
• Version: 3
• Status: draft
• Updated: 2026-05-06T20:00:08.982+00:00

Keep internal B2BEA administration simple; enforce external self-service, entitlements, ownership, lifecycle, and public visibility rules rigorously.

Core admins: Brett, Sarah, and Justin.

V1 rule: all three can make core site/admin changes. Avoid complex internal admin tiers for V1.

Required controls:

• Preview.
• Status.
• Publish/archive.
• Rollback where feasible.
• Audit events for public/material changes.
• Required fields and validation.

Not V1:

• Granular internal admin privilege tiers.
• Multi-step internal approval chains for the core team.

| ID | Topic | Decision | Rationale | |---|---|---|---| | DEC-001 | Public practitioner company profiles | Exclude from V1. Vendor public profiles are V1; practitioner company accounts are private workspace only. | Practitioner company value in V1 is operational access for seats, academy, careers, entitlements, and team reporting. Public company pages would add a new public directory/moderation surface without being required for V1. | | DEC-002 | Company-created jobs | Require B2BEA admin review before public publishing in V1. | Jobs are public-facing and need quality, trust, and spam controls. | | DEC-003 | Sanity versus Supabase source of truth | Sanity owns editorial/public content. B2BEA Supabase owns application and operational data, including people, company, vendor, membership, course, survey, job, event, analytics, and notification records. | Keep content editing in the CMS and product/workflow state in the application database. | | DEC-004 | Notifications | V1 is email-first with an internal notification event log. In-app notifications are designed for later unless a surface explicitly needs them. | Email covers V1 production needs with less UI/state complexity. |

| Role | Description | Access Boundary | |---|---|---| | anonymous | Unauthenticated public visitor. | Public content, ungated forms, public surveys, vendor/person/job/event pages, signup/login. | | member | Authenticated individual with a profile. | Own profile, own learning, own survey responses, member resources according to entitlements. | | pro_member | Member with paid/pro entitlement. | Pro gated resources, eligible academy/content/event benefits. | | vendor_admin | Vendor user who manages a vendor account. | Own vendor profile submissions, vendor team, content submissions, leads/analytics/billing when enabled. | | vendor_member | Vendor team member with limited vendor workspace access. | Vendor workspace sections assigned by vendor admin. | | company_admin | Practitioner company user who manages company access. | Own company employees, seats, academy/careers access, company entitlements, team reporting. | | company_employee | Employee under a practitioner company account. | Assigned academy/career/resources benefits, own profile and progress. | | author | Content contributor. | Own drafts/submissions where enabled; public publishing controlled by B2BEA admin

| Area | Anonymous | Member | Pro Member | Vendor Admin | Company Admin | B2BEA Admin | |---|---|---|---|---|---|---| | Public pages and directories | read | read | read | read | read | create/update/publish/archive | | Custom HTML landing/resource pages | read when published | read by gate | read by gate | none unless sponsor workflow | none unless assigned | import/preview/publish/archive/rollback | | Sanity standard pages | read when published | read by gate | read by gate | submit where enabled | none | create/update/preview/schedule/publish/archive | | Member profile | read public projection only | read/update own | read/update own | read own person only | read own person only | read/update/support | | Vendor profile | read published | read published | read published | submit updates for own vendor | read published | create/update/approve/publish/archive | | Vendor content submissions | none | none | none | create/update own submissions | none | review/approve/reject/publish/archive | | Company workspace | none | none unless employee | none unless employee | none | manage own company | create/update/support/audit | | Academy courses | browse public catalog | enroll/take if ent

| Entity | Owner | Source Of Truth | States | Public Visibility | Approval Rule | |---|---|---|---|---|---| | Sanity standard page | b2bea_admin | Sanity | draft, preview, scheduled, published, archived | Published only. | Core admin can publish directly; audit material public changes. | | Custom HTML landing/resource page | b2bea_admin | Code/import registry | draft, preview, published, archived, rolled_back | Published only. | Core admin can publish directly; rollback/archive required. | | Article/resource/guide/report | b2bea_admin or author/vendor by submission | Sanity plus Supabase tracking as needed | draft, submitted, in_review, approved, scheduled, published, rejected, archived | Published only. | Vendor/author submissions require B2BEA review. | | Vendor profile | vendor_admin plus b2bea_admin | Supabase | unclaimed, claimed, update_submitted, in_review, approved, published, rejected, archived | Approved/published fields only. | Vendor changes submit for admin approval before public projection changes. | | Member profile | member | Supabase | incomplete, active, public_profile_enabled, hidden, `suspen

• Public read paths can be static/client-rendered when data is already public.
• Any mutation by members, vendors, companies, or anonymous users needs server-side validation and ownership checks.
• Entitlement decisions should not rely only on client-side checks.
• Vendor/company/member data updates must validate ownership before write.
• Public projection changes should be auditable even when the core admin team can publish directly.
• Billing, membership, course access, survey assignment, and company seats require explicit entitlement checks.
• Export actions require role checks and audit events because they can expose sensitive data.

No major permission/lifecycle decisions remain open at this level. Deeper specs may add implementation-level decisions.

• design-system-spec
• publishing-model-spec
• data-model-spec
• surface-specs
• security-privacy-spec