Task: Bring ores.variability to the clean standard

Two halves of one pipeline were built and only one was wired.

system_setting_changed_event is declared in api. The http server registers the table's PostgreSQL channel and subscribes to the event in process, so its own settings cache does refresh when a setting changes — that half worked. What no component did is publish the event onto NATS: the variability service opened no event source, registered no mapping and had no outbound subject, so the event existed only inside whichever process happened to be listening.

ores.iam/core/src/messaging/registrar.cpp:370 is that second subscriber, and it subscribes to the raw literal "ores.variability.system_setting_changed", which is not the event's own name, not a subject any component declares, and not the canonical event form. Its comment says an update to iam.token.* takes effect without a restart; nothing published to that subject, so it never fired and the reload never happened.

Both halves are now wired: the generated event registrar maps the channel and publishes on the canonical variability.v1.system_settings_events.* subjects, and iam subscribes to the generated constants rather than to a literal. The generated eventing integration test asserts the round trip.

This is not an aberration. In-process consumption of another component's core library is an established pattern: ores.history.core is linked in production by thirteen components, and ores.http links five, because it is the HTTP front end that composes them. The pattern is structural rather than incidental. iam reads a setting during startup and inside auth handlers, and refdata reads one inside a materialisation service, so a bus round trip on those paths buys a failure mode and nothing else; history cannot be a round trip at all, because its rows must land in the caller's transaction. The setting-change event exists for the same reason: read in process, invalidate by event.

A generated stack replaces the entity, mapper, repository, service and handler. This is decision D3 below.

The five recipes under doc/recipes/shell/variability/ and their generated scripts/library/variability/*.ores invoke variability add-flag, delete-flag, flag-history and list-flags. The shell has not had those commands since the feature-flag surface became system settings; it has list-settings, save-setting, delete-setting and setting-history. No recipe exists for any current command, and regenerate_shell_recipe_inventory.py is green because it only reports what the recipe sources say.

• 14 public symbols have no caller anywhere: convert_to_json on both the domain type and the vector, repository::{sql, get_total_count, read_all(ctx), read_latest(offset, limit), write(ctx, vector)}, and service::{get_json, set_user_signups, set_signup_requires_authorization, is_password_validation_disabled, is_onboarding_system_complete, set_onboarding_system_complete, is_onboarding_tenant_complete}.
• The variability seed is not reachable from populate/populate.sql. It is reached from setup_schema.sql:64 through foundation_populate.sql:169. Every script is reachable, but the aggregator the standard names is not the one that runs them.
• validation_ignore.txt:361 carries an RLS_002 suppression for ores_variability_system_settings_tbl: party_id was added without a matching AS RESTRICTIVE party isolation policy, recorded as a stopgap.
• The component has 28 Catch2 cases across three suites and no test touches a protocol type. The repository suite is its only integration test.

The table's identity is the composite (tenant_id, party_id, name), and two of those three columns are server-owned. So the wire key is one of:

• (a) name alone, with tenancy and party read from the authenticated context. This is the ores.iam.account precedent, where the key is the username and the tenant comes from the token. It needs no new column, no seed rewrite and no compass change. It cannot address another party's setting, which no caller does today.
• (b) A new surrogate id uuid, with name as the natural key. This is the ores.assets.tag precedent, binding uuid-identified-lookup. It costs a schema change, a data migration, an edit to every seed script, an edit to compass_db.py, and a change to the upsert function.

Decision: (b), taken on 2026-09-26. The cost is accepted because the natural key is what makes codegen emit get_system_setting_by_name(...), the accessor the in-process consumers need (see D3). Option (a) would have left them scanning a list for a row they can name. The two decisions are one.

Consequences to carry through the change: the seed scripts and the upsert function gain an id, compass_db.py and the per-tenant seeding function follow, and the new column changes the table's primary key, so this is a schema break rather than an addition. The database is recreated from scratch, so there is no migration to write.

clear_bootstrap_mode clears system.bootstrap_mode and sets onboarding.tenant; complete_party_onboarding sets onboarding.party for a party named in the request. Two options:

• (a) Model them as operation models under variability.v1.ops.*, which is what P04 asks for. The party named by complete_party_onboarding is the party being onboarded, not the caller's own party, so it is a target rather than a claim of tenancy and it belongs in a domain operation. Record the reason, because the specification's server-owned rule otherwise reads as forbidding it.
• (b) Re-express both as ordinary writes of system.bootstrap_mode and onboarding.party. This removes two subjects and two handler methods, but it puts a party scope on the wire, which D1 rules out.

Recommendation: (a).

Three components call variability in process: iam through nine typed accessors, http through get_all(), refdata through the repository and read_latest(ctx, name). A fourth, assets, links the library and uses nothing. This is an established pattern, not an accident: thirteen components link ores.history.core the same way, because an in-process shared capability is the only correct shape for a read that must be synchronous with the caller, and the only possible shape for a write that must share the caller's transaction.

Codegen already supports this. Every generated entity's core library exports a documented service class with a visibility macro, in the public include tree, and an entity that declares a natural key gets a by-natural-key read: assets has tag_service::get_tag_by_name(const std::string&) and image_service::get_image_by_code(const std::string&). For system_setting the same generation yields get_system_setting_by_name("system.bootstrap_mode") – which is exactly the call the typed accessors need.

So the options are:

• (a) Bind the natural-key profile and let the generated service be the in-process API. Codegen owns the entity, the wire protocol, the handler, the SQL and the shell surface; the component keeps a small hand-written facade holding only the typed interpretation of a named setting (is_bootstrap_mode_enabled() becomes get_system_setting_by_name(...), a parse, and a default). This is the split the architecture pages already give core: repositories and a service layer. The nine live accessors survive; the seven dead ones and the dead repository methods go.
• (b) Migrate all three consumers to the wire. It removes the library edges, but it puts a bus round trip inside startup, inside authentication and inside a materialisation service, and refdata would have to grow a client for one setting.
• (c) Keep the in-process stack hand-written and generate only the wire types. This passes M06 and P01 to P04 while leaving the entity, mapper, repository and service as hand-written duplicates of what codegen emits for every other entity, which is what G02 forbids.

Recommendation: (a). The decisive point is D1: without a natural key the generated service has no get_by_name, and every typed accessor would have to scan a list. The surrogate-UUID answer to D1 and this question are one decision.

The in-process surface is load-bearing and undeclared. component_architecture.org records services and NATS subjects, not library edges. No item in the Component Clean Standard covers it, so the only thing that notices a broken in-process API is V01, the whole-tree build, and only at compile time. Nothing notices an edge that outlives its caller, which is how ores.assets came to link ores.variability.core.lib and use nothing from it.

The standard has grown before, when a survey found a gap: B06, H04, G07, V07 and V08 were added after four infrastructure components were surveyed. A candidate item here: every library edge into a component's core is recorded with the symbols the consumer calls, and every edge has at least one caller. It is cheap to check mechanically and it would have caught the assets edge.

Two subscribers, two different subjects, no publisher. Options: publish the event from the generated write path and point both subscribers at the canonical subject, or delete the event and the two subscriptions. P06 asks for an event cache that warms through the canonical list and follows the canonical event actions, so the first is the standard-compliant answer; the second is honest if the reload is not wanted. Recommendation: publish it, and fold the iam subscription's raw literal into the canonical generated constant. The reload the IAM comment promises has never worked, so this is a behaviour change that needs a test.