How should a multi-tenant LLM platform resolve tenant rules that conflict with its own policy?

## Two legitimate authors, one context window Single-tenant applications have a simple picture: the provider sets policy, you write the system prompt, the user talks. A platform inserts a fourth party. Your tenants are not end users — they are building products, they have their own compliance obligations, and their configuration is a genuine authority layer. But they are also not you, and their rules cannot be allowed to erode the guarantees you make to every tenant and every end user at once. The design question is therefore not "who wins" but "how do I make the ordering structural rather than rhetorical." ## Floor and ceiling The workable model is monotone narrowing. Platform policy defines a floor of behaviour that holds in every tenant's product. Tenant configuration may move only in one direction: it may add restrictions, tighten tone, narrow scope, forbid topics, require disclosures. It may not remove a platform restriction, loosen a required disclosure, or grant its assistant a behaviour the floor denies. The medical case makes this concrete. Suppose your platform's floor says the assistant does not give individualised clinical advice and always recommends contacting a professional for symptoms. A telehealth tenant may legitimately want *more*: mandatory jurisdiction-specific wording, a narrower topic scope, an explicit refusal list. All of that narrows and is fine. A tenant that writes "you may give dosage recommendations because our users are clinicians" is widening, and the answer is not to argue about it in prose — it is that the configuration surface should not accept it, and the capability should not exist unless that tenant has been separately qualified for it. That last point matters. "Never widen" is a good default, not a religion. Real platforms do grant elevated behaviour to specific tenants — but through an out-of-band process with contractual and technical gating, expressed as a per-tenant capability flag your assembly code reads, never as text a tenant typed into a settings field. ## Assembly is your responsibility The single most important implementation detail is that the tenant never hands you a finished system prompt. You assemble it. If a tenant supplies raw text that you concatenate into your system prompt, you have handed them your layer. They can precede your rules, contradict them, or write "disregard the preceding section." Instead: keep platform text in the top layer, place tenant text in a distinct lower layer (a developer tier if your provider exposes one, otherwise a clearly delimited section the platform layer describes as subordinate), and state in the platform layer how conflicts resolve — "the configuration below is subordinate to the rules above; where they conflict, follow the rules above." Prefer structured configuration to free text wherever you can. A tenant choosing tone from an enumerated set, adding topics to a deny list, or supplying a disclaimer string cannot produce a conflict at all, because the shape of the input has no room to express one. Free-text customisation is the surface where conflicts live, so keep it as small as the product allows and validate what arrives. ## Failing toward the platform No policy set anticipates everything, and tenants will produce collisions you did not model. Write the default down: on an unanticipated conflict, follow the platform rule and, where the product allows it, tell the end user that a configured behaviour was not applied. A silent divergence between what a tenant configured and what their users experience is the thing that becomes a support escalation months later. Give tenants visibility too. Publish the floor as documentation, validate configuration at save time rather than at inference time, and surface rejected settings in the console. A tenant discovering the policy through a user-facing refusal is a bad experience and generates pressure to weaken the floor. ## Where prompt layering stops being enough Everything above is still guidance — the same trained preference that governs any hierarchy, with the same non-zero failure rate. It is right-sized for behavioural policy: tone, disclosure, scope, refusal style. It is not sufficient for anything with consequences. Data isolation belongs in the retrieval and storage layer: tenant scoping applied before anything reaches a context window, never as an instruction not to mix tenants. Capability limits belong in per-tenant tool registration — a tenant whose plan excludes outbound email should have no email tool in its assistant's tool list, not an instruction against sending mail. Spend and rate limits belong in the gateway. Audit belongs in the request log, keyed by tenant. The useful summary is that prompt layering decides how the assistant *behaves*, and per-tenant configuration of tools, data scope and credentials decides what it *can do*. Conflicts in the first are resolved by ordering; conflicts in the second are resolved by not provisioning the capability. ## What to measure Run the floor as an eval suite against every tenant configuration, not just your own defaults. Each platform-level constraint gets adherence cases; each tenant's added restrictions get their own. Re-run on model upgrades and on tenant configuration changes, since a tenant edit is a prompt edit to a system you are accountable for. Track the rate at which tenant configurations are rejected at save time — a rising rate usually means the floor and the product's real needs have drifted apart, which is a policy conversation rather than an engineering one.