# DATA / DOMAIN MODEL v0.1 — APPROVED PLANNING BASELINE

**Phase 0 · 3 October 2026 · conceptual contracts only**  
**Owner adoption: PASS WITH CONDITIONS**, Owner Planning Disposition §§1–2, 3 October 2026. Governing conceptual data planning contract; provider/identity/dedup/dispatch/retention decisions remain OPEN. Adoption does not authorize a database/schema/migration.
Sources: Owner §7; Constitution XI; Technical Direction D/F/G; Architecture §§6–10/24; preceding Brand/Design/Security candidates. **No production schema, migrations, database resource or selected ORM/provider.**

## Domain ownership and allowed relationships

| Domain | Authority / conceptual attributes | Relationships and restrictions |
|---|---|---|
| Company/PublicPage/Practice | CMS; stable editorial identity, English content, metadata, approval/publication revision, permitted media references | Bounded page/practice templates; no private operational entities |
| WorkItem/CaseStudy | CMS; accurate title/context/role/evidence, practice, permission, media and three independent dimensions | `relationship`, `maturity`, `publication` never one status; no connection to venture live databases |
| MusicPractice | CMS; approved positioning/service explanation and music CTA | Practice within master brand, not an artist operations system |
| MusicProof | CMS; accurate relationship/role, approved public description/source, permitted media/rights/withdrawal reference | Small curated proof associated with MusicPractice; no full EPK/catalog/royalty contract |
| PublicMedia | CMS/approved media service; asset identity/version, caption/alt, dimensions, permission/use/expiry/withdrawal provenance | Referenced by approved content/release; public URL alone is not permission |
| ContentApproval | Editorial approval record; identified revision, approver, permitted use and conditions | Binds the actual approved revision; cannot authorize procurement or product execution |
| InquirySubmission | Journal; internal submission identity, practice, acceptance timestamp, approved minimum contact/intake, acceptance/handoff state | Business OR Music variant; no accounts, files, sales stages, tenants or pricing commitments |
| DeliveryIntent | Journal/outbox; accepted-submission reference, required destination/purpose, dispatch status, safe scheduling/attempt correlation | Required intent commits with inquiry; no acceptance without it; no message broker selected |
| DeliveryAttempt/Event | Minimal journal delivery/error/retry state; provider correlation, event identity/class/time and bounded safe diagnostics | Internal recovery truth, not full customer communications history or CRM |
| ReleaseProvenance | Derived immutable/versioned metadata; app/build identity, approved content revision, public asset/version refs, publication time, approval/release identity | Answers what approved release is live; not second editorial store or justified new database |

Relationships above are conceptual. Attribute proposals are not a relational schema or field implementation. Lifecycle/source ownership is binding direction; exact IDs, field validation/limits/storage layout and retention remain design/validation choices.

## Work & Ventures dimensions

- **Relationship:** owned venture, client engagement, internal initiative or accurately justified relationship; actual item evidence required.
- **Maturity:** research, prototype, building, beta, operating, completed or justified state; no inferred success.
- **Publication:** draft, approved, published, withdrawn; independent permission state, not business maturity.

A draft operating venture remains unpublished. A published prototype is not operating. A client engagement is not owned because it has a case study. Content approval/permissions govern projection, not the public index's display logic alone.

## Business and Music inquiry concepts

Common proposed minimum: practice, contact name/email or approved equivalent, bounded brief, permitted privacy/context acknowledgement, acceptance identity/time and delivery state. Exact required/optional fields, notices and legitimate retention are **OPEN**, determined by actual offers/privacy/responder process.

Business variant: approved practice/problem/context and bounded relevant needs. Music variant: artist/project context and accurately described enquirer role/request, without implying representation/rights or collecting private royalty/catalog/contract material. No uploads; no unnecessary phone/budget/sensitive detail by default. Additional fields require evidence of necessity, privacy review and applicable approval.

Browser information is untrusted; server validates practice/shape/limits. Internal IDs are correlation, **not authentication secrets**. No public inquiry-lookup endpoint/portal or public ID enumeration. Any optional receipt exposure would require separately reviewed security/design approval; it is not part of this candidate.

## Acceptance and outbox invariant

**accepted inquiry + required delivery intent must commit atomically before success.**

Conceptual transaction: validate bounded input → resolve approved request identity/dedup semantics → persist accepted inquiry and required notification/handoff intent in one atomic transaction → commit → return confirmed acceptance. External email/CRM and analytics are not transaction prerequisites.

Known rollback/DB rejection: no acceptance success. Lost response/ambiguous commit: do not assume rejected or blindly create another acceptance; safely resolve within the approved identity policy. Once committed, provider failure cannot erase or reverse the accepted record. No exactly-once third-party guarantee.

Identity policies must address retries, concurrent repeats, changed payload under reused identity, collision/expiry, authenticated internal access and no public enumeration. **Exact key generation/retention/conflict policy is OPEN pending H3 and Security/Integration review.** A candidate identifier field is not a chosen dedup mechanism.

## Conceptual lifecycle and failure semantics

| Concept | Candidate state family / transition invariant |
|---|---|
| Inquiry acceptance | Validated but uncommitted is not accepted; known committed acceptance is durable journal truth; rejected/uncertain response is not success |
| Intent | pending → eligible → attempting → provider-acknowledged or retry-required → resolved/manual attention; exact state names/storage unselected |
| Attempt/event | Record safe correlation and observed outcome; distinguish timeout/unknown result, provider accepted, delivered/bounced and staff response |
| Retry | Durable next eligibility and bounded attempt policy; backoff/concurrency chosen after actual limits; no fire-and-forget or process-memory ownership |
| Staff recovery | Restricted inspect/retry/disposition under authority; no sales pipeline, ownership stage table or custom operations dashboard |
| Content | draft → reviewed/approved revision → published → corrected/withdrawn with preserved attribution |
| Release | validated candidate → authorized promotion → current approved release; failed build never replaces working release |

Do not call provider acknowledgment “delivered” or delivery “human follow-up.” CRM transfer success tracks handoff only; CRM owns later commercial truth. Dedup of callback events and external operations has separate semantics from request dedup.

## Retention, classification and deletion

| Class | Rule / unresolved operating input |
|---|---|
| Approved public editorial/media | Rights, maintained truth, version/withdrawal and usable export; retention strategy awaiting content/legal policy |
| Draft/review/permissions | Restricted editorial provenance; access/export and required audit history reviewed; not public by default |
| Private inquiry/contact | Minimum necessary for actual response/legal obligations; exact lawful retention/deletion Owner/legal decision before production |
| Delivery diagnostics/correlation | Restricted, minimized safe fields; bounded retry and troubleshooting usefulness; no payload/token dumps |
| Release provenance/evidence | Sufficient attributable history for correction/recovery/review; no private inquiry data |
| Backups/exports | Same sensitivity as source data; restricted location/access, available history, deletion limitations disclosed |
| Anonymous analytics | Approved non-private events only; consent/processor/retention limitations; not acceptance system of record |

Deletion/withdrawal must consider dependent attempts, cached media, exports/backups, incident/legal requirements and approved access. No invented retention duration, legal basis or perfect erasure claim. Avoid cascading accepted-record deletion merely because delivery fails.

## Recovery, release and source-of-truth contracts

CMS public descriptions are not rights/legal proof by themselves; verified rights records establish allowed use. Journal acceptance is authoritative independent of notifications. Email owns observed provider events; CRM (if approved) owns sales follow-up; booking owns calendar bookings; each venture/music platform owns only its actual operational truth.

Coordinated code/database restore must recover compatible accepted inquiries/intents and reconcile attempts before replay. Lost/duplicate external effects remain real risks; actual plan/window/history, export/restore, RPO/RTO require H8, not documentary defaults.

Release metadata references approved content and assets without duplicating inquiry/private data. Exact mechanism may be validated build/deployment/CMS metadata; no separate release database selected. Media/CDN export/removal must preserve permission and history.

## Validation and acceptance

Required later tests/evidence: approval/revision mapping; three-dimension fixtures; minimized business/music contracts; atomic rollback/no-orphan-intent; ambiguity/lost-response/concurrent dedup/conflict; restart/idle/replica dispatch; callback replay; export/deletion/restore compatibility and safe replay; no public lookup/private analytics.

H2/H10 content/export, H3 identity/journal/outbox, H4 events, H6 telemetry, H8 restore, H9 access, H11 conditional storage. Attribute/state proposals need explicit reviewed decisions before schemas or technical cuts. Candidate is complete as a conceptual planning contract while these choices stay unresolved.