Model and Tool API Contracts
Suppose another program calls our pump model. Which readings does it need to send, and what should happen if they are missing? We’ll work out that agreement, give it a form both programs can check, then test what happens as either program changes.
Describing a model request
The model expects named measurements. We need to agree on which ones are required and what their values mean before two programs can exchange them.
- 01Ready to exploreDid the Caller Leave It Out, or Send No Reading?
Give absent measurements, explicit nulls and real zeroes different meanings before a request reaches the model.
- 02Ready to exploreYesterday’s Client Still Sends the Old Request
Introduce a new request shape without guessing what an older client meant or silently changing its results.
- 03Ready to exploreThe Number Was Valid, but It Meant Something Else
Keep units and score direction attached to numerical values before reusing fitted preprocessing or ranking evidence.
Handling and testing tool outcomes
What should an agent do when a tool times out? It depends on whether the tool did anything before the connection failed. We’ll represent that difference and write tests for it.
- 04Ready to exploreShould Botie Repeat the Request, or Find Out What Happened?
Give callers stable failure types, bounded retry rules and a separate path for operations whose outcome is unknown.
- 05Ready to exploreOne Correct Prediction Did Not Test the Interface
Turn expected relationships between requests into tests, then retain the small example that exposed a broken contract.