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? Every model's input contract — inputs, domains, sentinels — is public. The three sample models (emergency-fund, relocation, side-business) have fully public specs at worthune.com/docs/models/{model}; the full catalog's specs ship with a Pro key. Every API response links its own spec via specUrl (the API's spec endpoint), and each spec carries formulas, assumptions, exclusions, known issues, and its changelog.

Q2 — How is implementation correctness verified? Concordance testing: an independent second implementation, written from the published spec alone, must agree with the production engine on 250 cases per model — at one-part-in-a-billion tolerance — before any release. The sample models' eval datasets are fully public at /api/v1/evals/{model} (the full catalog's ship with a Pro key), 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), its check date against the primary source, 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-plan guarantee, per the pricing page.

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 input contracts for every model, fully public sample specs and eval datasets, 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? Published in full on the pricing page, with prices rather than invitations to talk. Three sample models are free to call with attribution, no signup and no key, and the household engine is free to run for as long as you do not ask us to store anything — no key there either. Model runs are never metered at any tier, which is a written commitment rather than a current generosity. Paid plans are $495 and $1,995 a month, and what they buy is state: households we keep, with an id, the API around them, bulk import, webhooks and drift detection. A plan meters active households, not calls, and the per-household rate above the included allowance is published too.

Q10 — What is the exit path? Every model's input contract is public, and the sample models' specs and eval datasets are fully public (the full catalog's ship with a Pro key); stored envelopes are self-describing and verifiable without us; the 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.