Define the versioned prediction HTTP service data contract

Make malformed input fail before it reaches the interesting algorithm. The accepted contract is JSON containing a finite numeric features array of length two. This boundary matters because schema drift, model load failure, slow requests, leaking input data to logs, and a release whose error rate exceeds the rollback trigger; allowing a bad value through makes later debugging look like an algorithm problem. Keep transformation functions separate from scoring or prediction so a test can identify which boundary changed the data.

The artifact's user-facing goal is specific: put a tested threshold model behind a stable JSON boundary with health, prediction, metrics, and rollback behavior. Its accepted input is JSON containing a finite numeric features array of length two. Those statements are intentionally narrower than “build an AI system.” Narrow scope lets us inspect every input and expected result, and it prevents a toy result from being presented as a production claim. The example implements or probes the input boundary. Copy it into a fresh file and run it without extra packages.

Save this as lesson.py and run python3 lesson.py. It uses only the language standard library, so the example is reproducible offline.

import math
def validate(p):
 x=p.get('features');
 if not isinstance(x,list) or len(x)!=2 or not all(isinstance(v,(int,float)) and math.isfinite(v) for v in x): raise ValueError('features: two finite numbers')
 return x
print(validate({'features':[.8,.3]}))

Expected output: [0.8, 0.3]. Exact floating-point formatting may vary slightly, but the asserted behavior must not. Read the output as evidence about this stage, not merely proof that the interpreter started.

Reproduce a bad request with curl, then inspect validation outcome, status code, model version, and duration. Do not send malformed data into predict and do not turn validation failures into HTTP 500. Compare candidate and stable predictions on the same canary payloads. A health endpoint proves the process is responsive; it does not prove prediction quality or model loading unless those checks are explicit.

At the data contract stage, save the smallest failing fixture beside the expected result. Change one cause at a time and rerun the exact command printed above; that makes the repair reviewable and keeps this chapter's progressive artifact reproducible.

Run contract, malformed-input, health, and smoke tests against the packaged service. Record p95 latency, validation-error rate, server-error rate, model version, and canary disagreement. Trigger a rehearsal rollback when disagreement exceeds the documented threshold. Verify the previous artifact actually starts; a rollback name in a checklist is not recovery evidence.

For this data contract page, preserve the fixture and result as evidence for the next page. Label observations separately from conclusions: a passing assertion establishes the behavior it names, while broader usefulness requires the chapter's full evaluation set and stated operating limits.