Name what CheckRequest.tenant denotes; record the access-engine rename intake

TEN-DEC-2026-002 answers flex-auth's FLEX-WP-0022-T01, open since
2026-09-15: `tenant` denotes the target tenant record, equals
`resource.id` by intent, and the write API is cross-tenant by design —
no action is refused on the subject/tenant relationship, and
tenant.guardrail.read must not differ because flex-auth itself calls it
across tenants. docs/flex-auth-integration.md states the relation in
this repo's voice.

TEN-IN-0004 is the live record flex-auth asked for on FLEX-WP-0020.
Runtime names stay flex-auth (FLEX-DEC-2026-013) and all deploy, cluster
and settings coordinates verify as retained; only five documentation
repository paths change when the rename lands.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 63291@bnt-lap001
Assistant-Session: 8bd77868-ca68-4f49-bb1e-d539ecc0d703

docs/flex-auth-integration.md

@@ -26,6 +26,41 @@ other PIP claim on the check it sends. The check asks whether *this
 caller* may use *this admin/PIP surface*, not what the tenant is allowed
 to do on the platform.
 
+## What `tenant` denotes (TEN-DEC-2026-002)
+
+`tenant` is the **target tenant record** — the tenant the action operates on.
+It is *not* the caller's tenant, and on guardrail actions it is not a separate
+"tenant the guardrail applies to": a guardrail is addressed only through the
+tenant it constrains, so that is the same tenant.
+
+`tenant` always equals `resource.id`. That is intended, not incidental: one
+`tenant_id` is copied onto both fields in `authz.FlexAuthWriteAuthorizer`.
+A check where the two differ did not come from this engine.
+
+`tenant` cannot denote the caller's tenant because this service does not know
+it. No inbound token is verified; the acting identity arrives as a
+caller-supplied `actor` string (`tenancy.yaml` I1). There is no caller tenant
+in scope when the check is built.
+
+**The write API is cross-tenant by design. No action in the vocabulary is
+refused on the relationship between `subject` and `tenant`.** The subjects are
+platform service identities in `tenant:platform`; the targets are arbitrary
+tenant records. Creating and retiring tenants cannot be done from inside the
+tenant concerned, and `tenant.create` has no existing target at check time, so
+a same-tenant rule would deny every create. Authorization here is a
+service-identity question over `(subject.id, action)`; `tenant` and
+`resource.id` say *which record* is being touched, for the decision record and
+the audit trail.
+
+`tenant.guardrail.read` does not differ, and must not: flex-auth calls it while
+deciding about arbitrary tenants, so a same-tenant rule on it would break the
+PDP itself.
+
+Varying `tenant` in a conformance fixture must not change the effect. That is
+the assertion this engine wants the published package to make — an unrestricted
+scope that is *stated* is a rule a reviewer can check; an unrestricted scope
+that is merely unwritten is indistinguishable from an omitted one.
+
 Action → resource-type mapping (must match `flex-auth`'s
 `FLEX-WP-0008-T01` vocabulary exactly — coordinate values, don't diverge):
 
@@ -104,6 +139,15 @@ Tests assert the file equals shipped behaviour.
 | `TENANT_ENGINE_FLEX_AUTH_TIMEOUT_SECONDS` | `3` | Bounded timeout on the synchronous path — no retries. |
 | `TENANT_ENGINE_FLEX_AUTH_TOKEN_FILE` | unset | Rotating bearer token file, read on each check. |
 
+## Repository coordinate vs runtime name (TEN-IN-0004)
+
+The `flex-auth` repository is renaming to `access-engine` (`FLEX-WP-0020`).
+**Runtime names stay `flex-auth`** per `FLEX-DEC-2026-013`: the cluster
+namespace, the `flex-auth-tenant-engine` Service, the token audience, and this
+engine's `TENANT_ENGINE_FLEX_AUTH_*` settings are all unchanged by the rename.
+Only the `flex-auth/...` repository paths cited below and above change, and
+only once the rename lands.
+
 ## Related
 
 - `pep-stance.yaml` — published fail-closed map