Say that the explanation refusal belongs to one deployment

docs/about/architecture.md

@@ -558,9 +558,16 @@ build:
 | `multiclass_classification` | `prediction`, `probabilities` |
 
 So `scores`, `rankings`, `embeddings` and `explanation` are declared by the
-client and refused by that deployment on every task. `rankings` is the one
-that still works end to end: `RANK TOP k` is decomposed into a classification
-per candidate, so the ranking is assembled here rather than asked for.
+client and refused by that deployment on every task. That is a fact about this
+build, not about the fields: `explanation` has been measured working against
+another relational deployment, which returns an explanation the client parses
+and hands back on `PredictionResult.explanation`. A deployment that refuses it is
+narrower than the model family, not the client declaring something nothing
+serves.
+
+`rankings` is the one that still works end to end against the narrower build:
+`RANK TOP k` is decomposed into a classification per candidate, so the ranking
+is assembled here rather than asked for.
 
 `forecasting` and `temporal_link_prediction` are declared as tasks and are not
 served either — a forecast is sent as a regression per step, and a bare

packages/structured-data-models-client/src/sdm_client/models.py

@@ -128,12 +128,9 @@
                 'explanation',
             }
         ),
-        # Empty, and not because the model does not explain. Nothing on this
-        # client takes a format argument, the contract's `OutputSpec` is only
-        # `{fields: [...]}`, and the endpoint stamps its own name on what it
-        # returns: `kumo_rfm_v2_1` from the shipping build. Two names were
-        # declared here that appear in no response on any task or graph, which
-        # is a list of formats to ask for on a surface that has no such knob.
+        # Empty because nothing here takes a format argument: the contract's
+        # `OutputSpec` is only `{fields: [...]}`, and the endpoint names the
+        # shape it returns. Two names declared here appeared in no response.
         explanation_formats=(),
         limits=RELATIONAL_LIMITS,
         unread_feature_stypes=frozenset({'text'}),

packages/structured-data-models-relational-engine/tests/client/rfm_nim_payloads.py

@@ -112,7 +112,7 @@
 
 
 def nim_v1_smoke_payload() -> dict[str, Any]:
-    """Payload mirrored from kumo_rfm_nim/scripts/run_container_smoke.sh."""
+    """Payload mirrored from the relational NIM's container smoke test."""
     return deepcopy(_NIM_V1_SMOKE_PAYLOAD)
 
 

scripts/check_repo_hygiene.py

@@ -93,6 +93,10 @@
     # ships either way.
     re.compile(r'\btfm-serving\b', re.IGNORECASE),
     re.compile(r'\bstructured-data-nims\b', re.IGNORECASE),
+    # A workspace inside that repository. The bare `rfm_nim` names the model
+    # a test talks to and stays; this is a path into a tree nobody outside
+    # can open, which is what shipped in a docstring until it was removed.
+    re.compile(r'\bkumo_rfm_nim\b', re.IGNORECASE),
     # Internal build names for the servers behind a model id. A reader
     # cannot look either up, and which build answers is not the client
     # story. The public repository and the five distributions it publishes

skills/relational/SKILL.md

@@ -49,7 +49,10 @@ serves `prediction` and `quantiles` on a regression, `prediction` and
 ```
 
 So ask for an explanation, catch the refusal, and fall back. Do not build a
-flow that assumes one arrives.
+flow that assumes one arrives. Do not assume one never does either: another
+relational deployment serves `explanation`, and the same code gets a parsed
+one back there, so the refusal belongs to the deployment and not to the
+request.
 
 The task is not an argument. It follows from the query: see
 [`pql.md`](pql.md).