The Vendor Due-Diligence Questionnaire, Answered

The vendor-risk interview kit in this library tells buyers what to ask. This piece is the other side of the table: the answers, in public, so due diligence can start from artifacts instead of email.

Due-diligence questionnaires vary in template and not much in substance: how is correctness assured, where do the constants come from, what changes without warning, what records exist, what happens if we leave. Worthune's answers do not vary by asker, so publishing them is cheaper for everyone — and more honest, because a published answer can be checked against the artifact it cites and cannot be quietly tuned per prospect. Here are ten questions — the interview kit's core set (/writing/vendor-risk-interview), plus the attestation and data-retention questions security reviews always add — answered.

The answers

Q1 — Where are the model specifications? Public, per model, at worthune.com/docs/models/{model}, and linked from every API response via its specUrl (the API's spec endpoint). Each spec carries formulas, assumptions, exclusions, known issues, and its changelog.

Q2 — How is implementation correctness verified? Dual implementation: an independent second implementation, written from the published specs alone, runs against 250 verification cases per model on every release, and releases gate on agreement within a stated tolerance. The same vectors are public at /api/v1/evals/{model}, so this answer is re-runnable by the asker.

Q3 — Where do regulatory constants come from? A public registry at /facts and /api/v1/facts in which every constant carries its primary source, its period, its jurisdiction (US-federal only, stated), a verification date, and an honest status — including historical rows kept for the record and, where it has happened, notes documenting corrections.

Q4 — What does a response contain? The full envelope: ok flag, model, spec version, contract and spec URLs, echoed inputs, outputs, sentinel annotations, assumptions, cited constants, a SHA-256 record over model-version-inputs-outputs with its verification recipe, and a disclaimer.

Q5 — What changes, and how do we find out? Behavior changes only with a spec-version bump, recorded in the public changelog at /models/changelog. There is no notification service; the documented pattern is a CI fixture that fails your build on drift. Patch releases can carry BREAKING contract changes (dead-input removals) — the changelog entry, not the version arithmetic, is the authority. Corrections to model behavior ship the same way: a version bump with an entry stating what was wrong and what changed, and each spec documents its known issues in the spec itself.

Q6 — Can we pin a version? Drift detection is free by construction — every envelope carries its specVersion and hash. Committed version pinning is a paid-tier guarantee, per the pricing page, on design-partner terms.

Q7 — What operational attestations exist? None are published today — no SOC 2, no ISO certification. What exists instead is unusually deep artifact-level verifiability: public specs, re-runnable validation vectors, public aggregate telemetry with an aggregate-only privacy posture, and the hash-verifiable envelope. Firms whose vendor policy requires attestations should weigh that trade explicitly; we state it rather than imply otherwise.

Q8 — What data do you retain about our calls? The telemetry store keeps aggregate counters only — per-day, per-surface, per-name hits and errors: endpoints, and for embeds the embedding site's hostname (no paths); no IPs, no user agents, no inputs — and the same aggregates are public at /api/v1/telemetry. Model inputs are computed on and echoed back, not retained as user records on our side; the stored-envelope discipline lives in your store, under your control.

Q9 — What are the commercial terms and their durability? Free with attribution, in writing on the pricing page: the models, API, MCP server, and embeds stay free; fair use is a 5,000-runs-per-month guideline, not a meter; paid tiers add guarantees and never take back what is free. No dollar prices are published — Pro and Enterprise are design-partner conversations.

Q10 — What is the exit path? The specs are public documents; stored envelopes are self-describing and verifiable without us; eval datasets let a replacement implementation prove equivalence case by case. The sunset-plan piece (/writing/sunset-plan) walks the full offboarding template — which is a working template, not a contractual commitment, and says so.

What updates this page

These answers describe the platform as it ships today, and they change the way everything here changes: visibly. A published attestation would appear here and on the pricing page; a new retention behavior would appear in the telemetry endpoint's own privacy line; altered terms would appear on the pricing page whose durability language is the standing constraint. A diligence file built on this page should record the date of capture — and the annual-review discipline (/writing/annual-model-review) is the natural cadence for re-capturing it.