Federated from workspace ·
PRD-001·Dental Clinic Revenue Operating System/docs/architecture/BUSINESS_CAPABILITY_MAP.mdDo not edit canonical truth here — update the source repo, then re-runnpm run docs:sync.
Business Capability Map
Status: Canonical capability reference — documentation only
Baseline: v3.12-tracking-platform
Last updated: 2026-06-27
Authority: PRODUCT_VISION_AND_STRATEGY.md, MODULE_BOUNDARIES.md, LONG_TERM_ROADMAP.md
Document Role
This document defines every reusable capability of the Universal Business Platform independently from any specific business domain. It is the canonical reference for:
- What capabilities exist
- How they relate
- Which are platform capabilities vs product capabilities
- Which are reusable across future products
- How AI workers consume them
This is not an implementation specification. It authorizes no implementation. For module boundaries and public contracts, see MODULE_BOUNDARIES.md. For product vision, see PRODUCT_VISION_AND_STRATEGY.md.
Architectural Layers
All capabilities exist within one of three layers. Dependency direction is always downward — products consume domain modules; domain modules consume platform capabilities via contracts; platform capabilities consume lower platform capabilities via contracts.
┌─────────────────────────────────────────────────────────┐
│ Business Product │
│ Brand, packaging, vertical UX, product-specific AI │
│ workers, go-to-market, entitlement tiers │
│ Example: Dental Clinic Revenue Operating System │
└───────────────────────────┬─────────────────────────────┘
│ configures & presents
┌───────────────────────────▼─────────────────────────────┐
│ Domain Modules │
│ Industry entities, workflows, billing rules, charts │
│ Example: CRM (dental), Leads, Clinic, Finance │
└───────────────────────────┬─────────────────────────────┘
│ consumes via public contracts only
┌───────────────────────────▼─────────────────────────────┐
│ Universal Business Platform │
│ Frozen platforms: AI, Analytics, Workflow, Growth, │
│ Compliance, Marketing, Tracking, SaaS, Observability… │
└─────────────────────────────────────────────────────────┘Layer responsibilities
| Layer | Owns | Does not own |
|---|---|---|
| Business Product | Product name, vertical terminology, staff/public experience packaging, product-specific worker personas, SaaS tier packaging, onboarding journeys | Platform contract semantics, provider SDKs, cross-tenant infrastructure |
| Domain Modules | Domain entities, write Actions, business policies, vertical workflows, domain public query/command contracts | Platform registries, preview engines, AI provider routing, frozen platform internals |
| Universal Business Platform | Contract-first capabilities, registries, preview-safe engines, entitlements, observability, AI runtime foundations | Industry-specific clinical charts, vertical billing rules, product branding |
1. Purpose
Why capability mapping exists
Modules, Filament resources, and code folders change as implementation evolves. Capabilities describe what the system can do for the business in stable, product-facing language. Capability mapping:
- Gives Product, UX, and AI teams a shared vocabulary independent of PHP namespaces
- Makes reuse across future business products explicit and auditable
- Shows AI workers which capabilities they may compose without referencing internal implementations
- Separates frozen platform truth from replaceable domain logic
Why capabilities are more stable than modules
| Module artifact | Stability | Capability |
|---|---|---|
| Class names, file paths | Change during refactors | Capability name persists |
| Internal services | Forbidden to external consumers | Capability accessed via contract |
| Legacy parallel runtimes | May coexist during migration | Capability has one authoritative platform path |
| Product branding | Per vertical | Capability definition is vertical-agnostic |
A capability such as Attribution Preview remains stable whether implemented in Tracking Platform v3.12 or consumed by Marketing AI in a future phase. Modules implement capabilities; products consume capabilities.
Why products consume capabilities instead of internal implementations
Under ANPA and module boundary rules:
- Products and AI workers import contracts only — never registries, engines, or Infrastructure models
- Capabilities are the unit of composition — Sales AI consumes Marketing Preview capability, not
MarketingPlatformServiceinternals - Frozen platforms are integration boundaries — bypassing a capability breaks freeze policy and audit guarantees
- Future products swap domain modules while reusing the same capability catalog
Products ask "what can the platform do?" Domain modules ask "what does this industry do?" Platforms answer "here is the contract."
2. Capability Categories
Capabilities are grouped by category. Categories are organizational — not module boundaries. A single frozen platform may own multiple capabilities.
2.1 AI Capabilities
| Capability | Description | Maturity |
|---|---|---|
| Conversation | Multi-turn dialogue, message history, locale-aware sessions | AI Platform + future Clinic AI |
| Planning | Tool planning, action planning, task plans, execution plans | Assistant v3.3, Agent v3.4 |
| Tool Execution | Contract-bound tool dispatch with preview and approved execute | AI Runtime v2.1 + future Clinic AI |
| Approval Workflow | Human-in-the-loop gates for write operations | Product vision + future Clinic AI |
| Memory | Session and role-aware context retention | AI Runtime v2.1 |
| Recommendations | Deterministic next-action and platform recommendations | Tracking, Marketing, Growth, OI platforms |
| Reporting | Natural language report narrative over contract-backed metrics | Product vision + Analytics |
| Provider Selection | Automatic routing across LLM/media/speech providers | Future AI Capability Ecosystem |
| AI Composition | Multi-capability chains (copy → image → video → validate) | Future Digital Workforce |
| Embeddings & Retrieval | Vector search, RAG, clinic-scoped knowledge | AI Runtime v2.1 |
| Agent Orchestration | Multi-agent coordination, handoff, collaboration preview | Agent v3.4 |
| Mission Runtime | Long-running mission scheduling, state, recovery | Mission v3.5 |
| Copilot Briefings | Role-based executive/clinic/finance briefings | Assistant v3.3 |
2.2 Business Capabilities
Business capabilities combine domain modules (writes and domain rules) with business platform layers (preview intelligence).
| Capability | Domain module | Business platform | Primary contract surface |
|---|---|---|---|
| CRM | Patients, appointments, clinical workflows | — | CRM Actions, read query ports |
| Scheduling | Appointments, calendar | Workflow availability | CRM Actions |
| Billing / Revenue | Invoices, payments, credit notes, refunds | Finance integrity | FinancialQueryContract |
| Leads | Capture, qualification, conversion | — | LeadQueryServiceContract, LeadCommandServiceContract |
| Marketing | Legacy campaign execution | Marketing Platform previews | MarketingPlatformContract |
| Growth | Legacy growth actions | Growth Platform scoring | GrowthPlatformContract |
| Tracking | Legacy event persistence | Tracking Platform taxonomy | TrackingPlatformContract |
| Compliance | Violation logging, audit | Compliance Platform scans | CompliancePlatformContract |
| Analytics | Metric providers | KPI, trend, benchmark | AnalyticsPlatformContract, AnalyticsAdvancedReadQueryContract |
| Operational Intelligence | — | Health scores, insights | OperationalIntelligenceContract |
| Clinic Configuration | Settings, hours, services | — | ClinicQueryServiceContract |
| Public Website | Template content | — | ClinicTemplateViewService |
2.3 Platform Capabilities
Infrastructure and cross-cutting capabilities — domain independent.
| Capability | Owner platform | Freeze reference |
|---|---|---|
| Workflow | Workflow Platform | v2.7 / v2.8 designer |
| Notifications | Notification Platform | v2.4 |
| Realtime / Presence | Realtime Platform | v2.6 |
| Permissions | Shared + Product layer RBAC | v1.4 + Shared |
| Localization | Shared + locale config | Shared |
| SaaS / Entitlements | Entitlements | v1.6 |
| Multi-tenancy | Shared clinic scoping + Saas | Shared + v1.3–v1.6 |
| Observability | Observability Platform | v3.7 |
| Production Hardening | Production Platform | v3.8 |
| Deployment / Configuration | Deployment Platform | v3.6 |
| Storage | Laravel + module Infrastructure | Per module |
| Search | Search Platform | v2.5 |
| Workspace | Workspace Platform | v2.3 |
| Integrations | Integrations Platform | v1.8 |
| Marketplace Connectors | Connector Marketplace | v1.9 |
| Public API | Public API | v1.7 |
| Billing (SaaS) | Billing Platform | v1.3 |
| Autonomous Operations | Autonomous Operations | v3.2 |
2.4 User Experience Capabilities
Presentation capabilities — no business logic; consume platform contracts.
| Capability | Description | Maturity |
|---|---|---|
| Structured Responses | Typed AI payloads: headline, narrative, alerts, metrics | Product vision + legacy assistant DTOs |
| Navigation Cards | Deep links to Filament resources with context | Product vision |
| Action Cards | Proposed actions with risk tier and approval | Product vision |
| Preview Screens | Preview-before-execute UI for tools and platform previews | ANPA standard |
| Dashboards | Read-only platform and domain dashboards | Frozen platform pages |
| Design System | Tokens, components, platform navigation patterns | Future Platform UX |
| Public Experience | Unified public site, hero AI placement | Future Public Experience Platform |
3. Capability Ownership
For each capability: owner (who defines and governs it), consumers, reusable across future products, domain independent (yes/no).
AI capabilities
| Capability | Owner Platform | Consumers | Reusable | Domain Independent |
|---|---|---|---|---|
| Conversation | AI Platform → future Clinic AI | All AI workers, Filament, Livewire | Yes | Yes |
| Planning | Assistant, Agent | Clinic AI, Digital Workforce | Yes | Yes |
| Tool Execution | AI Runtime → future Clinic AI | All AI workers | Yes | Yes |
| Approval Workflow | Future Clinic AI (product pattern) | All staff-facing AI workers | Yes | Yes |
| Memory | AI Runtime | All AI workers | Yes | Yes |
| Recommendations | Tracking, Marketing, Growth, OI | AI workers, dashboards | Yes | Yes |
| Reporting (AI narrative) | Product layer + Analytics | Clinic AI, managers, owners | Yes | Yes |
| Provider Selection | Future AI Capability Ecosystem | All AI workers | Yes | Yes |
| AI Composition | Future Digital Workforce | Sales AI, Clinic AI, Support AI | Yes | Yes |
| Embeddings & Retrieval | AI Runtime | All AI workers | Yes | Yes |
| Agent Orchestration | Agent Platform | Digital Workforce, Clinic AI | Yes | Yes |
| Mission Runtime | Mission Platform | Digital Workforce | Yes | Yes |
| Copilot Briefings | Assistant Platform | Filament, future Clinic AI | Yes | Yes |
Business capabilities
| Capability | Owner Platform | Consumers | Reusable | Domain Independent |
|---|---|---|---|---|
| CRM | CRM domain module | All products, AI workers, Workspace | Configure | No — domain module replaced per vertical |
| Scheduling | CRM domain module | Reception AI, Support AI, Workflow | Configure | No |
| Billing / Revenue | CRM Finance (frozen) | Finance AI, Clinic AI, reports | Configure | No — rules per vertical |
| Leads | Leads domain module | Sales AI, Growth, Marketing | Yes | Mostly — lead model adapts |
| Marketing intelligence | Marketing Platform | Sales AI, Clinic AI, Marketing staff | Yes | Yes |
| Growth intelligence | Growth Platform | Sales AI, Clinic AI, owners | Yes | Yes |
| Tracking intelligence | Tracking Platform | Marketing AI, Sales AI, Growth | Yes | Yes |
| Compliance intelligence | Compliance Platform | All AI workers, marketing staff | Yes | Yes — rule packs vary |
| Analytics | Analytics Platform | All dashboards, AI workers, reports | Yes | Yes |
| Operational Intelligence | OI Platform | Clinic AI, Assistant, Agent | Yes | Yes |
| Clinic Configuration | Clinic domain module | Onboarding AI, admin | Configure | No |
| Public Website | ClinicTemplateSystem | Sales AI, Public Experience | Configure | No |
Platform capabilities
| Capability | Owner Platform | Consumers | Reusable | Domain Independent |
|---|---|---|---|---|
| Workflow | Workflow Platform | All products, Mission, AI workers | Yes | Yes |
| Notifications | Notification Platform | All products, Workflow | Yes | Yes |
| Realtime | Realtime Platform | Assistant, Agent, reception UX | Yes | Yes |
| Permissions | Shared + Product | All layers | Yes | Yes |
| Localization | Shared + product config | All UX, AI workers | Yes | Yes |
| SaaS / Entitlements | Entitlements | All products, AI quota | Yes | Yes |
| Multi-tenancy | Shared + Saas | All products | Yes | Yes |
| Observability | Observability Platform | All platforms, audit, AI | Yes | Yes |
| Production | Production Platform | All platforms, AI gates | Yes | Yes |
| Deployment | Deployment Platform | Ops, feature flags | Yes | Yes |
| Search | Search Platform | Workspace, CRM UI | Yes | Yes |
| Workspace | Workspace Platform | Admin hub, notifications | Yes | Yes |
| Integrations | Integrations Platform | Marketplace, connectors | Yes | Yes |
| Public API | Public API | External systems, mobile (future) | Yes | Yes |
| Billing (SaaS) | Billing Platform | Product layer, entitlements | Yes | Yes |
| Autonomous Operations | Autonomous Operations | Assistant, Agent, OI | Yes | Yes |
User experience capabilities
| Capability | Owner Platform | Consumers | Reusable | Domain Independent |
|---|---|---|---|---|
| Structured Responses | Future Platform UX + Clinic AI | All AI surfaces | Yes | Yes |
| Navigation Cards | Future Platform UX + Clinic AI | All AI workers | Yes | Yes |
| Action Cards | Future Platform UX + Clinic AI | All AI workers | Yes | Yes |
| Preview Screens | ANPA pattern (all preview platforms) | Filament, AI, public site | Yes | Yes |
| Dashboards | Per frozen platform + domain | Staff, admins | Yes | Mostly |
| Design System | Future Platform UX | All Filament/Blade | Yes | Yes |
| Public Experience | Future Public Experience Platform | Sales AI, website | Configure | Mostly |
4. Capability Dependencies
Dependencies flow downward — higher capabilities consume lower capabilities via public contracts only. No upward or lateral internal imports.
Reporting stack
Intelligent Reporting (product capability)
↓
Analytics / Advanced Analytics
↓
Operational Intelligence
↓
Metric Data Providers (domain + platform events)
↓
Tracking Platform (behavioral taxonomy)
↓
Marketing Platform (channel context)
↓
Growth Platform (demand context)
↓
CRM / Leads (operational records)Direction: Reports consume analytics; analytics consumes metrics; metrics may be enriched by tracking and domain reads. AI narrates reports; it does not replace the query chain.
AI worker stack
AI Worker (Sales AI, Clinic AI, Support AI)
↓
Assistant / Agent / Mission (orchestration layers)
↓
AI Platform / AI Runtime (execution)
↓
Platform Contracts (Layer 1 live truth)
↓
Domain Query Contracts (CRM, Leads, Clinic, Finance reads)
↓
Entitlements + Production (gates)
↓
Observability (audit)Direction: AI workers never skip to domain Infrastructure. They traverse platform and domain contracts.
Marketing intelligence stack
Marketing Platform previews
↓
Compliance Platform (content validation context)
↓
Growth Platform (demand context)
↓
Tracking Platform (attribution/journey context)
↓
Leads (pipeline reads)
↓
Analytics (performance metrics)Compliance stack
Compliance Platform previews
↓
Growth Platform (validation context)
↓
Analytics + OI (signal enrichment)
↓
Observability (audit event types)Dependency rules (canonical)
| Rule | Meaning |
|---|---|
| Contract-only edges | Capability A → Capability B only through B's public contract |
| No registry imports | Consumers reference capability keys in config — not registry classes |
| Preview before mutate | Intelligence platforms preview; domain Actions mutate |
| AI consumes down | AI workers depend on platforms below them — never the reverse |
| Product configures | Business Product selects which capabilities are entitled — does not implement them |
5. Capability Lifecycle
Capabilities evolve through a governed lifecycle. Not every capability reaches every stage.
Idea
↓
Capability (named, categorized, ownership assigned)
↓
Platform (contract-first implementation, registries, engines, freeze)
↓
Product (entitlement packaging, UX presentation, vertical config)
↓
AI Worker (worker consumes capability via contract + tools)
↓
User Experience (structured responses, cards, dashboards, public surfaces)
↓
Marketplace (connectors, vertical packs, third-party extensions)| Stage | Governance | Example |
|---|---|---|
| Idea | Product/architecture discovery — no code | "AI-generated promotional video in campaigns" |
| Capability | Documented in this map; owner assigned | Video Generation capability (AI category) |
| Platform | Architecture spec → implementation → freeze | Tracking Platform v3.12 |
| Product | Entitlement tier, Filament/Blade presentation | Tracking dashboard in dental product |
| AI Worker | Worker tool binds to platform contract | Clinic AI calls previewJourney() |
| User Experience | Design system components render capability output | Journey preview card in Clinic AI panel |
| Marketplace | External connector or vertical pack distributes capability | Partner attribution connector |
Capabilities may enter at Platform (skipping Idea in repo history for mature domains) or remain at Capability indefinitely (vision-only until phase approval).
6. Capability Reuse Matrix
Legend:
| Symbol | Meaning |
|---|---|
| R | Reuse unchanged — same frozen platform capability |
| C | Configure — registry keys, entitlements, worker tools, rule packs |
| E | Extend — additive domain module on same platform |
| X | Replace — new domain module for vertical |
Strategic examples only — not committed products.
| Capability | Dental | Dermatology | Veterinary | Beauty | Warehouse | ERP | Retail | Hospitality | Laboratory | Field Service | Medical Clinic |
|---|---|---|---|---|---|---|---|---|---|---|---|
| AI Platform | R | R | R | R | R | R | R | R | R | R | R |
| Workflow | R | R | R | R | R | R | R | R | R | R | R |
| Analytics | R | R | R | R | R | R | R | R | R | R | R |
| Observability | R | R | R | R | R | R | R | R | R | R | R |
| Entitlements / SaaS | R | R | R | R | R | R | R | R | R | R | R |
| Marketing Platform | R | C | C | R | C | C | R | R | C | C | C |
| Tracking Platform | R | C | C | R | C | C | R | R | C | R | C |
| Growth Platform | R | C | C | R | C | R | R | R | C | C | C |
| Compliance Platform | R | C | C | C | C | C | C | C | R | C | C |
| CRM domain | R | X | X | C | X | E | C | C | X | X | X |
| Billing / Finance | R | C | C | C | C | E | C | C | C | C | C |
| Clinic AI patterns | R | C | C | C | C | C | C | C | C | C | C |
| Scheduling | R | C | C | C | — | E | — | R | C | R | R |
| Public website | R | C | C | C | — | C | C | R | C | — | C |
| Inventory domain | — | — | — | — | X | E | X | C | X | C | — |
| Design System | R | R | R | R | R | R | R | R | R | R | R |
| Digital Workforce | R | R | R | R | R | R | R | R | R | R | R |
Pattern: Platform rows are R. Domain rows are X, C, or E. Dental is the reference product; all others adapt domain modules while reusing frozen platforms.
7. AI Consumption Map
AI workers are capability composers. They consume capabilities only through platform and domain contracts.
Sales AI (future)
Sales AI Worker
↓
Marketing Platform (campaign/strategy previews)
↓
Tracking Platform (journey/attribution previews)
↓
Growth Platform (opportunity/demand previews)
↓
Leads (pipeline reads, lead creation commands — approved)
↓
Compliance Platform (content scan before outbound)
↓
Clinic / Public Experience (services, pricing context)
↓
Reports (prospect funnel, conversion narrative)
↓
Entitlements (plan recommendation, quota)Customer Support AI (future)
Support AI Worker
↓
CRM (appointment reads — scoped)
↓
Scheduling (availability previews)
↓
Clinic Configuration (hours, contact)
↓
Compliance Platform (patient communication rules)
↓
Realtime (escalation/presence — optional)
↓
Workflow (escalation definitions — read)Clinic AI (future)
Clinic AI Worker
↓
Financial Query (revenue, unpaid — permission gated)
↓
CRM (appointments, patients, treatment — role gated)
↓
Growth Platform (opportunity previews)
↓
Marketing Platform (campaign previews)
↓
Tracking Platform (conversion/journey previews)
↓
Compliance Platform (content/advertising previews)
↓
Operational Intelligence (health, insights)
↓
Analytics (trends, benchmarks)
↓
Workflow + Realtime (operations context)
↓
Reports (executive, financial, operational)
↓
Approval Workflow (writes)
↓
Observability (audit)Digital Workforce (future)
Digital Workforce Platform
↓
All AI workers (Sales, Support, Clinic, Onboarding, Compliance Advisor…)
↓
Agent + Mission + Assistant (orchestration)
↓
AI Capability Ecosystem (provider routing)
↓
All Platform Contracts (Layer 1)
↓
Entitlements + Production (gates)
↓
Observability (unified audit)Consumption rules for AI
| Rule | Description |
|---|---|
| Layer 1 first | Live state from platform/domain contracts before retrieval or LLM |
| Preview default | Intelligence and tool calls preview unless approval granted |
| Permission filter | Every capability check runs before response composition |
| No upward dependency | Platforms do not call AI workers |
| Structured output | All worker responses map to UX capabilities (cards, blocks, bands) |
8. Capability Stability Levels
Capabilities are classified by change governance. Stability level determines who may propose changes and what process applies.
| Level | Name | Definition | Governance | Examples |
|---|---|---|---|---|
| A | Frozen forever | Immutable integration boundary; additive DTO fields only via governed phases | Freeze policy; architecture review; zero-byte diff vs prior tag | Finance v1.0, Tracking v3.12, AI Platform v2.0 |
| B | Rare changes | Frozen platform; patch phases only for hardening | Phase workflow + freeze | Growth, Compliance, Marketing, Production |
| C | Configurable | Behavior driven by registries and config — not code changes | Registry validation; config review | Worker tools, attribution policies, entitlement tiers |
| D | Domain specific | Per-vertical domain module — replaced or extended per product | Domain module ownership; not frozen as platform | Dental chart, treatment plans, tooth notation |
| E | Experimental | Vision or legacy parallel — not canonical capability path | Discovery only; no production dependency | Legacy ClinicAssistantService, vision-only AI Capability Ecosystem registries |
Governance by level
| Level | Product may | Architecture may | Implementation |
|---|---|---|---|
| A | Consume via contract | Additive phase with new tag | Forbidden without phase |
| B | Consume via contract | Hardening phase | Governed phase only |
| C | Configure via admin/config | Extend registry schema via phase | Registry + config |
| D | Replace per vertical product | Spec new domain module | Per product phase |
| E | Must not depend for truth | Promote to C/B via discovery | Not authorized |
When this map conflicts with a frozen release record, the release record wins.
9. Future Expansion
New capabilities are added without modifying frozen platforms — only through additive phases.
| Expansion type | Path | Frozen platform impact |
|---|---|---|
| New AI capability | AI Capability Ecosystem phase; new capability category in registries | None — additive module/config |
| New business capability | New domain module + optional business platform layer | None — new module |
| New provider | AI Provider Registry (future); AI Platform provider slot | None — AI module additive |
| New report | Analytics metric provider + product report template | None — additive providers |
| New product | New domain modules + product config on same platforms | None |
| New vertical | Domain Adaptation Strategy (PRODUCT_VISION §17) | None |
| Marketplace extension | Connector Marketplace; Integrations platform | None — v1.9 pattern |
Expansion checklist (mandatory)
- Name capability in this map (or amend via documentation PR)
- Assign category, owner, stability level target
- Architecture discovery → specification → implementation → review → hardening → freeze (if platform)
- Update MODULE_BOUNDARIES only at freeze — not during discovery
- AI workers bind via new contract methods or existing contract composition — not internal imports
10. Strategic Principles
These principles govern capability decisions across all current and future products on the Universal Business Platform.
| Principle | Capability meaning |
|---|---|
| Capability First | Name and document what the system does before where code lives |
| Contract First | Every capability exposes a stable public contract for humans and AI |
| Configuration over Customization | Prefer registry/config changes over forked implementations |
| Composition over Duplication | Workers compose existing capabilities — do not reimplement analytics or compliance |
| Platform before Product | Platform capabilities exist before product packaging |
| Reuse before Rewrite | Future products replace domain modules — not frozen platforms |
| AI consumes Capabilities | AI workers are consumers — not owners — of business truth |
| Preview before Execute | Preview capability invoked before any mutate capability |
| Human Approval | Write capabilities require approval proportional to risk |
| Provider Agnostic | AI execution capabilities route across vendors — no single-provider dependency |
| Universal Business Platform | One capability catalog serves dental today and adjacent verticals tomorrow |
Related Documentation
| Document | Relationship |
|---|---|
| MODULE_BOUNDARIES.md | Authoritative public contracts and freeze tags per platform |
| PRODUCT_VISION_AND_STRATEGY.md | Product vision, Universal Business Platform, AI ecosystem |
| AI_NATIVE_PLATFORM_ARCHITECTURE.md | ANPA methodology, three-layer knowledge model |
| LONG_TERM_ROADMAP.md | Platform phase sequence |
| phase-9a-clinic-ai-platform-specification.md | Clinic AI design authority (when approved) |
| docs/releases/v3.12-tracking-platform.md | Current frozen baseline |
Business Capability Map. Baseline v3.12-tracking-platform. Documentation only — no implementation authorized.