Platform Responsibilities

How the Product Area Is Divided

Platform supplies the shared foundation for application work. Its modules separate identity and workspace authority, console presentation, metadata, queries, integrations, attention, notifications, operational jobs, data jobs, inference and workspace lifecycle. This document records the console-shell and security divisions; other modules gain ownership rows when their design is authored.

Console Shell and Navigation

The shell owns four presentation designs: the common frame, navigation, console addresses and application-access presentation. It also specifies start-up and refusal states, workspace entry and switching, compatibility redirects and the read-only Applications overview. These client objects have no business tables, and the shell exposes no service operation.

Security supplies identity and authority. Metadata supplies customer record placements. Operations owns the licensing computation behind the workspace application answer. The consumed administrative read is documented here provisionally, with its eventual home retained as an ownership finding. An in-browser refusal signal can request a fresh personal application list.

Production pages wait for an answered context, and workspace content waits for a matching selected workspace. Entry clears shared SWR data and remounts the keyed subtree. Switching removes record identities from the address. Application checks precede page-permission checks where the route or page guard classifies the application. Navigation filtering never replaces the service’s own authority.

Security, Customers and Workspaces

Security owns the three planning objects: Customer, Workspace and User Account. The account design retains separate membership, definition, assignment and staff-grant aggregates. Customers owns the organization record, Workspaces owns readiness and staff lifecycle intent, and the Security service owns identity and evaluated authority. Machine principals and Security events belong to the same module.

The operation and notification inventories agree with the three Service Contracts. The object invariants identify the guarantees and their enforcement limits; unknown concurrency and history protections remain findings. Fresh authority, gateway decisions, signed contexts, availability and external provider state have separate consistency bounds. None of the examined operations declares a Submissions binding or custom-field capability, and no module path invokes a model.

Metadata, Custom Fields, Layouts and Custom Objects

Metadata owns registered record descriptions, customer-defined fields and their rules, labels, forms, page layouts, custom applications and custom record types. It evaluates registered capabilities to determine which configuration operations are available. Record owners choose assignments for native records and store their field values; Metadata stores custom records, their relationships, change history and business-event ledger. Files provides upload staging, while custom-record saves attach prepared assets. Relationship deletion and merge functions allow native-record owners to apply link rules inside the caller's transaction.

Registration commits each manifest atomically and retains missing definitions, but overlapping manifest calls have no application-wide serialization guarantee. Custom-record persistence enforces active definitions, typed values and transactional history capture. Supported changes append business events in the same transaction; delivery and search updates complete later. Composite screen saves, external asset cleanup and routed delivery need their documented failure boundaries. No operation is published to Submissions. The record list consumes generated queries through Queries, which delegates model execution to the shared inference foundation.

Questions, Record Exploration and Data Delivery

Queries realizes the six planning concepts through query, Explorer, Quick Search, snapshot and workspace export services. It retains reusable definitions, derived results and execution history while source applications retain their business records. The ownership and exposed-operation rows identify the facet boundaries.

Person-requested queries and deliveries use the requester or schedule owner context; maintenance, search indexing, snapshot generation and staff validation use their dedicated execution boundaries. Queue consumers produce files and recurring deliveries, while durable jobs coordinate search rebuilds and snapshot attempts. Workspace package generation has no deployed runner, and its console integration remains defective.

Applications declare source vocabulary and processing interfaces. Metadata, Security, the LLM foundation, Communications, Integrations, Operations and workspace lifecycle each retain their delegated responsibilities. This module’s objects declare no custom fields, and its operations publish no Submissions bindings.

Integrations, Extensions and Workflow Actions

Six planning objects retain their numbers across three service boundaries. Integrations owns provider offers and installations, account links and credentials, capability execution and binding history, and message receipt and delivery. Extensions owns customization declarations, handlers, scoped bindings and invocation history. Workflow configuration owns reusable templates, calendars, automation and registry declarations; host applications retain their runtime records.

The operation inventory covers administration, provider invocation, adapter callbacks, incoming provider requests and deployment registration. Completion and interpreted provider events reach registered application consumers, while subscriptions send declared domain changes to adapters. Shared views expose host-owned runs and timers without transferring their ownership.

The invariant references identify each object’s guarantees and enforcement limits. External secret writes, repeated transport, reconciliation and material retained after workspace deletion remain explicit findings. The examined services do not publish intake bindings, enable custom fields or call a language model.

Staff Notifications and Association Communications

Notifications owns application declarations, staff request processing, personal notices and their channel history. Communications owns association content publication, recipient mail, provider outcomes and address protection. The three owned objects cover those separate records, including stored configuration for later notification channels.

The notification service exposes personal inbox operations, administrative history, authorized support reads and producer publication. The communication service exposes content authoring, sending requests, outcome inspection and suppression management. Its provider feedback is an external input; the work queues remain internal transport. Both services perform no model inference.

Business owners determine the communication trigger and source data. Security supplies identity and authority, Eligibility supplies responsibility audiences, Metadata supplies merge-field definitions, and Operations and workspace lifecycle supply shared execution. The contract and invariant rows retain the exact ownership boundaries and implementation limits, including incomplete recovery and audit behavior.

Eligibility, Responsibilities and Attention

Five domain designs describe rules and vocabulary, consumer uses, decisions and run records, accountability, and attention occurrences. Eligibility, Responsibilities and Attention are their three owning service modules within Platform.

Eligibility explains qualification and requests role refresh while Security maintains grants. Responsibilities resolves effective accountability without granting access. Attention stores provider conditions, resolves current audiences and maintains personal responses independently of occurrence lifecycle. Providers retain their business-record meaning and transactional source writes.

The operation inventory lists all seventy-two contracted routes. Mutation concurrency and history protections differ by path, so the object invariants state their actual limits. Post-commit work has partial scheduled repair, with no recovery for lost display history. The examined registrations enable no custom fields, publish no domain intake to Submissions and invoke no model.

Jobs, Audit and Licensing

Operations owns the common account of background work, workspace record activity, commercial licence standing and application readiness. The shared engine records execution history while each job owner supplies its domain tasks and recovery effects. Platform reconciles its own jobs on a five-minute schedule and combines published service views for customer, workspace and HQ monitoring. Requester messages record delivery outcomes without guaranteeing a further attempt after failure. Record visits and other owners’ activity use a shared append-only store with workspace isolation.

Licensing retains reasoned staff overrides and local commercial coverage, coordinates declared application preparation and computes availability for Security. Database decisions commit before security history and cache-refresh requests; failed follow-up can leave those later effects incomplete. Security retains workspace identity and access decisions, while Queries owns export-allowance administration. The module declares no custom fields, publishes no operation for configurable intake and invokes no model.

Data Job Engine

The module owns shared bulk execution and five design objects: jobs, uploads, producer mappings, data runs and capacity state. Adopting services keep jobs and mappings beside their domain records. Platform owns upload and run storage, while its capacity sentinel publishes protection decisions. Membership declares operations but has no runnable job storage at the examined revision.

The exposed operations match the service contracts: CRM record jobs, Platform definition and custom-record jobs, multipart upload, staff-driven migration runs, capacity pins and health checks. Internal queues, schedules and file orchestration are execution infrastructure. Capacity publication writes shared storage rather than emitting a business event.

Domain owners retain record validation, persistence, history and change events. Workspace lifecycle coordinates loading, reset and activation; shared operations provide durable orchestration. The invariant references describe enforcement boundaries, including producer-key insertion races, request-runner recovery gaps, explicit overwrite policy and missing retention sweeps. Partition maintenance remains provisionally assigned here. Engine objects enable no custom fields, operations publish no Submissions bindings, and examined paths make no model calls.

LLM and the AI Teammate

The module owns model-request and task bookkeeping, routing and price histories, monthly allowance records, temporary capacity, corrections, crossings, captured evidence and derived daily usage. Consuming features define their questions and validate the answers. Queries uses the declared metered operation, while general Jazz AI replies call a gateway directly outside that foundation. The conversation service owns only the console’s sample memory records; durable ownership remains open.

Admission conditionally reserves credits and a running slot in one period update. Controls and their security audit commit together. Request settlement and task increments precede a separate period movement, so interruption can leave the monthly account inconsistent. Hourly recovery closes stale work at the estimate, checks recent task totals, retries eligible notices and rebuilds reporting; it does not repair every accounting gap. Sensitive evidence reads require qualifying access and completed audit, with failed-read coverage remaining incomplete.

HQ staff receive historical and diagnostic views and privileged service controls; customer administrators receive scoped credit and feature summaries. Console controls for editing, grants and evidence remain disabled, and the planned customer dashboard has no page. The objects declare no custom fields, operations expose no intake bindings and no business events are declared. Security retains authority and audit storage, Queries retains generation and reporting semantics, shared email handles notices, and workspace lifecycle orchestrates removal.

Workspace Lifecycle Across Applications

Workspace lifecycle owns system readiness facts, construction attempts, participant contracts and registers, initial-load and reset records, and deletion decisions with notices and retained evidence. Platform exposes staff lifecycle operations; application functions supply their internal participant work. CRM also reconciles declared starter configuration during release updates.

The structured contracts identify the owning objects and exact operations. Locked decisions, scoped resource keys and database standing constraints supply specific safeguards rather than a universal guarantee of complete removal. Participant omissions, copied availability rules, separate-commit recovery and finalization gaps, and unverified console implementation remain findings. Ordinary workspace administration, authority, shared execution, import processing, export packaging and general sending retain their own module boundaries. The reviewed lifecycle dispatchers make no model calls and expose no configurable intake operation.

What Is Delegated to Platform and Other Areas

Identity, sessions and reach remain with Security; licensing and recent-record history remain with Operations; record definitions and placements remain with Metadata. Queries, Eligibility, Notifications, the LLM module and Accounting own the tools hosted in the frame. Business pages belong to the modules responsible for their records.

The shell performs no model inference and declares no custom fields or business-save operation. Security can still write bookkeeping during consumed reads, and it owns session termination. These effects are distinct from shell presentation ownership.

Security consumes participant-owned preparation/removal, import execution from the Data Job Engine, generic job execution and licensing from Operations, rule evaluation from Eligibility, delivery from Notifications, contacts from CRM and appointment-derived synchronization from Committees. The final workspace-module split remains an open planning decision; shared source scope does not establish a second rule owner.