Extension

What It Models

An extension lets customer configuration participate at a point an application deliberately offers. Platform stores the declaration, handler and binding; a host resolves the binding and invokes it through the shared library. Platform can evaluate rule handlers for tests and retain invocation records that hosts write.

Identity and Attributes

Applications declare dotted keys for points and business event types, with numbered contract versions. Handlers, bindings and invocations use generated identifiers; an invocation takes its execution identity from the host envelope.

A point states its application, kind, cardinality, scope order, modes, timeout ceiling, failure policies and registry status. Numbered contracts retain input and output schemas, condition facts, examples, optional neutral output and version status. Event declarations supply their application, subject kind, permitted scopes, payload versions and native subscribers. Handlers retain kind, safe target, secret reference, implemented contracts, rule settings, timeout and capture flag; HTTPS configuration is refused. Bindings attach a handler at a point and scope with a contract version, priority, failure policy, effective interval and lifecycle status. Invocation records explain the point, handler, binding, mode, purpose, result, timing, errors and optional diagnostic references. Catalogue reads aggregate the current workspace’s binding counts for each point. Handler and binding edits require the version previously read.

Relationships

A declared business event can correspond to a trigger registered for automation by its application.. The services keep separate registries and do not enforce that correspondence.. External business-event delivery uses the integration event service.. The extension registry contains no customer event-subscription facility..

Invariants

Registration validates the entire declaration and commits no registry changes when validation fails. A key already attributed to another declared service cannot be adopted by a new declaration. Omitting a customization point retires it and its versions and orphans its bindings across all workspaces. A scope on a single-answer point can contain only one binding whose status is enabled or shadow. Only registration can mark a binding orphaned; the administrative lifecycle permits an orphaned binding to move only to disabled. Rule saves check every implemented point’s current contract; binding validation checks the explicitly selected version. Handler secret storage supports writing, replacing and scheduling deletion, while the Platform handler API does not read values back. Deleting a handler fails while a binding still references it. Handler and binding mutations commit security history that names changed fields while omitting target and secret contents.

How It Is Stored and Shared

The extensions service owns global point and event declarations and workspace handler, binding and invocation records. Hosts have a restricted capability to create and finish invocation records, so ownership does not imply that Platform is the only writer. Handler secrets use write-only storage calls that do not share database rollback. No object declares custom fields.

Open Design Questions

Registration does not bind the declaration’s application name to the authenticated caller. Screens are available as mock previews only. Platform code-handler test transport, payload storage and invocation retention are incomplete, and broader extension intent remains proposed.