@elevasis/core 0.5.0 → 0.7.0

package/src/organization-model/domains/statuses.ts

@@ -0,0 +1,130 @@
+import { z } from 'zod'
+
+// ---------------------------------------------------------------------------
+// Semantic class enum — one value per status category.
+// Every status entry declares which category it belongs to via semanticClass.
+// ---------------------------------------------------------------------------
+
+export const StatusSemanticClassSchema = z.enum([
+  'delivery.task',
+  'delivery.project',
+  'delivery.milestone',
+  'queue',
+  'execution',
+  'schedule',
+  'schedule.run',
+  'request'
+])
+
+// ---------------------------------------------------------------------------
+// Status entry schema
+// ---------------------------------------------------------------------------
+
+export const StatusEntrySchema = z.object({
+  id: z.string().trim().min(1).max(100),
+  label: z.string().trim().min(1).max(120),
+  semanticClass: StatusSemanticClassSchema,
+  category: z.string().trim().min(1).max(80).optional()
+})
+
+// ---------------------------------------------------------------------------
+// Domain schema — a flat array of status entries keyed by id
+// ---------------------------------------------------------------------------
+
+export const StatusesDomainSchema = z.object({
+  entries: z.array(StatusEntrySchema).default([])
+})
+
+// ---------------------------------------------------------------------------
+// Seed — covers all status enums in scope (delivery, queue, execution,
+// schedule, schedule.run, request). Delivery project/milestone statuses are
+// included here as semantic references; they mirror delivery.ts but live in
+// the statuses domain as the vibe-readable registry.
+// ---------------------------------------------------------------------------
+
+export const DEFAULT_ORGANIZATION_MODEL_STATUSES: z.infer<typeof StatusesDomainSchema> = {
+  entries: [
+    // --- delivery.task (TaskStatus — 9 values) ---
+    { id: 'delivery.task.planned', label: 'Planned', semanticClass: 'delivery.task', category: 'delivery' },
+    { id: 'delivery.task.in_progress', label: 'In Progress', semanticClass: 'delivery.task', category: 'delivery' },
+    { id: 'delivery.task.blocked', label: 'Blocked', semanticClass: 'delivery.task', category: 'delivery' },
+    { id: 'delivery.task.submitted', label: 'Submitted', semanticClass: 'delivery.task', category: 'delivery' },
+    { id: 'delivery.task.approved', label: 'Approved', semanticClass: 'delivery.task', category: 'delivery' },
+    {
+      id: 'delivery.task.revision_requested',
+      label: 'Revision Requested',
+      semanticClass: 'delivery.task',
+      category: 'delivery'
+    },
+    { id: 'delivery.task.rejected', label: 'Rejected', semanticClass: 'delivery.task', category: 'delivery' },
+    { id: 'delivery.task.cancelled', label: 'Cancelled', semanticClass: 'delivery.task', category: 'delivery' },
+    { id: 'delivery.task.completed', label: 'Completed', semanticClass: 'delivery.task', category: 'delivery' },
+
+    // --- delivery.project (ProjectStatus — 6 values) ---
+    { id: 'delivery.project.active', label: 'Active', semanticClass: 'delivery.project', category: 'delivery' },
+    { id: 'delivery.project.on_track', label: 'On Track', semanticClass: 'delivery.project', category: 'delivery' },
+    { id: 'delivery.project.at_risk', label: 'At Risk', semanticClass: 'delivery.project', category: 'delivery' },
+    { id: 'delivery.project.blocked', label: 'Blocked', semanticClass: 'delivery.project', category: 'delivery' },
+    { id: 'delivery.project.paused', label: 'Paused', semanticClass: 'delivery.project', category: 'delivery' },
+    { id: 'delivery.project.completed', label: 'Completed', semanticClass: 'delivery.project', category: 'delivery' },
+
+    // --- delivery.milestone (MilestoneStatus — 5 values) ---
+    {
+      id: 'delivery.milestone.upcoming',
+      label: 'Upcoming',
+      semanticClass: 'delivery.milestone',
+      category: 'delivery'
+    },
+    {
+      id: 'delivery.milestone.in_progress',
+      label: 'In Progress',
+      semanticClass: 'delivery.milestone',
+      category: 'delivery'
+    },
+    {
+      id: 'delivery.milestone.blocked',
+      label: 'Blocked',
+      semanticClass: 'delivery.milestone',
+      category: 'delivery'
+    },
+    { id: 'delivery.milestone.overdue', label: 'Overdue', semanticClass: 'delivery.milestone', category: 'delivery' },
+    {
+      id: 'delivery.milestone.completed',
+      label: 'Completed',
+      semanticClass: 'delivery.milestone',
+      category: 'delivery'
+    },
+
+    // --- queue (QueueTaskStatus — 5 values, maps hitl/command-queue tasks) ---
+    { id: 'queue.pending', label: 'Pending', semanticClass: 'queue', category: 'queue' },
+    { id: 'queue.processing', label: 'Processing', semanticClass: 'queue', category: 'queue' },
+    { id: 'queue.completed', label: 'Completed', semanticClass: 'queue', category: 'queue' },
+    { id: 'queue.failed', label: 'Failed', semanticClass: 'queue', category: 'queue' },
+    { id: 'queue.expired', label: 'Expired', semanticClass: 'queue', category: 'queue' },
+
+    // --- execution (ExecutionStatus — 5 values) ---
+    { id: 'execution.pending', label: 'Pending', semanticClass: 'execution', category: 'execution' },
+    { id: 'execution.running', label: 'Running', semanticClass: 'execution', category: 'execution' },
+    { id: 'execution.completed', label: 'Completed', semanticClass: 'execution', category: 'execution' },
+    { id: 'execution.failed', label: 'Failed', semanticClass: 'execution', category: 'execution' },
+    { id: 'execution.warning', label: 'Warning', semanticClass: 'execution', category: 'execution' },
+
+    // --- schedule (schedule status — 4 values) ---
+    { id: 'schedule.active', label: 'Active', semanticClass: 'schedule', category: 'schedule' },
+    { id: 'schedule.paused', label: 'Paused', semanticClass: 'schedule', category: 'schedule' },
+    { id: 'schedule.completed', label: 'Completed', semanticClass: 'schedule', category: 'schedule' },
+    { id: 'schedule.cancelled', label: 'Cancelled', semanticClass: 'schedule', category: 'schedule' },
+
+    // --- schedule.run (schedule run status — 4 values) ---
+    { id: 'schedule.run.running', label: 'Running', semanticClass: 'schedule.run', category: 'schedule' },
+    { id: 'schedule.run.completed', label: 'Completed', semanticClass: 'schedule.run', category: 'schedule' },
+    { id: 'schedule.run.failed', label: 'Failed', semanticClass: 'schedule.run', category: 'schedule' },
+    { id: 'schedule.run.cancelled', label: 'Cancelled', semanticClass: 'schedule.run', category: 'schedule' },
+
+    // --- request (RequestStatus — 4 values, maps reported_requests) ---
+    { id: 'request.open', label: 'Open', semanticClass: 'request', category: 'request' },
+    { id: 'request.investigating', label: 'Investigating', semanticClass: 'request', category: 'request' },
+    { id: 'request.resolved', label: 'Resolved', semanticClass: 'request', category: 'request' },
+    { id: 'request.wont_fix', label: "Won't Fix", semanticClass: 'request', category: 'request' }
+  ]
+}

package/src/organization-model/index.ts

@@ -6,8 +6,8 @@ export * from './resolve'
 export * from './foundation'
 export * from './graph'
 export * from './domains/branding'
-export * from './domains/crm'
-export * from './domains/delivery'
+export * from './domains/sales'
+export * from './domains/projects'
 export * from './domains/features'
-export * from './domains/lead-gen'
+export * from './domains/prospecting'
 export * from './domains/navigation'

package/src/organization-model/organization-graph.mdx

@@ -62,6 +62,7 @@ This means runtime topology is represented as bridged `resource` nodes plus rela
 - Implementation-resource bridging prefers `organizationModel.resourceMappings`.
 - Semantic grouping now comes from the unified `organizationModel.features` array. The builder no longer emits separate `domain` nodes.
 - Command View resource `domains` metadata is currently bridged onto `feature` references, not onto a distinct domain-node layer.
+- The 2026-04-20 reality-domain expansion (identity, customers, offerings, roles, goals, statuses, operations, techStack) does not introduce new graph node kinds. Those domains are model-layer data; they are not independently represented as graph nodes. They can be surfaced as metadata on the organization root node when a consumer needs to expose them through a graph lens.
 - Graph defaults remain valid when produced by `resolveOrganizationModel()`.
 - If the graph needs a concept the model cannot express, extend the model first.
 

package/src/organization-model/organization-model.mdx

@@ -5,7 +5,7 @@ description: Organization OS Model layer documentation for the semantic organiza
 
 ## Overview
 
-Within Organization OS, the organization model is the **Model** layer and part of the cross-cutting **Public API** layer. It is the semantic contract that maps an organization's product shape to domains, features, navigation surfaces and groups, domain-specific semantics (CRM pipeline, lead-gen lifecycle, delivery status), and resource mappings. It is schema-first, versioned, and validated.
+Within Organization OS, the organization model is the **Model** layer and part of the cross-cutting **Public API** layer. It is the semantic contract that maps an organization's full organizational reality to domains, features, navigation surfaces and groups, domain-specific semantics (sales pipeline, prospecting lifecycle, projects status), and resource mappings. It is schema-first, versioned, and validated.
 
 The model is authored in `@repo/core` and published as a curated external package `@elevasis/core`. It is consumed by:
 
@@ -21,7 +21,7 @@ The model does **not** replace the shared feature-provider system. It enriches a
 - `packages/core/src/organization-model/types.ts` -- exported TypeScript types
 - `packages/core/src/organization-model/defaults.ts` -- `DEFAULT_ORGANIZATION_MODEL`
 - `packages/core/src/organization-model/resolve.ts` -- `defineOrganizationModel`, `resolveOrganizationModel`
-- `packages/core/src/organization-model/domains/*.ts` -- feature schema, navigation surfaces, CRM/lead-gen/delivery semantics
+- `packages/core/src/organization-model/domains/*.ts` -- feature schema, navigation surfaces, sales/prospecting/projects semantics, and the 8 reality domains (identity, customers, offerings, roles, goals, statuses, operations, shared/techStack)
 - `packages/core/src/published.ts` -- curated root barrel for the published package
 - `packages/core/src/organization-model/published.ts` -- curated organization-model barrel
 - `packages/core/src/__tests__/template-foundations-compatibility.test.ts` -- adapter-baseline guard
@@ -32,12 +32,31 @@ Top-level fields on `OrganizationModel`:
 
 - `version`
 - `features` -- unified feature array (`OrganizationModelFeature[]`); each entry combines access gating, semantic grouping, and display metadata
-- `branding`
+- `branding` -- display identity (org name, product name, logos)
 - `navigation` -- surfaces, groups, `defaultSurfaceId`
-- `crm` -- pipeline stages and stage semantics
-- `leadGen` -- company/contact lifecycle stages
-- `delivery` -- project/milestone/task statuses
-- `resourceMappings`
+- `sales` -- pipeline stages and stage semantics (formerly `crm`)
+- `prospecting` -- company/contact lifecycle stages (formerly `leadGen`)
+- `projects` -- project/milestone/task statuses (formerly `delivery`)
+- `identity` -- legal identity, mission/vision, industry, geography, and temporal anchors
+- `customers` -- customer segments with jobs-to-be-done, firmographics, and value propositions
+- `offerings` -- products and services with pricing model and segment/feature references
+- `roles` -- role chart with responsibilities, reporting lines, and role holders
+- `goals` -- organizational goals with period and measurable outcomes
+- `statuses` -- flat registry of all status entries across delivery, queue, execution, schedule, and request semantic classes
+- `operations` -- catalog of stateful runtime entities (HITL queue, executions, sessions, notifications, schedules)
+- `resourceMappings` -- deployable resource links, each optionally extended with `techStack` metadata
+
+### Domain Rename Wave
+
+Three legacy domain names were renamed in the 2026-04-20 expansion to align developer-facing code with user-visible labels:
+
+| Old name   | New name      | Notes                                                                                |
+| ---------- | ------------- | ------------------------------------------------------------------------------------ |
+| `crm`      | `sales`       | Domain files, feature IDs, surface IDs, imports, and sidebar labels all updated      |
+| `leadGen`  | `prospecting` | Same scope as above                                                                  |
+| `delivery` | `projects`    | Aligns with the "Projects" sidebar label; `projects` feature ID was already in place |
+
+Any reference to `crm`, `leadGen`, or `delivery` in domain files, imports, or surface IDs should be treated as a historical artifact unless explicitly annotated otherwise.
 
 ### Branding Shape
 
@@ -56,22 +75,25 @@ All `id` fields, `parentId`, `defaultSurfaceId`, and reference ID arrays use `Mo
 - Regex: `/^[a-z0-9]+(?:[-._][a-z0-9]+)*$/`
 - Max length: 100 chars
 - Allowed separators: `-`, `_`, `.`
-- Examples: `crm.pipeline`, `lead-gen.lists`, `operations.organization-graph`
+- Examples: `sales.pipeline`, `prospecting.lists`, `operations.organization-graph`
 
 This applies to domain IDs, surface IDs, navigation group IDs, and resource mapping IDs.
 
 ### Default Features
 
-Seven features ship by default in `DEFAULT_ORGANIZATION_MODEL.features`:
+Eight features ship by default in `DEFAULT_ORGANIZATION_MODEL.features`:
 
-- `crm` -- enabled; CRM pipeline and deal management
-- `lead-gen` -- enabled; prospecting, qualification, and outreach
-- `projects` -- enabled; projects, milestones, and client work execution (formerly `delivery`)
+- `crm` -- enabled; sales pipeline and deal management (feature ID unchanged; domain renamed to `sales`)
+- `lead-gen` -- enabled; prospecting, qualification, and outreach (feature ID unchanged; domain renamed to `prospecting`)
+- `projects` -- enabled; projects, milestones, and client work execution
 - `operations` -- enabled; organizational topology and orchestration visibility
 - `monitoring` -- enabled; execution monitoring
 - `settings` -- enabled; organization settings
+- `submitted-requests` -- enabled; submitted-request lifecycle surface
 - `seo` -- disabled by default; SEO surface
 
+Note: the feature IDs (`crm`, `lead-gen`) are consumer-facing identifiers that have not changed. The underlying domain key on `OrganizationModel` was renamed (`crm` → `sales`, `leadGen` → `prospecting`). Adapters that already use the feature ID constants (`CRM_FEATURE_ID`, `LEAD_GEN_FEATURE_ID`) require no change.
+
 Each feature entry (`OrganizationModelFeature`) combines what were previously three separate concepts: an access/gating key (the former `OrganizationModelFeatureKey`), a semantic domain (the former `SemanticDomainSchema` entry), and display metadata. The `features` field is now `z.array(FeatureSchema)` -- there is no separate `domains` array and no separate `enabled`/`labels` map.
 
 `FeatureModule.featureId` on the UI side maps directly to one of these IDs. No alias layer is needed. See [Feature Shell](../ui/feature-shell.mdx) for how the provider resolves feature access from this array.
@@ -88,18 +110,30 @@ Each feature entry (`OrganizationModelFeature`) combines what were previously th
 - `entityIds` -- entities this resource operates on
 - `surfaceIds` -- surfaces this resource is exposed in
 - `capabilityIds` -- capabilities this resource fulfills
+- `techStack` (optional) -- external-SaaS integration metadata; see TechStack Extension below
 
 All four ID arrays are bidirectionally validated against their counterparts (see Referential Integrity).
 
+### TechStack Extension
+
+`techStack` is an optional nested object on `ResourceMappingSchema` defined in `domains/shared.ts`. It captures external-SaaS integration metadata without introducing a tenth top-level domain. Fields:
+
+- `platform` -- name of the external platform (e.g. "HubSpot", "Stripe", "Notion")
+- `purpose` -- free-form description of what this integration does
+- `credentialStatus` -- one of `'configured' | 'pending' | 'expired' | 'missing'`
+- `isSystemOfRecord` -- boolean; whether this integration is the primary source of truth for its domain (defaults to `false`)
+
+Backward-compatible: existing resource mappings without `techStack` parse cleanly. The extension flows through `ResourceMappingSchema` automatically with no changes to `schema.ts` composition.
+
 ### Default Navigation
 
-Surfaces such as `crm.pipeline`, `lead-gen.lists`, `projects.index`, `operations.organization-graph`, and `operations.command-view`. Groups include `primary-workspace` and `primary-operations`. The model can shape shell meaning even when route files stay app-local.
+Surfaces such as `sales.pipeline`, `prospecting.lists`, `projects.index`, `operations.organization-graph`, and `operations.command-view`. Groups include `primary-workspace` and `primary-operations`. The model can shape shell meaning even when route files stay app-local.
 
 ### SurfaceDefinition Shape
 
 `OrganizationModelSurface` (inferred from `SurfaceDefinitionSchema`) defines a navigable view:
 
-- `id` -- ModelId (e.g. `crm.pipeline`)
+- `id` -- ModelId (e.g. `sales.pipeline`)
 - `label` -- display name
 - `path` -- route path, must start with `/`, max 300 chars
 - `surfaceType` -- `'page' | 'dashboard' | 'graph' | 'detail' | 'list' | 'settings'`
@@ -124,14 +158,36 @@ The default groups (`primary-workspace`, `primary-operations`) both use `placeme
 
 ### Feature-Specific Semantics
 
-The top-level `crm`, `leadGen`, and `delivery` fields on `OrganizationModel` remain as named fields (not moved into per-feature config) and carry domain-specific semantic shapes:
+Three renamed top-level domain fields carry feature-specific semantic shapes (pipeline stages, lifecycle stages, project statuses). These are named fields on `OrganizationModel`, not embedded in per-feature config:
 
-- `crm` -- pipeline stages and stage semantics
-- `leadGen` -- company and contact lifecycle stages
-- `delivery` -- project, milestone, and task statuses (used by the `projects` feature)
+- `sales` -- pipeline stages and stage semantics (formerly `crm`)
+- `prospecting` -- company and contact lifecycle stages (formerly `leadGen`)
+- `projects` -- project, milestone, and task statuses (formerly `delivery`)
 
 This is why the organization model is semantic, not just nav config -- it owns product meaning for the business objects the shell surfaces expose.
 
+### Reality Domains (New in 2026-04-20 Expansion)
+
+Five new domains capture organizational reality that was absent from the original model. They sit alongside the existing platform-configuration domains and follow the same `domains/*.ts` pattern:
+
+**`identity`** -- legal identity distinct from `branding` (which is display identity). Fields: `mission`, `vision`, `legalName`, `entityType`, `jurisdiction`, `industryCategory`, `geographicFocus`, `timeZone`, `businessHours`. All fields default to empty strings; `timeZone` defaults to `'UTC'`; `businessHours` defaults to `{}`.
+
+**`customers`** -- customer segments. Each `CustomerSegment` entry has: `id`, `name`, `description`, `jobsToBeDone`, `pains`, `gains`, `valueProp` (all plain-language strings), and `firmographics` (optional object with `companySize`, `industry`, `revenue`, `geography`). Domain defaults to `{ segments: [] }`.
+
+**`offerings`** -- products and services. Each `Product` entry has: `id`, `name`, `description`, `pricingModel` (enum: `'one-time' | 'subscription' | 'usage-based' | 'custom'`), `price` (optional number), `currency` (optional string), `targetSegmentIds` (cross-ref validated against `customers.segments[].id`), `deliveryFeatureId` (optional cross-ref validated against `features[].id`). Domain defaults to `{ products: [] }`.
+
+**`roles`** -- role chart. Each `Role` entry has: `id`, `title`, `responsibilities` (string array, default `[]`), `reportsToId` (optional, cross-ref validated within the same collection), `heldBy` (optional name or email string). All field names are plain-language; no EOS jargon (`seats`, `accountabilities`) survives. Domain defaults to `{ roles: [] }`.
+
+**`goals`** -- organizational goals. Each `Objective` entry has: `id`, `description`, `periodStart` (ISO 8601 date), `periodEnd` (ISO 8601 date, must be strictly after `periodStart`), `keyResults` (array of `{ id, description, targetValue?, currentValue?, unit? }`). User-facing text uses "goals" and "measurable outcomes" -- never "OKR" or "key results". Domain defaults to `{ objectives: [] }`.
+
+### Statuses and Operations Domains (Vibe Layer)
+
+Two domains support the ambient vibe layer's plain-language rendering:
+
+**`statuses`** -- flat registry of `StatusEntry` objects. Each entry: `id`, `label`, `semanticClass` (one of `'delivery.task' | 'delivery.project' | 'delivery.milestone' | 'queue' | 'execution' | 'schedule' | 'schedule.run' | 'request'`), optional `category`. Labels are vibe-readable: the ambient classifier narrates state using `label` from the model, never hardcoded strings. `QueueTaskStatus` in the queue domain routes through this registry. Defaults to a seed set covering all semantic classes.
+
+**`operations`** -- catalog of stateful runtime entities. Each `OperationEntry`: `id`, `label`, `semanticClass` (one of `'queue' | 'executions' | 'sessions' | 'notifications' | 'schedules'`), optional `featureId`, optional `supportedStatusSemanticClass` (ties an operation entry back to which status semantic classes apply). Default entries: `operations.queue` (HITL queue), `operations.executions`, `operations.sessions`, `operations.notifications`, `operations.schedules`.
+
 ## Authoring & Resolution
 
 - `defineOrganizationModel()` -- typed authoring helper; returns the input unchanged but constrains the type.
@@ -179,6 +235,13 @@ Merge semantics:
 
 This bidirectional enforcement is what keeps the organization model semantically consistent rather than loosely structured config.
 
+**Reality domain cross-refs** (validated in the same `superRefine` pass):
+
+- each `offerings.products[].targetSegmentIds[]` must resolve to a `customers.segments[].id`
+- each `offerings.products[].deliveryFeatureId` (when present) must resolve to a `features[].id`
+- each `roles.roles[].reportsToId` (when present) must resolve to another `roles.roles[].id` in the same collection
+- each `goals.objectives[].periodEnd` must be strictly after `periodStart` (ISO 8601 string comparison)
+
 ## Provider Integration
 
 `ElevasisFeaturesProvider` uses the organization model in three ways:
@@ -236,7 +299,9 @@ Exports the foundations module provides to consumers:
 - `FoundationFeatureKey`, `FoundationSurfaceIcon`, `FoundationNavigationSurface`, `FoundationOrganizationModel`
 - `homeLabel`, `quickAccessSurfaceIds`, `getOrganizationSurface(surfaceId)`
 
-Downstream template shells pass `canonicalOrganizationModel` into `ElevasisFeaturesProvider`, preserving host-local dashboard/nav customizations alongside the shared runtime. Feature IDs are now direct matches -- `crm`, `lead-gen`, `projects` in the org model correspond directly to the same IDs on `FeatureModule.featureId`. No alias layer is needed.
+Downstream template shells pass `canonicalOrganizationModel` into `ElevasisFeaturesProvider`, preserving host-local dashboard/nav customizations alongside the shared runtime. Feature IDs are direct matches -- `crm`, `lead-gen`, `projects` in the org model correspond directly to the same IDs on `FeatureModule.featureId`. No alias layer is needed. The domain rename wave (crm→sales, leadGen→prospecting, delivery→projects) affects the schema field names, not the feature ID constants; adapters using `CRM_FEATURE_ID`, `LEAD_GEN_FEATURE_ID`, etc. require no changes.
+
+Adapters that override the new reality domains (`identity`, `customers`, `offerings`, `roles`, `goals`) or add `techStack` metadata to resource mappings should use `/configure` as the structured entry point for those edits in external projects. `/configure` runs a layered QA flow, proposes changes, and gates the write through `resolveOrganizationModel()` + `OrganizationModelSchema.parse()` before committing.
 
 Derivative projects (`external/nirvana-marketing`, `external/ZentaraHQ`) follow the same adapter + provider-wiring baseline with their own project-local customizations.
 

package/src/organization-model/published.ts

@@ -1,20 +1,47 @@
 export { OrganizationModelSchema } from './schema'
 export { FeatureSchema } from './domains/features'
+export { TechStackEntrySchema } from './domains/shared'
 export {
   PROJECTS_FEATURE_ID,
   PROJECTS_INDEX_SURFACE_ID,
-  DELIVERY_PROJECTS_VIEW_CAPABILITY_ID,
-  CRM_FEATURE_ID,
-  LEAD_GEN_FEATURE_ID,
+  PROJECTS_VIEW_CAPABILITY_ID,
+  SALES_FEATURE_ID,
+  PROSPECTING_FEATURE_ID,
   OPERATIONS_FEATURE_ID,
   MONITORING_FEATURE_ID,
   SETTINGS_FEATURE_ID,
   SEO_FEATURE_ID,
-  CRM_PIPELINE_SURFACE_ID,
-  LEAD_GEN_LISTS_SURFACE_ID,
+  SALES_PIPELINE_SURFACE_ID,
+  PROSPECTING_LISTS_SURFACE_ID,
   OPERATIONS_ORGANIZATION_GRAPH_SURFACE_ID
 } from './contracts'
 export { DEFAULT_ORGANIZATION_MODEL } from './defaults'
+export {
+  DEFAULT_ORGANIZATION_MODEL_STATUSES,
+  StatusesDomainSchema,
+  StatusEntrySchema,
+  StatusSemanticClassSchema
+} from './domains/statuses'
+export {
+  DEFAULT_ORGANIZATION_MODEL_OPERATIONS,
+  OperationsDomainSchema,
+  OperationEntrySchema,
+  OperationSemanticClassSchema
+} from './domains/operations'
+export {
+  DEFAULT_ORGANIZATION_MODEL_CUSTOMERS,
+  CustomersDomainSchema,
+  CustomerSegmentSchema,
+  FirmographicsSchema
+} from './domains/customers'
+export {
+  DEFAULT_ORGANIZATION_MODEL_OFFERINGS,
+  OfferingsDomainSchema,
+  ProductSchema,
+  PricingModelSchema
+} from './domains/offerings'
+export { DEFAULT_ORGANIZATION_MODEL_ROLES, RolesDomainSchema, RoleSchema } from './domains/roles'
+export { DEFAULT_ORGANIZATION_MODEL_GOALS, GoalsDomainSchema, ObjectiveSchema, KeyResultSchema } from './domains/goals'
 export { defineOrganizationModel, resolveOrganizationModel } from './resolve'
 export { createFoundationOrganizationModel } from './foundation'
 
@@ -22,12 +49,30 @@ export type {
   DeepPartial,
   OrganizationModel,
   OrganizationModelBranding,
-  OrganizationModelCrm,
-  OrganizationModelDelivery,
+  OrganizationModelSales,
+  OrganizationModelProspecting,
+  OrganizationModelProjects,
+  OrganizationModelCustomerFirmographics,
+  OrganizationModelCustomers,
+  OrganizationModelCustomerSegment,
   OrganizationModelFeature,
-  OrganizationModelLeadGen,
+  OrganizationModelGoals,
+  OrganizationModelKeyResult,
   OrganizationModelNavigation,
+  OrganizationModelObjective,
+  OrganizationModelOfferings,
+  OrganizationModelOperationEntry,
+  OrganizationModelOperationSemanticClass,
+  OrganizationModelOperations,
+  OrganizationModelPricingModel,
+  OrganizationModelProduct,
   OrganizationModelResourceMapping,
+  OrganizationModelRole,
+  OrganizationModelTechStackEntry,
+  OrganizationModelRoles,
+  OrganizationModelStatuses,
+  OrganizationModelStatusEntry,
+  OrganizationModelStatusSemanticClass,
   OrganizationModelSurface
 } from './types'
 

package/src/organization-model/schema.ts

@@ -1,20 +1,34 @@
 import { z } from 'zod'
 import { OrganizationModelBrandingSchema } from './domains/branding'
-import { OrganizationModelCrmSchema } from './domains/crm'
-import { OrganizationModelDeliverySchema } from './domains/delivery'
+import { OrganizationModelSalesSchema } from './domains/sales'
+import { OrganizationModelProjectsSchema } from './domains/projects'
 import { FeatureSchema } from './domains/features'
-import { OrganizationModelLeadGenSchema } from './domains/lead-gen'
+import { OrganizationModelProspectingSchema } from './domains/prospecting'
 import { OrganizationModelNavigationSchema } from './domains/navigation'
 import { ResourceMappingSchema } from './domains/shared'
+import { IdentityDomainSchema, DEFAULT_ORGANIZATION_MODEL_IDENTITY } from './domains/identity'
+import { CustomersDomainSchema, DEFAULT_ORGANIZATION_MODEL_CUSTOMERS } from './domains/customers'
+import { OfferingsDomainSchema, DEFAULT_ORGANIZATION_MODEL_OFFERINGS } from './domains/offerings'
+import { RolesDomainSchema, DEFAULT_ORGANIZATION_MODEL_ROLES } from './domains/roles'
+import { GoalsDomainSchema, DEFAULT_ORGANIZATION_MODEL_GOALS } from './domains/goals'
+import { OperationsDomainSchema } from './domains/operations'
+import { StatusesDomainSchema } from './domains/statuses'
 
 const OrganizationModelSchemaBase = z.object({
   version: z.literal(1).default(1),
   features: z.array(FeatureSchema).default([]),
   branding: OrganizationModelBrandingSchema,
   navigation: OrganizationModelNavigationSchema,
-  crm: OrganizationModelCrmSchema,
-  leadGen: OrganizationModelLeadGenSchema,
-  delivery: OrganizationModelDeliverySchema,
+  sales: OrganizationModelSalesSchema,
+  prospecting: OrganizationModelProspectingSchema,
+  projects: OrganizationModelProjectsSchema,
+  identity: IdentityDomainSchema.default(DEFAULT_ORGANIZATION_MODEL_IDENTITY),
+  customers: CustomersDomainSchema.default(DEFAULT_ORGANIZATION_MODEL_CUSTOMERS),
+  offerings: OfferingsDomainSchema.default(DEFAULT_ORGANIZATION_MODEL_OFFERINGS),
+  roles: RolesDomainSchema.default(DEFAULT_ORGANIZATION_MODEL_ROLES),
+  goals: GoalsDomainSchema.default(DEFAULT_ORGANIZATION_MODEL_GOALS),
+  statuses: StatusesDomainSchema.default({ entries: [] }),
+  operations: OperationsDomainSchema.default({ entries: [] }),
   resourceMappings: z.array(ResourceMappingSchema).default([])
 })
 
@@ -176,12 +190,58 @@ export const OrganizationModelSchema = OrganizationModelSchemaBase.superRefine((
         addIssue(
           ctx,
           ['navigation', 'surfaces', surfaceIndex, 'resourceIds', resourceIndex],
-          `Surface "${surface.id}" references resource "${resourceId}" but that resource mapping does not include surface "${surface.id}"`
+          `Surface "${surface.id}" references resource "${resourceId}" but that surface does not include resource "${surface.id}"`
         )
       }
     })
   })
 
+  // Offerings -> CustomerSegment cross-ref: targetSegmentIds must resolve
+  const segmentsById = new Map(model.customers.segments.map((seg) => [seg.id, seg]))
+  model.offerings.products.forEach((product, productIndex) => {
+    product.targetSegmentIds.forEach((segmentId, segmentIndex) => {
+      if (!segmentsById.has(segmentId)) {
+        addIssue(
+          ctx,
+          ['offerings', 'products', productIndex, 'targetSegmentIds', segmentIndex],
+          `Product "${product.id}" references unknown customer segment "${segmentId}"`
+        )
+      }
+    })
+
+    // Offerings -> Feature cross-ref: deliveryFeatureId must resolve (when present)
+    if (product.deliveryFeatureId !== undefined && !featuresById.has(product.deliveryFeatureId)) {
+      addIssue(
+        ctx,
+        ['offerings', 'products', productIndex, 'deliveryFeatureId'],
+        `Product "${product.id}" references unknown delivery feature "${product.deliveryFeatureId}"`
+      )
+    }
+  })
+
+  // Goals -> period-range validation: periodEnd must be strictly after periodStart
+  model.goals.objectives.forEach((objective, index) => {
+    if (objective.periodEnd <= objective.periodStart) {
+      addIssue(
+        ctx,
+        ['goals', 'objectives', index, 'periodEnd'],
+        `Goal "${objective.id}" has periodEnd "${objective.periodEnd}" which must be strictly after periodStart "${objective.periodStart}"`
+      )
+    }
+  })
+
+  // Roles -> reportsToId cross-ref: each reportsToId must resolve to another role in the same collection
+  const rolesById = new Map(model.roles.roles.map((role) => [role.id, role]))
+  model.roles.roles.forEach((role, roleIndex) => {
+    if (role.reportsToId !== undefined && !rolesById.has(role.reportsToId)) {
+      addIssue(
+        ctx,
+        ['roles', 'roles', roleIndex, 'reportsToId'],
+        `Role "${role.id}" references unknown reportsToId "${role.reportsToId}"`
+      )
+    }
+  })
+
   // ResourceMapping -> Feature and Surface bidirectional validation
   model.resourceMappings.forEach((resourceMapping, resourceIndex) => {
     resourceMapping.featureIds.forEach((featureId, featureIndex) => {

package/src/organization-model/types.ts

@@ -1,22 +1,46 @@
 import type { z } from 'zod'
 import { OrganizationModelBrandingSchema } from './domains/branding'
-import { OrganizationModelCrmSchema } from './domains/crm'
-import { OrganizationModelDeliverySchema } from './domains/delivery'
+import { OrganizationModelSalesSchema } from './domains/sales'
+import { OrganizationModelProjectsSchema } from './domains/projects'
 import { FeatureSchema } from './domains/features'
-import { OrganizationModelLeadGenSchema } from './domains/lead-gen'
+import { OrganizationModelProspectingSchema } from './domains/prospecting'
 import { OrganizationModelNavigationSchema, SurfaceDefinitionSchema } from './domains/navigation'
-import { ResourceMappingSchema } from './domains/shared'
+import { ResourceMappingSchema, TechStackEntrySchema } from './domains/shared'
+import { OperationsDomainSchema, OperationEntrySchema, OperationSemanticClassSchema } from './domains/operations'
+import { StatusesDomainSchema, StatusEntrySchema, StatusSemanticClassSchema } from './domains/statuses'
+import { CustomersDomainSchema, CustomerSegmentSchema, FirmographicsSchema } from './domains/customers'
+import { OfferingsDomainSchema, ProductSchema, PricingModelSchema } from './domains/offerings'
+import { RolesDomainSchema, RoleSchema } from './domains/roles'
+import { GoalsDomainSchema, ObjectiveSchema, KeyResultSchema } from './domains/goals'
 import { OrganizationModelSchema } from './schema'
 
 export type OrganizationModel = z.infer<typeof OrganizationModelSchema>
 export type OrganizationModelBranding = z.infer<typeof OrganizationModelBrandingSchema>
-export type OrganizationModelCrm = z.infer<typeof OrganizationModelCrmSchema>
-export type OrganizationModelLeadGen = z.infer<typeof OrganizationModelLeadGenSchema>
-export type OrganizationModelDelivery = z.infer<typeof OrganizationModelDeliverySchema>
+export type OrganizationModelSales = z.infer<typeof OrganizationModelSalesSchema>
+export type OrganizationModelProspecting = z.infer<typeof OrganizationModelProspectingSchema>
+export type OrganizationModelProjects = z.infer<typeof OrganizationModelProjectsSchema>
 export type OrganizationModelFeature = z.infer<typeof FeatureSchema>
 export type OrganizationModelNavigation = z.infer<typeof OrganizationModelNavigationSchema>
 export type OrganizationModelSurface = z.infer<typeof SurfaceDefinitionSchema>
 export type OrganizationModelResourceMapping = z.infer<typeof ResourceMappingSchema>
+export type OrganizationModelTechStackEntry = z.infer<typeof TechStackEntrySchema>
+export type OrganizationModelStatuses = z.infer<typeof StatusesDomainSchema>
+export type OrganizationModelStatusEntry = z.infer<typeof StatusEntrySchema>
+export type OrganizationModelStatusSemanticClass = z.infer<typeof StatusSemanticClassSchema>
+export type OrganizationModelOperations = z.infer<typeof OperationsDomainSchema>
+export type OrganizationModelOperationEntry = z.infer<typeof OperationEntrySchema>
+export type OrganizationModelOperationSemanticClass = z.infer<typeof OperationSemanticClassSchema>
+export type OrganizationModelCustomers = z.infer<typeof CustomersDomainSchema>
+export type OrganizationModelCustomerSegment = z.infer<typeof CustomerSegmentSchema>
+export type OrganizationModelCustomerFirmographics = z.infer<typeof FirmographicsSchema>
+export type OrganizationModelOfferings = z.infer<typeof OfferingsDomainSchema>
+export type OrganizationModelProduct = z.infer<typeof ProductSchema>
+export type OrganizationModelPricingModel = z.infer<typeof PricingModelSchema>
+export type OrganizationModelRoles = z.infer<typeof RolesDomainSchema>
+export type OrganizationModelRole = z.infer<typeof RoleSchema>
+export type OrganizationModelGoals = z.infer<typeof GoalsDomainSchema>
+export type OrganizationModelObjective = z.infer<typeof ObjectiveSchema>
+export type OrganizationModelKeyResult = z.infer<typeof KeyResultSchema>
 
 export type DeepPartial<T> =
   T extends Array<infer U> ? Array<DeepPartial<U>> : T extends object ? { [K in keyof T]?: DeepPartial<T[K]> } : T

package/src/platform/constants/versions.ts

@@ -1,3 +1,3 @@
 export const VERSION = {
-  CURRENT: '1.6.1'
+  CURRENT: '1.6.3'
 }

package/src/platform/registry/types.ts

@@ -119,7 +119,7 @@ export interface ResourceList {
 // ============================================================================
 
 /** Webhook provider identifiers */
-export type WebhookProviderType = 'cal-com' | 'stripe' | 'signature-api' | 'instantly' | 'apify'
+export type WebhookProviderType = 'cal-com' | 'stripe' | 'signature-api' | 'instantly' | 'apify' | 'test'
 
 /** Webhook trigger configuration */
 export interface WebhookTriggerConfig {

package/src/projects/api-schemas.ts

@@ -132,6 +132,7 @@ export const UpdateMilestoneRequestSchema = z
     due_date: z.string().nullable().optional(),
     completed_at: z.string().nullable().optional(),
     sequence: z.number().int().min(0).optional(),
+    checklist: ChecklistSchema.optional(),
     metadata: z.record(z.string(), z.unknown()).nullable().optional()
   })
   .strict()