A cluster of distributed-operation TCs assume forward behaviour the spec doesn't mandate; the broker is spec-correct in each. Each needs the test author to pick the intended behaviour: - **D011_03_inc/D011_04_inc** — `?id=urn:…` alone is rejected as an insufficient selector (TS 104-175 § 10.4.3.4 enumerates 5 sufficient selectors; `id` alone is not one). Add `&type=Vehicle` or use `GET /entities/{id}`. - **D002_02_01_inc / D002_02_02_inc** — inclusive Delete Entity where one leg 404s: the tests expect a 207 BatchOperationResult surfacing that 404; the broker returns 204. **TS 104-175 § 10.2.8.4 backs the broker** — ResourceNotFound is reserved for total absence ("no existing Entity held locally **and no matching registrations apply**"), and the inclusive forward is defined as "remove the entity locally *if it exists*". So a 404 from an inclusive source — which need not hold every entity of a registered type — is simply not in the error model. The only text pointing the other way is the **coarse HTTP-binding § 6.3.5** ("inclusive + an error response from one or more sources → 207"). **Spec ask:** reconcile § 6.3.5 with § 10.2.8.4 — a benign Not-Found from an inclusive source (entity legitimately absent there) is *not* a reportable error; reserve 207 for genuine failures (5xx / timeout / conflict). Tests corrected to expect 204. - **D003_01_exc** — Append-Attrs forwarded as `application/json` with no Link header, so attribute names don't expand to the CSR's @context. - **D004_01_exc** — PATCH-attrs body carries an `id` not matching the URL id (§10.2.3 — URL id wins). - **D007/D013/D016** — assertions do a @context-rigid dict compare that is self-defeating across brokers.