---
id: KEY-WP-0030
type: workplan
title: "Make the static-registration precondition a checked condition"
domain: infotech
repo: key-cape
status: finished
owner: claude
topic_slug: tenant-precondition-guard
created: "2026-09-09"
updated: "2026-09-09"
state_hub_workstream_id: "9ed8f851-080a-5d15-8642-f799c2e3295c"
---

`informed-decision` replied on KEY-WP-0013-T05 and asked for one thing that is
ours to do: the caveat under which a registration-bound human tenant is safe
should be "a condition of the capability, so a future change to registration
policy has to confront it", not reasoning left in a message.

They are right that it was only prose. `docs/tenant-claim-contract.md` states it,
and a separate test asserted `registration_endpoint` is absent — but nothing
connected the two, so a future session adding dynamic registration would see a
test about discovery metadata, not a warning about relabelling users.

## Tie the exclusion to the capability it protects

```task
id: KEY-WP-0030-T01
status: done
priority: medium
state_hub_task_id: "4729d591-39d4-5f33-bef8-db8057090913"
```

`TestRegistrationBoundTenantRequiresStaticRegistration` asserts both halves
together: that a client-declared tenant is issued, and that dynamic client
registration is not advertised. Whichever is removed first, the failure points at
the other.

The failure message carries the reasoning rather than the observation. Adding
dynamic registration while a registration may declare its users' tenant means
anyone able to register a client can relabel the users who log in through it into
a zone of their choosing; the message says that and names the two ways out, drop
the capability or gate it to statically configured registrations.

Verified in both directions rather than assumed: advertising a
`registration_endpoint` fails it with the escalation message, and neutering
`humanTenant` fails it with the message saying to remove the guard along with the
capability it protects.

This is deliberately not a vote on the tenant question. It makes the precondition
of one option checkable; it does not choose between them, and if option 1 lands
the capability and this guard are removed together.

## Carry the tenant claim's provenance

```task
id: KEY-WP-0030-T03
status: done
priority: high
```

gate-house ruled on GH-DEC-2026-013 while this was in flight. Section 5 is a
finding nobody asked for and is ours to implement: `tenant` is a bare string, so
a consumer cannot tell a zone the directory asserted about the person from one a
registration supplied about the client they came through. approval-engine
exact-matches that string while its contract reads as though it relies on the
first — the check is sound and the property a reader infers from it is absent.

Every token now carries `tenant_source` beside `tenant`: `directory`,
`registration`, or `default`. It is advertised in `claims_supported` and asserted
on both grants at the token level, not only in the resolution function, because
the claim a consumer reads is the thing under obligation.

Three values where the ruling names two, and that is the substantive judgement
here. Labelling an unasserted profile default as `directory` would reproduce the
same defect one level down — a consumer reading an assertion the identity layer
never made. The ruling cites GH-DEC-2026-011 §3 on unknown versus absent for the
case it examined; the same rule applies to our own fallback, so the fallback is
named rather than folded into the strongest neighbouring value.

The agreement case resolves to `directory` deliberately: if a registration
declares the zone the directory also assigned, the directory did assert it, and
reporting the weaker source would understate what is known.

## Condition (b) corrected a message I had just shipped

```task
id: KEY-WP-0030-T04
status: done
priority: high
```

The guard committed in `5f516a0` told a future reader that adding dynamic
registration could be resolved by dropping the capability **or gating it to
statically configured registrations**. Condition (b) voids the second: admitting
dynamic registration voids the registration-bound shape that day, and the
directory becomes the only source whatever state the adapter is in. gate-house
strengthened our own "must be revisited" on the grounds that *revisited* implies
the answer might survive review, and it would not.

So the message offered a way out the ruling forbids, in the exact place someone
would read it while making that change. Corrected the same day. Worth recording
rather than quietly editing: the guard was written to force a confrontation, and
a guard that suggests an inadmissible resolution is worse than none.

## What stays with the owners

```task
id: KEY-WP-0030-T02
status: done
priority: medium
state_hub_task_id: "32b10327-f55d-5a0e-a4bc-be92929469dc"
```

`informed-decision` prefers option 2 and explicitly declines to treat that as the
answer, flagging it to gate-house on GH-DEC-2026-012 and naming approval-engine's
stake. KeyCape leans the same way, which is a reason for more care rather than
less: the code already implements option 2 (`329e48f`), so the doctrine question
is being decided against a working implementation. That is worth saying out loud
to everyone waiting on it, and was.

Their scope set `[openid, approval:read, approval:approve]` is confirmed and
already published. `client_id` and callback follow at their T07, deliberately not
before the tenant question resolves — registering a client that fails closed at
first use is the failure this exchange existed to avoid.