---
type: Axis
title: extensibility (trust/plug-in axis)
description: The extensibility/trust architecture axis — how third-party behavior enters the system (hardcoded → config → plugin → sandboxed). A system-singleton axis whose commitment surface is the configuration schema (and the plugin contract); worked example is the backend adapter Protocol + plugin format.
tags: [axis, architecture, extensibility, plugin, adapter, trust, rfc-75, deep]
timestamp: 2026-06-18T00:00:00Z
---

# Extensibility (trust/plug-in axis)

> **DEEP axis (5A.2).** Full §6 depth with a worked example from the skill's own
> history — the forge-backend adapter Protocol + plugin format.

## Concept

Extensibility is the **trust/plug-in** axis (RFC #75 §3): how behavior that the
core doesn't hardcode enters the system, and how much the core trusts it. The
ladder runs hardcoded (the only behaviors are compiled in) → config (declared
data selects among built-in behaviors) → plugin (third-party code conforming to
a published contract is loaded) → sandboxed (plugin code runs with constrained
capabilities). Its **commitment surface is the configuration schema** (§4) at
the lower rungs and the **plugin contract** (a wire/interface contract) at the
upper rungs: once plugins target a contract, the contract is a commitment you
must version. Its **scope is system-singleton** (§5).

## Why it is an axis (discriminator test — §2)

1. **Ordered tiers** — each rung admits a more independent, less-trusted source
   of behavior.
2. **Cross-cutting bundle** — a rung dictates the extension contract (Protocol),
   the discovery/registration mechanism, the config schema, the trust boundary,
   and the conformance tests.
3. **Asymmetric migration cost** — once a published plugin contract has external
   implementers, you cannot change it freely; sandboxing after the fact means
   re-mediating every capability a trusted plugin previously assumed.
4. **Requirement-keyed selection** — falsifiable probes pick the rung.

## Schema view (the §6 entry — validated by `axis_catalog`)

```yaml
id: extensibility
kind: architecture-axis
scope: system-singleton
selection:
  probes:
    - "Are all behaviors known + compiled in, with no need to vary per deployment? → hardcoded."
    - "Must a deployment SELECT among built-in behaviors without recompiling? → config."
    - "Must third parties add NEW behavior conforming to a published contract? → plugin."
    - "Is the plugin code untrusted (must run with constrained capabilities)? → sandboxed."
    - "Do external parties implement your extension contract? → it is now a versioned commitment."
composes_with:
  - "extension trust interacts with principal (a plugin runs AS some principal)"
applies_when: []
tiers:
  - tier: hardcoded
    commitment_delta:
      surface: configuration-schema
      delta: "behaviors are compiled into the core; varying behavior means editing + redeploying code. No extension surface."
    admin_tool: "none — change the code."
    enforcement:
      - "the set of behaviors is closed + reviewed in-tree."
    tests:
      - "each built-in behavior is covered."
    forecloses: "per-deployment variation without a rebuild."
    migration_cost_to_next: "low — externalize the choice into a config schema selecting built-ins."
  - tier: config
    commitment_delta:
      surface: configuration-schema
      delta: "declared configuration selects + parameterizes among built-in behaviors. New behaviors still require core code; config only chooses."
    admin_tool: "config validator + schema docs."
    enforcement:
      - "config is validated against a schema; an unknown selection is rejected at load."
    tests:
      - "each valid config selects the right built-in; an invalid config fails closed."
    forecloses: "third-party NEW behavior (config only picks among existing)."
    migration_cost_to_next: "high — publish an extension contract (Protocol) + a loader for third-party implementations."
  - tier: plugin
    commitment_delta:
      surface: interface-wire-contract
      delta: "third-party code conforming to a published contract (a Protocol + a plugin/manifest format) is discovered + loaded. The contract is now a versioned commitment external parties depend on."
    admin_tool: "plugin registry + conformance checker; manifest validator."
    enforcement:
      - "a loaded plugin must satisfy the published Protocol; a non-conforming plugin is rejected at registration."
      - "the contract is versioned; a breaking change is a contract event."
    tests:
      - "a conforming plugin loads + is invoked; a non-conforming one is rejected; the contract's compatibility is checked."
    forecloses: "unilateral contract changes; external implementers are coupled to it."
    migration_cost_to_next: "high — constrain plugin capabilities (sandbox) without breaking trusted plugins."
  - tier: sandboxed
    commitment_delta:
      surface: interface-wire-contract
      delta: "plugin code runs with constrained capabilities (no ambient FS/network/process access); the host mediates every capability the plugin uses."
    admin_tool: "capability-grant console; sandbox-policy editor."
    enforcement:
      - "a plugin can only use explicitly granted capabilities; ambient access is denied by default."
    tests:
      - "a plugin attempting an ungranted capability is denied; a granted one succeeds; escape attempts fail."
    forecloses: "plugins assuming ambient host capabilities."
    migration_cost_to_next: "n/a — top of the ladder."
examples:
  - "The skill's own climb: forge backends are PLUGINS behind a published adapter Protocol (GitHub / Forgejo+Codeberg / GitLab / local docs store) selected by forge-config.json.platforms — a deployment adds/removes a backend via config (add_backend), and a new backend is a new Protocol implementation, not a core edit. The skill itself is also a Claude-Code PLUGIN with a .claude-plugin/plugin.json manifest + .mcp.json contract. Sits at plugin (trusted, in-process); not sandboxed — backends + the MCP server run with full host capabilities by design."
```

## Selection procedure (§8)

Bidirectional check; chosen once. Recorded in the system architecture record; a
new third-party-implemented surface that lacks a published, versioned contract
is a systems-analysis D-finding.

## Composition (§5)

A plugin runs *as* some principal — extensibility composes with **principal**
when the loaded code acts on behalf of a service/system identity. Rule authored
in 5A.3.
