The Integration Preflight Checklist

Each item on this list is a one-line version of a failure mode covered somewhere in this library. The list is for the week before production; the linked pieces are for when a box will not check.

An API integration is done when nobody thinks about it anymore. For a verified-math dependency, getting there means closing out six areas: the contract, validation, the envelope, versioning, operations, and attribution. This is the consolidated preflight — thirty-three checks, grouped by the question each area answers. Teams that have followed the individual guides will find nothing new here except the compression; teams starting cold can work the list and follow the pointer wherever a check fails.

The contract: are you calling what you think you are calling

• ✓The model name exists in the live catalog at /models.
• ✓The machine contract at /api/v1/models/{name} has been fetched and read, not inferred.
• ✓Every input is supplied explicitly — the API has no optional inputs and no defaults, so your caller owns every value it sends.
• ✓Rate units match the contract — most models take decimals (0.04, never 4), and the exceptions (divorce, eldercare, estate-planning) take percent points and say so in their constraint notes.
• ✓Field names match the contract exactly — unknown fields are rejected, which makes typos loud early.
• ✓The spec behind the contract has been read once by a human who owns the integration.

Validation: rejection as UX, not as surprise

• ✓Form controls are constrained to the published domains, so most users cannot express an invalid request.
• ✓Server-side rejections map field errors to controls one-to-one.
• ✓Error messages render verbatim — they are written to be user-grade.
• ✓Nothing client-side clamps or adjusts a value the user did not choose.
• ✓Cross-field rules from the contract's constraints are represented in the UI, not discovered in production.
• ✓Out-of-scope questions get honest copy, not a forced answer.

The envelope: evidence, stored

• ✓The five columns exist: model, specVersion, inputs, outputs, record_sha256.
• ✓Envelopes are written when an answer is shown, exported, or acted on — not on every keystroke.
• ✓The hash is re-verified once at write time.
• ✓User identity lives outside the envelope row, joined by your keys.
• ✓Retention matches your records schedule, decided with whoever owns that schedule.

Versioning: drift is detected, not discovered

• ✓A fixture stores inputs, outputs, specVersion, and record.sha256 for a handful of cases per model.
• ✓CI asserts version first, hash second, on a schedule — not only on push.
• ✓At least one fixture case exercises a triggered sentinel.
• ✓The changelog at /models/changelog is bookmarked by a named owner who reads version bumps.
• ✓Fixture updates land as dedicated commits linking the changelog entry.

Operations: the five metrics and the two numbers

• ✓Logs carry envelope metadata — model, specVersion, ok, triggered sentinels, record hash, latency — and never raw inputs.
• ✓Alerts exist for sustained 429s, error-rate spikes by field, and an observed specVersion differing from the pinned one.
• ✓429 handling honors the retry-after header, and nothing auto-retries a validation failure.
• ✓Interactive controls are debounced so a slider cannot become a request stream.
• ✓Any caching keys on model plus specVersion plus inputs, and invalidates on version change.
• ✓No constant has been copied out of a response into code — constants stay in the facts registry where they carry period and source.

Attribution and terms: the two-minute legal check

• ✓If API or MCP results are shown to end users, a visible Powered by Worthune with a link is present.
• ✓If embeds are used, the badge is intact and unobscured at every breakpoint.
• ✓Internal-only and evaluation use carries no obligation — confirm which category each surface is.
• ✓The pricing page has been read by the person who owns the vendor relationship — the terms are short and written down.
• ✓Monthly volume is glanced at against the 5,000-run fair-use guideline — a guideline, not a meter.

Sign-off

Two checks remain that no list can automate. First, a named person owns this integration — the changelog reader, the fixture updater, the one paged when the hash alert fires. Integrations without an owner decay into exactly the unmonitored dependency this list exists to prevent. Second, someone has run the whole flow as a user — typed an out-of-range age, seen the message, hit a sentinel case, read the answer — because a checklist proves the mechanics and only a walkthrough proves the experience. When both hold and every box above checks, ship it, and enjoy the specific pleasure of a dependency that never makes the incident channel.