Every type in the workspace. Shaped where the plan allows.

One cell in the console, down to one button here.

Most of this exists. Plan gates already run from the console's plan matrix through effective_features to a profile field that gating.ts reads. Custom types add a catalog row, one resolver, three profile fields, three endpoints and the audit verbs, and they close one gap the pipe has today (step 5). Steps marked new are the build; the rest is plumbing that already carries graph, files and translate.

1. Catalognew row

   FEATURE_CATALOG["custom_types"], bool, levels plan and org only. Not workspace, not user: who may change a workspace's vocabulary is the workspace's policy, and a user-level override must never be able to grant it (the narrowest-writer-wins trap REFERENCE.feature-registry.md warns about). A sibling max_custom_types (int, org) follows the max_emails pattern: unset falls through to PLAN_MAX_CUSTOM_TYPES[plan], and -1 means unlimited.

2. Planexists

   Console → Plans → Features matrix: one cell per plan (POST /api/admin/v1/plan-features), every toggle written to plan_features_audit. The new key appears in the matrix by itself, because the matrix reads the catalog. A contract-locked org keeps what it signed (contract_base_features), so a later matrix edit never takes custom types away from a signed contract.

3. Org exceptionexists

   Console → Org → Flags (POST /api/admin/v1/orgs/{id}/flags), for a pilot on a plan without it or a contract exception. It goes into the same audit log. The org layer is console-only today, so no workspace can turn this on for itself.

4. Resolvenew

   custom_types_manage_for(org_id, org_role, resolved) beside graph_enabled_for: feature_enabled("custom_types", org_id=…), deliberately without user_id or workspace_id, AND the role is owner or org admin. Superadmin passes, for dogfooding. On any error it returns False, so the buttons stay hidden.

5. Profile3 fields

   GET /profile gains custom_types_enabled (the workspace's plan includes it), can_manage_types (that, and you are an admin) and custom_types_upgrade_to: the lowest plan whose matrix cell is on, or null. The third field is needed because a plan that leaves a feature out writes nothing. effective_features only carries keys a layer grants, so the entry is absent, and gating.ts denyReasonFor reads absence as unavailable, not plan. Today's pipe cannot say "upgrade" for a plan-gated feature. An org that was explicitly turned off does carry source: org.

6. Appgate row

   A types row in gating.ts. With no role or flag, every member of the workspace sees the page. can_manage_types decides whether New, Edit and Restore render: hide, don't disable. When it is off for an admin, the banner comes from the reason: custom_types_upgrade_to set means an upgrade (See plans → Team), an org false means a conversation with Relay, and neither means no banner, only built-ins. Adding the page touches the usual six places (pages.test.ts checks them).

7. Server3 endpoints

   GET /api/user/v1/types: built-ins and the workspace's custom types, with settings and usage counts. Ungated. POST / PATCH /types/{id} re-check custom_types_manage_for and the ceiling, and refuse with 403 {"error":"plan","feature":"custom_types"}, because a hidden button is not a closed endpoint. POST /types/{id}/archive needs only the admin role, so a frozen workspace can still tidy up.

8. Applyexists

   Send, forward, claim and filter resolve a type from its stored row through kinds.resolve, the same PLAIN → type default → series override → sender chain that boot uses today. None of them reads the gate. A downgrade freezes the vocabulary; it never changes what a relay does.

9. Recordaudit verbs

   Every write goes to log_audit("type.created" | "type.changed" | "type.archived" | "type.restored") with the before and after settings, plus a system row when the plan gate flips for the workspace. The Activity tab and the console both read that one log.

10. Consolereport

    A Types report across workspaces: how many custom types, on which plans and classes, which settings people actually change, and the latest edits. Counts first, with one workspace's vocabulary readable on drill-in. This is how we see what's being built out (below).

Seeing and applying are never gated.

What's being built out, across workspaces.

Two screens. The plan matrix already exists and gains a row by itself. The Types report is new: it answers "what are people making types for?", which is the signal for which options deserve to be built in next.

What has to hold.

Five for Erik.

1. Which plans, and what ceiling. The concept assumes Team and Enterprise, 25 and unlimited.
2. Can managers manage? ORG_MANAGEMENT_ROLES includes manager. The concept limits it to owner and org admin.
3. Members' way in. A nav item for everyone, or admins in the nav and members via "What's this type?" on the send sheet.
4. Agents making types over MCP. v1 says no: types are made in the app and applied anywhere.
5. Stream types wait until Streams have settings of their own. Until then, Streams take labels.

Related: the model is relay-platform docs/SPEC.class-and-type.md (v0.4, in review). The option set and its copy are the series Kind editor that shipped in relay-app #807. The gate plumbing is relay-platform relay/features.py and relay-app web/src/gating.ts.