--- id: CON-PFM-INT-005 name: Extension feature: FEAT-PFM-INT-05 product_area: platform module: integrations revision: 1 status: draft product_intent: proposed implementation_evidence: observed source_sha: services-platform: ad3f6a6582843008ed0f5a17b131878d15829af1 react-console: baf6dae382d6f41dce976c7f848667ccc37e076f definition: >- An extension is configured behaviour attached to a customization point an application exposes, using a rule or an authorized code handler. owned_by: MOD-PFM-INT synonyms: - Customization - Extension point - Integration Lambda (Rhythm 1.0) not_to_be_confused_with: - Provider offer and adapter - Provider account routing choice - Post-event action configuration facets: - name: Extension point meaning: >- An application declares a customization moment with its kind, cardinality, scope choices and failure behaviour. used_for: Defining the boundary where customer configuration may participate. - name: Contract version meaning: 'Each point version supplies input and output schemas, examples, supported facts and any neutral result.' used_for: Validating configured behaviour and interpreting examples. - name: Business event type meaning: A declared business occurrence has a payload contract and native application subscribers. used_for: Describing events that other work may consume. - name: Handler meaning: 'Rules, Lambda functions and built-ins supply behaviour, with handler secrets kept separately.' used_for: Implementing a customization point’s answer. - name: Extension binding meaning: 'The attachment identifies scope, handler, lifecycle, priority, policy and effective dates.' used_for: Selecting which configured behaviour applies in a business context. - name: Invocation meaning: 'A retained handler execution distinguishes ordinary, shadow and test purpose and its outcome.' used_for: Inspecting customization execution and diagnosis. relationships: - to: CON-PFM-INT-004 statement: >- External business-event delivery belongs to integration routing rather than a separate extension subscription system. provenance: documented source: 'services-platform:docs/extensions.md#6. What is not built' - to: CON-PFM-INT-006 statement: >- Business-event declarations and automation event triggers need consistent meanings across their separate registries. provenance: inferred source: 'services-platform:docs/workflow-actions/automation-rules.md#Automation rules: the engine''s third host' note: >- The design expects compatible event or action meaning across these mechanisms; automation validates its trigger registry rather than joins extension event types, and the complete host path is not established by these sources. lifecycle: - state: draft meaning: The attachment is prepared but not active. how_it_changes: 'An administrator enables, shadows or disables it.' - state: shadow meaning: The configured attachment has shadow standing beside the authoritative choice. how_it_changes: It can be activated or disabled. - state: enabled meaning: The attachment can supply the selected answer. how_it_changes: 'Staff can pause it, switch to shadow or receive an orphaned status from registration.' - state: orphaned meaning: Registration removed the point it references. how_it_changes: The remaining lifecycle operation is disable. acted_on_by: - CAP-PFM-INT-016 - CAP-PFM-INT-017 visible_to: - ACT-PFM-022 - ACT-PFM-019 - ACT-PFM-020 evidence: - >- services-platform source inventory: modules/extensions/** (db tables, lifecycle.ts, resolution.ts, services/registration, services/rules, services/test-invocation, aws/api/extensions.routes.ts); docs/extensions.md; docs/proposals/extensibility/decision-log.md. - >- react-console source inventory: app/(console)/console/[tenantId]/configuration/platform/extensions/**, components/extensions/*, lib/extensions/* (mock adapter). supersedes: [] --- # Extension ## What It Is An extension is configured behaviour that an application invites at a declared customization point. Staff can use it to adapt a decision or transformation without rewriting the surrounding application. The application owns the moment and the contract; the customer configuration supplies a handler and an attachment identifying where it applies. A declarative rule gives configuration administrators a way to express supported conditions and results. Authorized code authors can supply a function handler for behaviour outside that rule form. The point’s declaration explains what input is available, what answer is acceptable and how the application treats failure. This makes the boundary a product concept: customization participates at an offered moment instead of gaining unrestricted control of application records. ## What It Is Not A provider integration connects Rhythm with an outside service and account. An extension changes participation inside an application-defined process. Its binding selects a handler for a customization scope rather than a provider account for a capability. Automation rules raise actions after a business event and retain their own publication model; that event-driven work should not be confused with choosing a customized answer at a point. ## How It Is Used Configuration administrators review the offered points, write rules and test examples before attaching them. A code author uses stronger authority when supplying a function handler. Scope and effective dates help staff restrict the intended use. Preview explains which attachment would be selected and where choices are ambiguous. The present console demonstrates configuration with sample data. Backend rule tests execute and record results, while Platform’s code-handler test path has no active transport. These are different evidence strengths. A successful sample demonstration does not prove that the customer’s saved binding changes a consuming application. Good use asks for that complete path before relying on the customization in a business process. ## Its Facets **Point and contract version.** The application identifies a supported moment and defines input, output, available facts and any neutral answer. Versions let configuration name the contract it uses. **Business-event declaration.** The same registry intake also describes application occurrences and native subscribers. It is a neighbouring event facet rather than another customization handler. **Handler.** Rule, function and built-in kinds supply behaviour. Kind-specific properties separate executable target information from write-only secrets. **Binding.** The attachment specifies scope, lifecycle, priority, failure policy and time window. A retired point leaves the attachment orphaned for administrative review. **Invocation.** Recorded purpose and outcome distinguish tests and other runs. Capture references are diagnostic information, not evidence that payload storage and retention are fully implemented. ## How It Relates Extensions have a different role from provider calls even when a customized process eventually contacts a provider. Business-event declarations should align with automation event triggers, but the two registries are separate and their connection is an inferred design relationship. Outbound business-event delivery belongs to the integration router rather than a separate extension subscription facility. ## What It Could Become The product should confirm the adopted design recommendations through recorded decisions and prove a connected consuming application. The registration intake also needs an explicit boundary tying replacement authority to the invoking application; trusting a declaration’s service name is insufficient evidence of that identity. Console wiring, code transport, shadow execution evidence and invocation retention remain open edges. Future customization work should retain the offered-point boundary rather than infer approval from the presence of a handler record.