Platform Plugin and Extension Registry¶

Register — instantiates Platform Core / Extension Design

The authoritative system of record for every extension's identity, provenance, versions, and lifecycle state — the single source of truth from which discovery, approval, suspension, and retirement are driven.

Every other extension mechanism needs one place it can trust to answer "what is this extension, who owns it, which version is this, and is it still allowed?" Platform Plugin and Extension Registry is that place: the authoritative record that assigns each extension a stable identity and holds its provenance, owner, version history, and — decisively — its current lifecycle state. Its defining move is that state lives in the record, not in the extension: suspension, ownership transfer, and retirement are executed by flipping a field every consumer reads, so a recall or a hand-off takes effect ecosystem-wide the moment the registry changes. It does not judge whether an extension is safe, enforce what it may do, or decide policy — it records, and everything else reads from it.

Example¶

A smart-home hub platform built on an interoperability standard like Matter lets independent makers ship device integrations. A vendor registering a smart-lock integration receives a stable extension ID, has its publisher identity and provenance recorded, uploads version 1.3, and declares compatibility with hub firmware ≥ a given release. Months later a vulnerability surfaces. Rather than chase every installed copy, the operator flips the registry record to suspended — and because each hub checks the registry before loading an integration, distribution stops and installed instances surface a warning. Later the integration changes hands: the new maintainer is recorded as owner in a single field edit, with the old provenance preserved. Identity, registration, state change, and orderly transfer all happen as record operations, never as re-publishing.

How it works¶

What makes it a register rather than a store or a gate:

One authoritative identity per extension — stable IDs, verified namespace/publisher ownership, and provenance, so impersonation and name collisions are caught at the record level.
Append-only history — every version, owner, and status change is retained, giving a trustworthy audit trail rather than a mutable snapshot.
A canonical status field — experimental / supported / deprecated / suspended / retired is the single value consumers trust, and the lever from which suspension and retirement propagate.
Stale-record review, transfer, and appeal — abandoned records get flagged, ownership can move, and status changes are contestable.

Tuning parameters¶

Identity strictness — how hard publisher identity and namespace ownership are verified before an ID is granted. Turning it up curbs impersonation and typosquatting but raises onboarding friction.
Registration gate depth — whether records go live self-serve or wait on approval. (The judgment is another mechanism's; this dial only sets whether the register blocks on it.)
Status granularity — how many lifecycle states the register distinguishes; more states are more expressive but more to maintain and reason about.
Provenance retention — how much version and ownership history is kept immutable versus pruned.
Discovery exposure — which fields are publicly queryable versus operator-only.

When it helps, and when it misleads¶

Its strength is that it gives the whole ecosystem one trusted answer to identity, currency, and permission — and it is what makes recall real: a suspension in the register actually stops distribution and use, instead of a warning nobody sees. It is the backbone the catalog, review gate, sandbox, and dashboards all read from.

Its failure modes are those of any register. It is only as trustworthy as its identity checks — weak verification invites impersonation, typosquatting, and dependency confusion.^[1] And it rots quietly: abandoned extensions still stamped "supported" erode trust in the one field everyone relies on, so stale-record review is not optional. The classic misuse is letting the register harden into opaque gatekeeping — using registration as a discretionary chokepoint rather than a transparent, appealable record. The discipline that guards against both is visible criteria, contestable status changes, and periodic stale-record sweeps.

How it implements the components¶

extension_identity_discovery_and_registration — its core function: it assigns stable identity, records provenance / owner / versions / status, and makes extensions discoverable and resolvable.
extension_lifecycle_governance — it holds the authoritative lifecycle state and executes registration, suspension, ownership transfer, and retirement as record transitions — the state store the lifecycle turns on.

It does not decide whether an extension is fit — conformance and safety verdicts come from [Platform Extension Review and Certification], and ecosystem-wide policy authority sits with Platform Ecosystem Change Council. It records declared permissions but does not enforce them at runtime; that is [Platform Sandbox and Capability Permissions].

Instantiates: Platform Core / Extension Design — the registry is the ecosystem's system of record for identity and lifecycle state.
Consumes: Platform Extension Review and Certification supplies the verdicts recorded as supported / conditional status.
Sibling mechanisms: Platform Extension Manifest · Platform Extension Review and Certification · Platform API and SDK · Platform Architecture Blueprint · Platform Capability Catalog and Portal · Platform Conformance Test Suite · Platform Ecosystem Change Council · Platform Extension Health and Dependency Dashboard · Platform Reference Implementation · Platform Sandbox and Capability Permissions · Platform Semantic Versioning and Release Train · Platform Migration and Deprecation Tooling

Notes¶

The registry is a record, not a verdict. Keeping "is it recorded and current" separate from "is it safe" (Review and Certification) and "can it act" (Sandbox and Capability Permissions) is what lets each of the three evolve — and fail — independently, instead of collapsing identity, judgment, and enforcement into one brittle chokepoint.

References¶

[1] Typosquatting and dependency confusion are well-documented attacks on public package registries (npm, PyPI), where a malicious package mimics a trusted name or shadows a private one. They are the standard illustration of why a registry's identity and provenance checks are load-bearing rather than clerical. ↩