--- id: AREA-PFM title: Platform product_area: platform revision: 1 status: draft product_intent: proposed source_sha: rhythm-v2-docs: cd10cc78ca5b27f476de773abc747115fed86231 modules: - MOD-PFM-SEC - MOD-PFM-CSH - MOD-PFM-MTD - MOD-PFM-QRY - MOD-PFM-INT - MOD-PFM-ELG - MOD-PFM-NOT - MOD-PFM-OPS - MOD-PFM-DJE - MOD-PFM-LLM - MOD-PFM-TNL owns: - 'Customer and workspace administration, identity, scoped access and staff entry.' - Shared console navigation and presentation of working context. - 'Shared record descriptions, customer configuration and custom records.' - 'Shared questions, qualification, accountability, attention and communication services.' - 'Provider connections, customization contracts and shared automation configuration.' - 'Durable work, bulk processing, application availability, AI usage and workspace lifecycle coordination.' does_not_own: - Application business records and their ordinary validation remain with the owning application modules. - >- Financial books, purchasing, membership, committee decisions, submissions, website content and marketing campaigns remain with their product areas. - >- Provider-specific behavior remains with integration adapters; application hosts retain workflow execution records. handoffs: - to: Application record owners what: >- Record descriptions, authorized reads, events, lifecycle participation and bulk-operation implementations. - to: Accounting and Billing what: 'Financial working context, commercial inputs and application-owned documents.' - to: Websites and Submissions what: 'Portal identity and scoped access, shared qualification and application declarations.' - to: Marketing what: Published communication content and authorized recipient requests. - to: Integration adapters and external providers what: 'Selected capabilities, protected credentials, outbound requests and verified feedback.' invariants: - >- The product should keep each shared fact with one owning module and make consumers use that owner’s contract. - 'The product should preserve workspace boundaries across interactive, background and external work.' - >- The product should keep customer authority distinct from Rhythm staff authority and require recorded clearance for staff entry. - The product should preserve application ownership when shared engines process business records. - >- The product should make failure, recovery and incomplete implementation visible without implying that admission proves completion. - >- The product should keep application decisions and permission checks authoritative when a model supplies an answer. provenance: documented source: 'rhythm-v2-docs:specs/PRODUCT-AREAS.md#Module Registry' evidence: - 'rhythm-v2-docs:specs/PRODUCT-AREAS.md#Platform' - 'rhythm-v2-docs:specs/platform/ACTORS.md' - 'rhythm-v2-docs:specs/platform/RESPONSIBILITIES.md' - 'rhythm-v2-docs:specs/platform/security/MODULE.md' - 'rhythm-v2-docs:specs/platform/console-shell/MODULE.md' - 'rhythm-v2-docs:specs/platform/metadata/MODULE.md' - 'rhythm-v2-docs:specs/platform/queries/MODULE.md' - 'rhythm-v2-docs:specs/platform/integrations/MODULE.md' - 'rhythm-v2-docs:specs/platform/eligibility/MODULE.md' - 'rhythm-v2-docs:specs/platform/notifications/MODULE.md' - 'rhythm-v2-docs:specs/platform/operations/MODULE.md' - 'rhythm-v2-docs:specs/platform/data-job-engine/MODULE.md' - 'rhythm-v2-docs:specs/platform/llm/MODULE.md' - 'rhythm-v2-docs:specs/platform/tenant-lifecycle/MODULE.md' narrative_sources: - section: Purpose and Outcomes provenance: documented source: 'rhythm-v2-docs:specs/platform/ACTORS.md; specs/platform/RESPONSIBILITIES.md' - section: Scope and Boundaries provenance: documented source: - 'rhythm-v2-docs:specs/platform/security/MODULE.md#Boundary' - 'rhythm-v2-docs:specs/platform/console-shell/MODULE.md#Boundary' - 'rhythm-v2-docs:specs/platform/metadata/MODULE.md#Boundary' - 'rhythm-v2-docs:specs/platform/queries/MODULE.md#Boundary' - 'rhythm-v2-docs:specs/platform/integrations/MODULE.md#Boundary' - 'rhythm-v2-docs:specs/platform/eligibility/MODULE.md#Boundary' - 'rhythm-v2-docs:specs/platform/notifications/MODULE.md#Boundary' - 'rhythm-v2-docs:specs/platform/operations/MODULE.md#Boundary' - 'rhythm-v2-docs:specs/platform/data-job-engine/MODULE.md#Boundary' - 'rhythm-v2-docs:specs/platform/llm/MODULE.md#Boundary' - 'rhythm-v2-docs:specs/platform/tenant-lifecycle/MODULE.md#Boundary' - section: How the Area Is Divided provenance: documented source: - 'rhythm-v2-docs:specs/platform/security/MODULE.md#Purpose' - 'rhythm-v2-docs:specs/platform/console-shell/MODULE.md#Purpose' - 'rhythm-v2-docs:specs/platform/metadata/MODULE.md#Purpose' - 'rhythm-v2-docs:specs/platform/queries/MODULE.md#Purpose' - 'rhythm-v2-docs:specs/platform/integrations/MODULE.md#Purpose' - 'rhythm-v2-docs:specs/platform/eligibility/MODULE.md#Purpose' - 'rhythm-v2-docs:specs/platform/notifications/MODULE.md#Purpose' - 'rhythm-v2-docs:specs/platform/operations/MODULE.md#Purpose' - 'rhythm-v2-docs:specs/platform/data-job-engine/MODULE.md#Purpose' - 'rhythm-v2-docs:specs/platform/llm/MODULE.md#Purpose' - 'rhythm-v2-docs:specs/platform/tenant-lifecycle/MODULE.md#Purpose' - section: Area-Level Invariants provenance: inferred source: 'rhythm-v2-docs:specs/platform/RESPONSIBILITIES.md' note: >- Proposed common obligations follow the documented ownership boundaries; control findings prevent a claim of universal implementation. - section: Open Ownership Questions provenance: unknown source: - FND-PFM-TNL-036 - FND-PFM-CSH-037 - FND-PFM-MTD-055 - OQ-PFM-LLM-003 - OQ-PFM-TNL-001 - OQ-PFM-DJE-004 --- # Platform ## Purpose and Outcomes Platform gives customers a shared foundation for working across Rhythm’s applications. People enter under their own identities, work in an explicit workspace and see the destinations their access permits. Administrators shape local information and presentation, assign responsibilities and control how colleagues and Rhythm staff reach customer work. Support staff use a separate administrative context to investigate problems and coordinate customer environments. Application teams use the same foundation to describe records, expose authorized information, connect providers and coordinate work that spans more than one service. Shared questions and qualification help people interpret information; attention and communications bring relevant work to its audience. Background execution and bulk processing retain progress and outcomes so interrupted work can be investigated. Workspace coordination connects application preparation, initial loading and deliberate removal. AI services account for model work while consuming features retain responsibility for interpreting answers. The intended outcome is a coherent working environment in which customers can understand their access, adapt shared tools and follow the results of administrative or automated work. This overview describes the area’s responsibilities and proposed common obligations. The module specifications and findings distinguish implemented behavior, recorded product decisions and unfinished work. ## Scope and Boundaries Platform owns shared identity, access, configuration and coordination records, together with the common console frame. It also owns the reusable services for questions, qualification, attention, delivery, provider connections, durable execution and AI accounting. Application modules own their business records and their validation. They provide declarations, source events, bulk implementations and lifecycle participants to shared services. Accounting supplies financial context and application-owned documents; Marketing supplies campaign content and consent decisions; Websites and Submissions retain their portal experiences and domain outcomes. Integration adapters retain provider-specific behavior, and application hosts retain their workflow execution records. A hosted page stays with the module responsible for its records. Shared execution does not transfer record ownership, and a shared access answer does not transfer responsibility for an application’s narrower record checks. ## How the Area Is Divided **Security, Customers and Workspaces** explains who enters Rhythm, which customer or workspace they reach and how authority is administered. Open it for identity, sessions, access definitions, memberships, staff entry and ordinary customer administration. **Console Shell and Navigation** explains the common working frame and how people reach destinations in an explicit context. Open it for workspace entry, navigation, address handling and the presentation of unavailable applications. **Metadata and Organization-defined Records** explains shared record descriptions and customer-defined information. Open it for configuration ownership, forms and layouts, custom registers, record relationships and attachment staging. **Queries, Explorer, Search, Snapshots and Exports** explains shared ways to find, interpret and deliver authorized information. Open it for reusable questions, record exploration, reports, search and the boundary between query files and whole-workspace packages. **Integrations, Extensions and Workflow Actions** explains connections to providers and the contracts applications expose for customer customization. Open it for provider accounts, gateway work, extension configuration and shared automation definitions. **Eligibility, Responsibilities and Attention** explains shared qualification and the assignment of work to an appropriate audience. Open it for reusable conditions, consumer decisions, responsibility coverage and attention records. **Notifications and Communications** explains delivery of staff notices and association messages. Open it for recipient delivery, preferences, published message content, sender protection and provider outcomes. **Jobs, Audit and Licensing** explains the shared record of background work, record activity and application availability. Open it for operational recovery, shared activity history and commercial or staff availability decisions. **Data Job Engine** explains shared bulk processing, input transfers and migration coordination. Open it for execution contracts, job evidence, producer mappings, capacity protection and the applications that adopt the engine. **LLM and the AI Teammate** explains model execution, usage accounting and the Jazz AI experience. Open it for AI admission, allowances, diagnostic evidence and the limits of the current prototype. **Workspace Lifecycle Across Applications** explains coordinated preparation, initial loading, reset and removal. Open it for participant responsibilities, readiness, lifecycle recovery and retained deletion evidence. ## Area-Level Invariants The product should give each shared fact one owner and require consumers to use its contract. Workspace boundaries should hold through interactive work, background execution and external delivery. Customer administration and Rhythm staff authority should remain distinct, with recorded clearance for staff entry. Application owners should retain domain decisions when shared engines process their records. Failed or unfinished coordination should remain visible with an explicit recovery boundary. A model answer should pass the consuming feature’s validation and approval requirements before it changes product state. These are proposed obligations across the area. Their control assignments identify applicability; findings retain known implementation gaps. ## Open Ownership Questions Security and workspace lifecycle currently describe overlapping lifecycle contracts. Product still needs to settle their final division and remove the duplicate specification homes. The administrator’s Applications overview has a provisional home in Console Shell even though Operations owns its availability answer. Metadata’s charter also names shared Operations for work assigned to the Data Job Engine. These ownership records need a consistent home at their next authorized revision. Partition maintenance remains provisionally assigned to the Data Job Engine. Durable Jazz AI conversation ownership and the boundary required before customer use remain open. The lifecycle module’s console-source boundary also leaves its screen ownership and implementation unverified.