# 0002 — The plug-in test: what belongs in a Core baseline

- **Status:** accepted for accepted
- **Date:** 2026-08-03
- **Applies to:** every profile. Applied to Calendar in [`0003`](0003-calendar-core-audit.md).

## Context

USB is cited throughout this project as the source of its shape. It has been repeatedly misread — including by two independent frontier-model reviews of this proposal, both of which concluded that USB's reliability came from certification and that Class Profiles is therefore missing its load-bearing part.

That is the wrong harvest. USB is an **example**, not a template.

The transferable property is this: **you plug in a display the host has never seen, and a picture appears.** Not because the device is interchangeable with another display in every respect — it may be 8K, it may be 3D, it may have quirks — but because the basic job of a display is defined and every display implements it. Certification is how USB *policed* that. It is not what made it useful, and it is not the only way to get it: Android ships a declarative model with no per-app certification, where the host decides and the cost of a false claim falls on the claimant.

What is wanted here is a **ubiquitous language: easy to understand, easy to implement, with levels.**

## The display, spelled out

> All displays implement geometry — resolution, bit depth, refresh rate. Optionally, a display may also report other supported resolutions, bit depths, and refresh rates, but not necessarily. And if this display is something else — say, 3D — it can report that in custom fields its own driver understands.

Three levels, which are already the three tiers in `spec/02 §1`:

| Display | Class Profiles tier | Universality |
|---|---|---|
| Geometry: every display has it | **Core baseline** | everyone |
| Other supported modes, declared if present | **Facet** | some |
| 3D, in fields its own driver understands | **Vendor member** | one |

The levels are levels of **universality, not of quality**. A vendor member is not a lesser thing that failed to become standard; it is how a real difference stays visible and usable without being forced on implementations that do not have it. `com.acme.cal/travel_buffer@1` is the 3D display.

## The gap this fills

`spec/05 §1` already gives a membership test for the **kernel**:

> Test for kernel membership: **would every class, without exception, be wrong without it?**

There is no analogous test for **Core baseline** membership within a class. `spec/01 §3` describes what a baseline *is* (immutable, content-addressed, the mandatory floor) and the Ten Jobs list supplies a **sufficiency** test — a baseline alone must complete the class's ten most common jobs. Nothing supplies a **necessity** test, so nothing prevents Core from accumulating behaviour that most members of the class have but some real ones lack.

## Decision

Core baseline membership is governed by a pair of tests. A candidate belongs in Core only if it passes **both**.

**Sufficiency (existing).** Core alone completes the class's Ten Jobs. Nothing in the Ten Jobs list may require a facet.

**Necessity (new) — the plug-in test.**

> **A thing that cannot do this is not a member of this class.**

If a real, reasonable implementation of the class can lack the behaviour and still obviously be a member of that class, the behaviour is **not Core**. It is a facet, or a vendor member, or nothing.

The evidence standard for "real and reasonable" is an existing implementation, not a thought experiment. Where the discovery corpus can speak to a candidate, it should.

## Why this makes the all-or-nothing rule correct

`spec/03 §4` requires a baseline Claim to pass the baseline suite **completely**: *"a partial pass is a failing grade: a floor only means something if it always means everything."*

That rule is only defensible if every Core member is necessary. If Core contains something a real calendar could reasonably lack, then all-or-nothing excludes implementations that should have worked on plug-in — which is exactly the failure the analogy exists to prevent. The necessity test is what earns the all-or-nothing rule.

It also resolves hedged normative language. Wording of the form *"wherever the backend permits"* inside a Core requirement is a sign that the necessity test was not applied: the hedge exists because the author knew some backends cannot comply. Under this decision the hedge is not a compromise to be softened but a finding to be acted on — the behaviour fails necessity and moves to a facet.

## Consequences

1. Every Core baseline gets a recorded necessity audit, member by member, before publication. Calendar's is [`0003`](0003-calendar-core-audit.md).
2. Hedged obligations (`where supported`, `wherever possible`, `if the backend permits`) are prohibited in Core. A Core requirement is unconditional; a conditional behaviour is a facet with a `degrades_to` statement.
3. The Ten Jobs list is itself auditable. If a listed job can only be completed by an implementation with a capability that fails the necessity test, then either the job is not one of the class's ten most common jobs, or the capability is genuinely universal. One of the two must give.
4. Facets get easier to justify, not harder. Moving something out of Core is not a demotion — it is the mechanism working. The facet still carries a fixture suite, an exact version, and a `degrades_to` statement, so nothing disappears silently (`spec/05 §8`).

## The stop rule

The necessity test cuts. Applied without a limit it keeps cutting, and a Core shaved down to almost nothing surrounded by a cloud of facets would be a worse outcome than the oversized floor it replaced — `spec/01 §4` already warns against exactly that: *"Fourteen loose independent properties are neither"* testable nor composable.

The display supplies the limit, because it is the same test read forwards instead of backwards:

> **Geometry alone shows a picture. Core alone must run your calendar.**

A Core-only implementation must be **usefully complete for ordinary work**, not merely technically conformant. That is what the Ten Jobs sufficiency test already measures, and it is the binding constraint on how far necessity may cut. The two rules pull against each other on purpose: necessity shrinks the floor, sufficiency stops it collapsing, and Core is what survives both.

Two further guards:

- **A facet is a coherent job someone can want or decline** — recurrence, invitations, tombstones. If a proposal starts producing one facet per implementation difference, the finding is that the **class boundary is wrong**, not that more facets are needed.
- **Facet count is a smell, not a rule.** If a class needs many facets before it can do ordinary work, either the class is really two classes, or Core was cut past the picture.

Applied to Calendar ([`0003`](0003-calendar-core-audit.md)): Core after the audit is see, create, edit, cancel, and find free time. That runs a calendar. The cut is inside the line.

## What this does not change

This is a rule about **Core membership**, not about the value of the proposal. It does not weaken conformance; it makes the floor smaller and truer, which is what "plug it in and it works" requires. A large floor that excludes real devices is worse than a small floor that admits them and declares the rest.

It also does not change who the proposal is for. The floor exists so that a publisher's server is misused less, so that an agent infers less, so that a person gets a better answer — a chain in which each link produces the next ([`spec/01 §9`](../spec/01-concepts.md#agent-facing)). A floor that is too big breaks the first link by excluding real implementations; a floor that is too small breaks it by leaving them nothing worth conforming to.

## Note on the reviews

Both independent reviews recommended richer capability descriptions — target-space characterization, determinism class, authority visibility, consistency-domain declarations. Under this decision most of that is out of scope by construction. A display declares geometry. It does not declare its target space or its determinism class, and a language that required it to would not become ubiquitous, because every implementer would have to fill the field in.

The design pressure is **easy to understand and easy to implement.** Expressiveness that costs implementers more than it saves consumers is a net loss, and the kernel's own membership test already says so.