A practice group's provisioning client sends SCIM 2.0 writes that RFC 7644 does not describe — which divergences do you absorb, and which do you refuse?

## The asymmetry that makes this a judgement call Every other decision on this endpoint has a right answer in a specification. This one does not, because of who is on the other end. The SCIM client pushing dentists and hygienists into your radiography viewer belongs to the customer. You cannot ship it a fix on your schedule. You can ask the customer's administrator to reconfigure it, and sometimes that is the only correct answer, but it has a cost measured in renewal conversations rather than in engineering hours. What the customer experiences when you refuse is not "our identity system is non-conforming". It is "the viewer is broken". So the question an interviewer is really asking is whether you can distinguish the divergences that are cheap to absorb from the ones that will quietly damage your data, and whether you have a mechanism rather than a reflex. ## A test for absorbing Absorb only when **all four** of these hold: 1. **Unambiguous.** There is exactly one thing the client can mean. A `remove` whose path is absent fails this immediately: it might mean clear that attribute, or it might mean the client built the document wrong and the intended target is anyone's guess. 2. **Invisible to conforming clients.** Handling it changes nothing another customer's client observes. A normalisation that alters what you return to everybody is a protocol change wearing a workaround's clothes. 3. **Expressible at the edge.** It can be a rewrite applied to the request before your domain sees it — a case fold on an `op` value, an array accepted where a single object was expected — rather than a conditional threaded through your persistence code. A divergence that reaches storage is one you will be unable to remove. 4. **Scopeable.** The credential the write arrived on already resolves one tenant, so the rule can apply to that tenant alone rather than becoming global behaviour that a future conforming client inherits. ## A test for refusing Refuse, and mean it, when any of these hold: - **The intent is ambiguous.** Two readings, one of which removes a person's access to clinical images, is not a coin to flip. - **Absorbing it loses data.** Accepting a membership document whose shape you half-understand, and writing the part you did understand, produces a group that is wrong in a way nobody can detect from either side. - **It would make you guess about access.** Who may open a patient's radiographs is the customer's decision expressed through their identity system. If their write does not say, the answer is not a default. - **It is a client bug that will be fixed.** Absorbing it removes the pressure that would have fixed it, and you now own it forever. And refuse *legibly*. A 400 with `scimType` and a `detail` naming the operation and the attribute is what lets a support engineer, reading a ticket three time zones away, tell an administrator what to change. A refusal nobody can diagnose is functionally the same as an outage. ## Who decides, and who enforces It is worth being precise about the parties, because this is where the reasoning usually slides. **Your endpoint** enforces: it applies the write or returns an error. **Your product** decides which divergences the endpoint will tolerate, and that decision is made once, deliberately, not per incident. **The customer's identity system** decides what to send, and neither of your two roles can change that. A design that blurs the first two acquires a conditional per customer; a design that forgets the third builds a support process around asking people to do things they cannot do. ## The estate over years The tenth divergence does not cost what the first did. Keep them as data rather than as code paths scattered through a handler: 1. A single normalisation layer at the request edge, with one named rule per divergence. 2. Each rule recorded with the client kind it addresses, the date, the tenant that forced it, and the ticket. 3. A test per rule that pins both the divergent input and the conforming input, so nobody "fixes" a rule back into a bug. 4. A review that asks, on a cadence, whether each rule is still needed — clients do get updated, and a rule whose tenant left two years ago is pure carrying cost. Without that, the normalisation layer becomes archaeology: nobody knows which conditional is load-bearing, so nobody removes any of them, and the endpoint's behaviour is no longer describable in the discovery documents you publish. That is the real long-term failure — not a wrong branch, but a contract you can no longer state. ## The answer that shows seniority The weak answer is either extreme: "we conform strictly and it is their bug", which loses customers, or "we accept whatever arrives", which loses the ability to reason about your own data. The strong answer names the asymmetry, gives a test with a short list of conditions, insists the refusals be diagnostic, and treats the accumulated divergences as an asset with a maintenance cost and an owner.