Task: Define the registration target state

A knowledge document that fixes where a self-registered account lands, so that the registration work is built against a decided target rather than decided while it is built. It settles the default tenant, the default party and the default role, the state an account holds while it waits, the read the door makes before it offers a form, and the write path the two registration flags have never had.

• Every default names its storage, its owner and its uniqueness rule.
• The actor that may set each default is justified from the write policy of the table that holds it, not from intent.
• The waiting state is a state, not an absence, and both the roster and the sign-in path are said to read it.
• The rejected alternatives are recorded with the ground they were rejected on.
• The document links to every entity model it changes.

1. Start from the survey, which fixed what exists and what is broken.
2. Settle the storage shape by asking who may write each candidate row, because a default nobody can set is not a default.
3. Settle the waiting state as a value the roster and the sign-in refusal both read.
4. Name the read the door makes, and keep it separate from the bootstrap read.
5. State the write path the flags lack, and the honest behaviour of the authorisation flag until its workflow exists.
6. Record what the document changes, layer by layer, as the implementation's checklist.

• The shape changed once, and the reason is worth keeping. The first proposal put every default in the variability settings. The write policies killed it: ores_iam_tenants_tbl admits only a system-tenant session, so a default_party_id on the tenant row would be unreachable to the tenant administrator who owns the choice. A default belongs on the row its actor may write.
• The single-tenant case needs no configuration: the address resolves the tenant, which is the rule Multi-Tenancy Architecture already states for a pre-authentication request. The default-tenant flag exists for a deployment that serves several tenants at one address.

Manual QA scenarios (scaffolded via compass add test_scenario) that verify this task. Link new ones here as they're created; the scenario doc itself links back via its "Verifies task" field.

Registration and Onboarding Defaults is the target state. It settles the three questions a registration answers and states the rule that decides where each default lives: the flag sits on the row its actor may write.

The defaults are is_registration_default on the tenant, the party and the role, each with a partial unique index over the live rows; the tenant flag is the super administrator's, the other two the tenant administrator's. The waiting state is a new account_status of pending, written when the tenant nominates no default party, read by the roster and refused by sign-in with its own code. The door asks one unauthenticated read, iam.v1.auth.registration-policy, which returns the flags, the destination and whether a registration can be used at once. Both boolean flags stay in the variability settings and gain the settings read and write they have never had.

Both Entry responses gain an error_code, so a refusal is a value rather than a sentence to match. The document ends with a change table, layer by layer, that the implementation tasks are scheduled from, and with the waiting-state requirement stated for the Directory journeys rather than built here.