Can Another Program Use Botie’s Answer?

Botie replies, “P-2 probably needs its seal checked.” A technician can understand the sentence. A program that sorts inspection suggestions now has to guess where the asset ID ends and the recommendation begins. Another response might use an entirely different sentence.

We can ask for named fields and validate them before the next component uses them. This solves a problem about the shape of the answer. Whether a seal inspection is justified still depends on the evidence.

Try a known asset, an unknown asset, and a response whose diagnosis has the wrong type. The two output flags answer different questions.

For this exercise, a response is an object with exactly two fields: asset and diagnosis. Each must contain nonempty text. That is a deliberately small interface. In a real maintenance assistant we might also require source IDs, an uncertainty status, and the document version used.

An object maps names to values. In Python, a dictionary is the structure we will use for that mapping. Names avoid relying on word order or position in a sentence. They also let a validator point to a particular missing or malformed value.

An empty diagnosis is rejected here. Another application could permit null for an explicitly unknown diagnosis, but it must define what null means.

Parsing converts a JSON string into a Python value. A valid JSON string could describe a list, a number, or an object with unexpected fields. The parser does not know which of these our application requires.

Validation checks the parsed value against our contract. Does it have exactly the expected keys? Is each value text? Does the text contain something other than whitespace? We keep these checks explicit so a reader can see what they establish. Some libraries convert values while validating; strict validation may be preferable when a number should not silently become an identifier.

Malformed JSON is a parsing error. A diagnosis containing a number is a schema error. Report the distinction when it helps someone repair the response.

import json
reply = json.loads('{"asset":"P-2","diagnosis":7}')
print(type(reply).__name__)
print(isinstance(reply["diagnosis"], str))

dict
False

Our exact-key check rejects a missing field and an unexpected field. The two text checks reject numbers, nulls, and blank strings. Join those checks with logical and: all must pass.

We intentionally do not coerce a diagnosis of 7 into the string “7”. That would hide a response that did not follow the requested meaning. Keeping the checks separate also makes the workshop easier to inspect: disconnect the text branch and the numeric diagnosis case exposes the missing validation.

Required keys = {asset, diagnosis}
Schema valid = exact keys AND nonempty asset text AND nonempty diagnosis text

The resulting flag describes this contract only. It does not promise compliance with a larger schema that we never checked.

Suppose asset is “P-9” and diagnosis is “seal wear”. Both values are text, and the keys are correct. If the registry contains only P-2 and P-3, the asset lookup should fail. That is an application-level check using external knowledge.

Even a registered P-2 may have a healthy seal. The source might discuss a different symptom or describe a general possibility rather than a finding. To check factual support, compare the claim with the cited evidence and the scope of the question. The schema cannot do that for us.

The workshop returns schema_valid and asset_known separately. That makes it possible to see a structurally valid response about an unavailable asset.

A provider may refuse a request or stop before a complete answer is available. A network error may return no model output at all. These cases should not be passed into the diagnosis parser as though they were ordinary candidate records.

When a schema check fails, a bounded retry can tell the model which field needs repair. Keep the original error and response for permitted debugging. A retry is another model request with cost and latency; it is not evidence that the eventual answer is factual. If the retry limit is reached, return a clear failure state.

Provider features for constrained generation differ. Check their supported schema subset and failure modes instead of assuming every JSON Schema keyword is enforced.

Imagine adding urgency next month. An old caller expecting exactly two keys may reject the new record. A new caller may require urgency and reject old saved answers. Version the interface or arrange a compatibility period deliberately.

Use test records from both versions when changing the validator. Include values at the boundary, such as an empty string, a missing field, and an unfamiliar asset. These cases often explain an integration failure more clearly than a long successful example.

The following Python function returns both check results and leaves the caller to decide what to show. It performs no scheduling action.