Skip to content

Platform Extension Manifest

Declarative artifact — instantiates Platform Core / Extension Design

The machine-readable declaration every extension ships with — its identity, dependencies, requested permissions, bound extension points, and compatibility range — so the platform can reason about it before it ever runs.

Platform Extension Manifest is the declaration file every extension ships with — a machine-readable statement of what it is and what it needs: its identity and version, its dependencies, the permissions and resources it requests, the extension points it binds to, and its compatibility range. Its defining property is that it makes the extension's claims verifiable and machine-checkable up front, before the extension runs. A manifest does nothing at runtime; it lets the platform reason about an extension — resolve its dependencies, check its compatibility, gate its permissions, register its identity — from a declaration, rather than by running unknown code and finding out.

Example

A 3D game engine supports a modding ecosystem. Every mod ships a manifest: a unique id and semantic version, the engine version range it targets (>=5.2 <6.0), the mods it depends on, and the capabilities it requests — filesystem read for its textures, network access only to a declared asset host, and no access to save files at all.

When a player installs the mod, the platform reads the manifest first. It resolves the dependency graph, refuses the install outright if the engine is 6.1 (outside the declared range), and shows the player exactly which permissions they are about to grant. Later, when the mod tries to reach the network beyond its declared host, the request is denied — the manifest said it would not, and that declaration became the boundary the sandbox enforces. Nothing here required running the mod to discover what it wanted.

How it works

  • Declare, in verifiable form, the extension's identity, version, dependencies, requested permissions and resources, bound extension points, and compatibility range.
  • Make the declaration machine-checkable, so the platform can resolve dependencies, validate compatibility, and gate permissions before any execution.
  • Serve as the single hand-off — the artifact the registry ingests, the permission model reads, and the sandbox enforces against.
  • Keep it honest by verification — a manifest declares intent; it cannot by itself prove the code matches, so its claims are checked, not trusted.

Tuning parameters

  • Declaration granularity — how finely permissions and dependencies must be stated. Fine grain enables least-privilege and precise resolution but burdens every builder; coarse grain is easy but over-grants.
  • Compatibility expression — exact pins versus ranges. Pins are predictable but brittle across platform updates; ranges survive updates, but only if the platform honors its versioning promise.[1]
  • Required vs. optional fields — how much a manifest must declare to be valid. More required fields make extensions safer to reason about but raise the bar to publish.
  • Verification strictness — how hard declared claims are checked against reality. Strict verification closes the gap between declaration and behavior but costs tooling; lax verification lets a manifest lie.

When it helps, and when it misleads

Its strength is that it lets a platform reason about an extension cheaply and safely from a declaration, and it is the common artifact that the registry, permission model, and sandbox all build on — so identity, dependencies, and permissions stay consistent across them instead of being re-derived three different ways.

Its failure mode is the gap between declaration and fact: a manifest states intent, not proof. It automates policy but cannot show an extension is safe or truthful, so an unverified manifest is a promise, and a compatibility range is only as trustworthy as the platform's fidelity to its own versioning.[1] The classic misuse is treating a well-formed manifest as evidence of safety — letting the neatly-declared file stand in for the verification it was supposed to enable. The discipline that guards against this is to check declared claims against actual behavior (signatures, scans, conformance runs) and to keep the manifest the source those checks verify against, not merely quote.

How it implements the components

The manifest realizes the declaration side of an extension's metadata — the claims other mechanisms store, resolve, and enforce:

  • platform_dependency_and_permission_model — declares the extension's direct and transitive dependencies, the platform capabilities and data scopes it requests, and its resource limits, in the form least-privilege enforcement reads from.
  • extension_identity_discovery_and_registration — carries the stable identity, version, provenance, and status metadata that registration and discovery are built from.

It declares but does not store or adjudicate what it declares — the authoritative record and lifecycle state live in the Platform Plugin and Extension Registry — and it does not enforce the permissions it requests, which is the job of Platform Sandbox and Capability Permissions.

  • Instantiates: Platform Core / Extension Design — the manifest is the declaration that makes an extension something the platform can reason about before it runs.
  • Sibling mechanisms: Platform Plugin and Extension Registry · Platform Sandbox and Capability Permissions · Platform Extension Health and Dependency Dashboard · Platform Architecture Blueprint · Platform API and SDK · Platform Capability Catalog and Portal · Platform Conformance Test Suite · Platform Ecosystem Change Council · Platform Migration and Deprecation Tooling · Platform Reference Implementation · Platform Semantic Versioning and Release Train

References

[1] Semantic Versioning (SemVer) — the MAJOR.MINOR.PATCH convention in which a change to the leftmost number signals a break. A manifest's compatibility range (e.g. >=5.2 <6.0) is only meaningful if the platform actually honors SemVer's promise that a minor bump will not break dependents. ↩