diff --git a/docs/tenant-claim-contract.md b/docs/tenant-claim-contract.md
index 0c917c7..1c013e0 100644
--- a/docs/tenant-claim-contract.md
+++ b/docs/tenant-claim-contract.md
@@ -202,6 +202,29 @@ from that is the consumer's call — gate-house explicitly did **not** rule on
 whether approval-engine's exact-match admission is the right gate. Carrying
 provenance makes that question answerable; it does not answer it.
 
+**What approval-engine's check actually asks, in their words.** Asked which
+resolution they wanted, approval-engine chose the registration-bound shape and
+stated the limit that makes it admissible for them, which they asked to be
+carried here so it cannot be over-read later:
+
+> Their tenant comparison is **store isolation**. It answers *does this caller
+> belong to the store this engine serves*, not *is this human a member of the
+> platform zone*. For that question a registration-supplied tenant is admissible:
+> admission means arriving through a channel the platform registered, and the
+> approver client is static and deployment-owned.
+>
+> **A registration-supplied tenant is not admissible for any doctrine that turns
+> on the approver's own membership.** "An approver must be a member of the
+> platform zone" is a fact about the person, and this claim cannot carry it. No
+> such doctrine exists today. If one is issued, it needs a directory-sourced
+> claim — and an exact-match check does not become that claim merely by matching.
+
+That is the same conclusion as GH-DEC-2026-013 §1 reached independently from the
+consuming side, and it is the practical reason `tenant_source` exists: a consumer
+whose check means *store isolation* can accept `registration`, and a consumer
+whose check means *membership* must require `directory`. The claim does not know
+which question is being asked; the consumer does.
+
 `tenant_source` is advertised in `claims_supported`, and
 `TestIssuedTokensCarryTenantProvenance` asserts it reaches issued tokens on both
 grants, including the unasserted-default case.