vibn-frontend/prd-template/campreg-data-model.md

# CampReg Data Model Specification

**Version:** 0.1  
**Date:** 2026-06-01

---

## 1. Data Model Philosophy

CampReg should be designed around a marketplace-connected, multi-tenant, family-centered data model.

The core data model must support:

- Parent-owned child profiles
- Provider-owned operational records
- Marketplace listing data
- Multiple registration modes
- Multi-location providers
- Multiple seasons
- Multiple programs and sessions
- Payment and ledger history
- Forms and custom fields
- Staff roles and permissions
- Attendance and check-in/check-out
- Health and medication records with restricted access
- Marketing automation and campaign attribution
- Public API and webhooks

The model should assume that families may interact with multiple providers over time through the same parent account. This is a major advantage over isolated provider-only registration systems.

---

## 2. Tenancy Model

### 2.1 Platform Tenant Types

CampReg should distinguish between:

- Platform-level users
- Provider organizations
- Parent/family accounts
- Marketplace listings
- Staff users attached to provider organizations

### 2.2 Provider Organization

A provider organization is the primary operational tenant.

Examples:

- A summer camp company
- A school
- A sports club
- A nonprofit youth organization
- A multi-location camp operator
- A solo coach or instructor

Provider data should be isolated by organization unless intentionally exposed through marketplace listings or shared parent/family interactions.

### 2.3 Parent Account

A parent account can exist independently of a provider. This is important because CampMatch is a marketplace. A parent may search, save, compare, and create child profiles before registering.

### 2.4 Shared Family Identity

A family profile can register with multiple providers. Each provider sees only the data required for that provider’s registration, operations, and communication. The platform may maintain a broader family-level profile for parent convenience, consent, history, and matching.

---

## 3. Core Entities

## 3.1 User

Represents any authenticated person.

Fields:

- id
- email
- phone
- first_name
- last_name
- auth_provider
- email_verified_at
- phone_verified_at
- created_at
- updated_at
- last_login_at
- status

Relationships:

- May belong to one or more family accounts
- May belong to one or more provider organizations
- May have platform admin permissions

## 3.2 Family

Represents a parent-controlled household/account.

Fields:

- id
- primary_parent_user_id
- family_name
- primary_phone
- primary_email
- default_address_id
- marketing_consent_status
- operational_sms_consent_status
- created_at
- updated_at

Relationships:

- Has many parents/guardians
- Has many campers/kids
- Has many registrations
- Has many payment methods via processor tokens
- Has many emergency contacts

## 3.3 Parent / Guardian

Represents a user’s role within a family.

Fields:

- id
- family_id
- user_id
- relationship_to_child
- is_primary_guardian
- can_register
- can_pay
- can_manage_pickups
- can_receive_emergency_messages
- created_at
- updated_at

## 3.4 Camper / Kid

Represents a child profile controlled by a family.

Fields:

- id
- family_id
- first_name
- last_name
- preferred_name
- date_of_birth
- grade
- gender_optional
- pronouns_optional
- interests_json
- skill_levels_json
- accessibility_notes
- dietary_notes
- allergy_summary
- medical_flag_summary
- created_at
- updated_at

Sensitive fields must be permission-scoped and carefully separated where appropriate.

## 3.5 Provider Organization

Fields:

- id
- legal_name
- public_name
- organization_type
- website_url
- support_email
- support_phone
- billing_email
- verification_status
- claim_status
- created_at
- updated_at

Relationships:

- Has many locations
- Has many provider users
- Has many listings
- Has many seasons
- Has many programs
- Has many sessions
- Has many registrations

## 3.6 Provider Location

Fields:

- id
- provider_organization_id
- name
- address_line_1
- address_line_2
- city
- region
- postal_code
- country
- latitude
- longitude
- timezone
- created_at
- updated_at

## 3.7 Marketplace Listing

Represents the public CampMatch listing.

Fields:

- id
- provider_organization_id nullable
- claimed_by_provider_id nullable
- public_name
- slug
- description
- short_description
- categories_json
- age_min
- age_max
- location_id
- website_url
- external_registration_url
- registration_mode
- listing_status
- verification_status
- source
- seo_title
- seo_description
- created_at
- updated_at

Registration modes:

- external_link
- lead_capture
- campreg_registration

## 3.8 Season

Fields:

- id
- provider_organization_id
- name
- start_date
- end_date
- registration_open_at
- registration_close_at
- status
- created_at
- updated_at

## 3.9 Program

A program is a type of offering, such as Soccer Camp, Art Camp, STEM Camp.

Fields:

- id
- provider_organization_id
- season_id nullable
- name
- description
- category
- age_min
- age_max
- default_price
- default_capacity
- status
- created_at
- updated_at

## 3.10 Session

A session is a specific scheduled instance of a program.

Fields:

- id
- provider_organization_id
- program_id
- location_id
- name
- start_date
- end_date
- daily_start_time
- daily_end_time
- age_min
- age_max
- capacity
- price
- deposit_amount
- registration_status
- waitlist_enabled
- created_at
- updated_at

## 3.11 Registration

Represents a parent’s registration transaction/workflow.

Fields:

- id
- family_id
- provider_organization_id
- status
- registration_source
- marketplace_referral_id nullable
- started_at
- completed_at
- cancelled_at
- created_at
- updated_at

Statuses:

- started
- pending_forms
- pending_payment
- completed
- waitlisted
- cancelled
- refunded

## 3.12 Enrollment

Represents a camper enrolled in a specific session.

Fields:

- id
- registration_id
- camper_id
- session_id
- enrollment_status
- waitlist_position nullable
- price_charged
- discount_amount
- financial_aid_amount
- created_at
- updated_at

Statuses:

- enrolled
- waitlisted
- cancelled
- transferred
- completed
- no_show

## 3.13 Form Template

Fields:

- id
- provider_organization_id
- name
- description
- applies_to
- schema_json
- required
- version
- status
- created_at
- updated_at

Applies to:

- family
- parent
- camper
- registration
- staff

## 3.14 Form Submission

Fields:

- id
- form_template_id
- family_id nullable
- camper_id nullable
- registration_id nullable
- provider_organization_id
- submitted_by_user_id
- submission_json
- status
- submitted_at
- approved_at
- rejected_at
- created_at
- updated_at

## 3.15 Document

Fields:

- id
- provider_organization_id nullable
- family_id nullable
- camper_id nullable
- registration_id nullable
- uploaded_by_user_id
- file_url
- file_type
- document_type
- status
- created_at
- updated_at

## 3.16 Waiver / Agreement

Fields:

- id
- provider_organization_id
- title
- body_markdown
- version
- effective_date
- status
- created_at
- updated_at

## 3.17 Signature Record

Fields:

- id
- waiver_id
- user_id
- family_id
- camper_id nullable
- registration_id nullable
- signed_name
- signed_at
- ip_address
- user_agent
- created_at

## 3.18 Payment

Fields:

- id
- provider_organization_id
- family_id
- registration_id nullable
- processor
- processor_payment_id
- amount
- currency
- status
- payment_method_summary
- paid_at
- failed_at
- refunded_at
- created_at
- updated_at

## 3.19 Invoice

Fields:

- id
- provider_organization_id
- family_id
- registration_id nullable
- invoice_number
- subtotal
- discounts
- taxes
- fees
- total
- balance_due
- due_date
- status
- created_at
- updated_at

## 3.20 Ledger Entry

Fields:

- id
- provider_organization_id
- family_id
- registration_id nullable
- entry_type
- amount
- currency
- description
- related_payment_id nullable
- created_at

Entry types:

- invoice_created
- payment_received
- refund_issued
- discount_applied
- manual_adjustment
- failed_payment

## 3.21 Attendance Record

Fields:

- id
- provider_organization_id
- session_id
- camper_id
- date
- status
- checked_in_at
- checked_in_by_staff_id
- checked_out_at
- checked_out_by_staff_id
- pickup_person_id nullable
- notes
- created_at
- updated_at

Statuses:

- present
- absent
- checked_in
- checked_out
- late
- early_pickup

## 3.22 Authorized Pickup

Fields:

- id
- family_id
- camper_id nullable
- name
- relationship
- phone
- email
- photo_url optional
- authorized_by_user_id
- status
- valid_from
- valid_until
- created_at
- updated_at

## 3.23 Staff User

Fields:

- id
- provider_organization_id
- user_id
- role_id
- title
- department
- status
- created_at
- updated_at

## 3.24 Role

Fields:

- id
- provider_organization_id
- name
- description
- permissions_json
- created_at
- updated_at

Core roles:

- Provider Owner
- Camp Director
- Registrar/Admin
- Counselor
- Medical Staff
- Finance Staff
- Marketing Staff

## 3.25 Medication

Fields:

- id
- provider_organization_id
- camper_id
- name
- dosage
- frequency
- instructions
- prescribing_doctor optional
- start_date
- end_date
- status
- created_at
- updated_at

## 3.26 Medication Dispense

Fields:

- id
- medication_id
- camper_id
- provider_organization_id
- dispensed_at
- dispensed_by_staff_id
- dosage_given
- notes
- created_at

## 3.27 Incident Report

Fields:

- id
- provider_organization_id
- session_id nullable
- camper_id nullable
- reported_by_staff_id
- incident_type
- severity
- description
- action_taken
- parent_notified_at nullable
- status
- created_at
- updated_at

## 3.28 Message

Fields:

- id
- provider_organization_id nullable
- family_id nullable
- campaign_id nullable
- message_type
- channel
- subject
- body
- sent_by_user_id nullable
- sent_at
- status
- created_at

Channels:

- email
- sms
- push
- portal

## 3.29 Lead

Fields:

- id
- marketplace_listing_id
- provider_organization_id nullable
- parent_user_id nullable
- family_id nullable
- child_age
- interests_json
- requested_dates
- message
- source
- status
- assigned_to_staff_id nullable
- created_at
- updated_at

## 3.30 Campaign

Fields:

- id
- provider_organization_id
- campaign_type
- source_system
- title
- goal
- target_audience_json
- content_json
- approval_status
- missinglettr_campaign_id nullable
- scheduled_at nullable
- created_at
- updated_at

## 3.31 API Key

Fields:

- id
- provider_organization_id
- name
- key_hash
- scopes_json
- created_by_user_id
- last_used_at
- revoked_at
- created_at

## 3.32 Webhook Subscription

Fields:

- id
- provider_organization_id
- target_url
- event_types_json
- signing_secret_hash
- status
- created_at
- updated_at

## 3.33 Webhook Event

Fields:

- id
- provider_organization_id
- event_type
- payload_json
- delivery_status
- attempts
- last_attempt_at
- created_at

---

## 4. Audit Logging

Every sensitive or operationally important action should generate an audit record.

Required audit events:

- User login
- Permission change
- Provider claim approval
- Listing update
- Registration created/completed/cancelled
- Payment received/refunded/failed
- Form submitted/approved/rejected
- Camper medical data viewed
- Medication dispensed
- Attendance changed
- Pickup authorization changed
- Staff role changed
- API key created/revoked
- Webhook created/updated

Audit log fields:

- id
- actor_user_id
- provider_organization_id nullable
- family_id nullable
- entity_type
- entity_id
- action
- before_json nullable
- after_json nullable
- ip_address
- user_agent
- created_at

---

## 5. Data Access Rules

### 5.1 Parent Access

Parents can access:

- Their family profile
- Their children’s profiles
- Their registrations
- Their forms
- Their payments
- Their authorized pickups
- Provider messages sent to them

Parents cannot access:

- Other families
- Provider internal notes unless shared
- Staff-only incident notes unless shared
- Other campers

### 5.2 Provider Access

Providers can access:

- Registrations submitted to their organization
- Forms required by their organization
- Payment and ledger data for their registrations
- Attendance for their sessions
- Staff and operational data for their organization

Providers should only access child/family data necessary for the relationship and purpose.

### 5.3 Staff Access

Staff access depends on roles.

Counselor access:

- Session roster
- Attendance
- Pickup verification
- Emergency contacts
- Allergy flags if needed

Medical staff access:

- Medication records
- Medical notes
- Dispense records
- Health forms

Finance access:

- Invoices
- Payments
- Ledgers
- Refunds

Marketing access:

- Leads
- Campaign audiences
- Non-sensitive profile segments
- Consent-filtered parent communication lists

---

## 6. Data Retention

Required retention policies should be configurable by provider and jurisdiction.

Suggested categories:

- Parent/family profiles
- Child profiles
- Registration records
- Payment records
- Tax/receipt records
- Attendance records
- Medical records
- Incident records
- Marketing consent records
- Audit logs

Retention must support:

- Legal requirements
- Provider policies
- Parent deletion/export requests
- Child data minimization
- Backup retention windows

---

## 7. Reporting Model

Reporting should be built on clean operational tables plus an analytics layer.

Suggested approach:

- PostgreSQL for operational data
- Event table for behavioral and marketplace events
- BigQuery or analytics warehouse for reporting, marketplace trends, and growth automation

Important reporting dimensions:

- Provider
- Location
- Season
- Program
- Session
- Category
- Age group
- City/region
- Registration source
- Campaign source
- Parent status
- Child interest

---

## 8. Marketplace Events

Track events such as:

- search.performed
- listing.viewed
- listing.saved
- listing.compared
- registration.clicked
- lead.submitted
- registration.started
- registration.completed
- provider.claim_started
- provider.claim_completed

These events power marketplace analytics, provider reporting, and VibnAI growth recommendations.