Sunset Plan: What Happens If You Stop Using Worthune

A vendor relationship the caller can end cleanly is a vendor relationship worth having. This is what ending it looks like.

Procurement teams have learned to ask a specific question during vendor evaluation: what happens if we stop using this vendor. The question is not adversarial. It is a check that the caller’s dependency on the vendor is bounded, that the caller retains the artifacts that matter, and that the offboarding path is real rather than aspirational. This piece is the specific answer for callers considering Worthune as a vendor or for callers preparing to migrate.

What the caller keeps

The specification of every model the caller integrated is public and remains available regardless of the caller’s status with Worthune. Specifications are published at stable URLs; the caller can archive local copies at any time. Every stored envelope the caller retained contains the model name, the specVersion, the inputs, the outputs, the assumptions, the facts referenced with their period and source names, and the SHA-256 record. That envelope is portable data the caller owns.

The published contracts for each model — the input schema and the output schema in machine-readable form — are also public. A caller who wants to migrate to a different implementation of the same spec has, in these artifacts, everything needed to verify that the new implementation reproduces the same behavior against the same inputs. The verification is not a promise; it is a check the caller can run against their own stored envelopes.

What the caller does not carry away

The caller does not carry away the running platform. The API endpoints, the MCP server, and any hosted infrastructure remain Worthune’s to run. A caller who stops using Worthune stops calling the platform; the calls stop being made in the free case, and stop under whatever terms the agreement sets in the Pro or Enterprise case.

The caller also does not carry away the ongoing maintenance of the constants and the specs. If the caller’s use case depends on constants moving with regulatory changes, either the caller’s replacement vendor takes over that maintenance, or the caller’s internal team does. The specification of the current behavior is public; the ongoing maintenance is a service, and services are what vendors provide.

The offboarding path

A specific offboarding for a caller currently in production looks like this. Days one to fifteen: the caller archives local copies of the specifications, the contracts, the current facts registry rows the caller depends on, and the current changelog for each model in use. This is a defensive step regardless of the caller’s exit direction; it locks in the artifacts as they exist at the time of the decision.

Days fifteen to thirty: the caller identifies the replacement path for each model. The replacement may be another vendor implementing the same specifications, an internal implementation the caller builds against the archived specs, or a decision to retire the calculator entirely. Each replacement path has different verification requirements. A different vendor’s implementation needs to be run against the caller’s stored envelopes to confirm it reproduces the same outputs. An internal implementation needs the same verification. A retired calculator needs a migration plan for users who were relying on it.

Days thirty to sixty: the caller runs the replacement in shadow mode against the current Worthune calls. Every user-visible call goes to both implementations; the caller compares the outputs, logs any differences, and diagnoses the causes. Discrepancies at this stage are the reason shadow mode exists; they are almost always the caller’s replacement implementation not honoring some aspect of the spec, and the discrepancies point at the specific corrections needed.

Days sixty to ninety: the caller cuts over. The replacement implementation becomes the primary; Worthune calls are removed from the code path. Stored envelopes from the Worthune period remain in the caller’s database, still valid and still recomputable against archived specs if the caller ever needs to defend a past answer.

1. Days 1–15

   Archive local copies of specs, contracts, facts rows, and changelog entries.

2. Days 15–30

   Identify replacement path for each model; different vendor, internal implementation, or retirement.

3. Days 30–60

   Run replacement in shadow mode; compare outputs; diagnose discrepancies.

4. Days 60–90

   Cut over; remove Worthune calls; retain stored envelopes for historical reference.

5. Ongoing

   Historical stored envelopes remain valid and auditable against archived specifications.

The reason the exit is designed this way

The portability posture is not a marketing choice; it is what a published-contract platform produces by construction. A model whose specification is public and whose behavior is version-pinned is a model any competent engineering team can reimplement. A model whose interface is proprietary and whose behavior is opaque is not. Worthune’s design chose the first shape because the second shape produces the kind of vendor relationships that procurement teams learn to be cautious of.

The design also reflects a specific commercial posture. A platform whose exit is clean is a platform that has to keep earning the caller’s use. That is the intended dynamic. Callers who stay with Worthune are staying because the ongoing maintenance is worth the relationship, not because leaving is expensive. The pricing durability commitment on the pricing page — nothing that was free moves behind a paywall — is the same posture applied to pricing. The sunset plan is the same posture applied to offboarding.

What replaces Worthune, in the abstract

A caller exiting Worthune has three general replacement categories. The first is another verified-model vendor whose catalog includes the same specifications. This is the most direct replacement and typically the least engineering work; the caller substitutes the endpoint and re-verifies the envelopes. The second is an internal implementation against the archived specs. This has more engineering work up front and moves the maintenance calendar back inside the firm; it is the appropriate choice for callers whose specific needs no longer align with any vendor. The third is retirement of the calculator surface entirely. This is the appropriate choice when the calculator was providing marginal value and the exit is a natural point to remove it rather than migrate it.

Each replacement has its own verification requirements; the Vendor Risk Interview Kit for Model Vendors (/writing/vendor-risk-interview) is the working list for evaluating a different-vendor replacement. Callers who are exiting Worthune to move to a different verified-model vendor should run the kit against the new vendor with the specific answers Worthune produced as reference points; the comparison is more informative than the kit run against either vendor in isolation.

The one thing exit does not restore

The one thing an exit does not restore is time. The engineering hours the caller invested in integrating Worthune — the UI patterns, the envelope storage, the compliance surface, the show-your-work display — remain the caller’s. They also do not need to be redone at exit; a replacement vendor honoring the same specs uses the same UI patterns, the same storage schema, and the same audit surface. The exit is a substitution at the API layer, not a rewrite of everything above it. This is the specific technical shape that makes the exit tractable.

“The exit is designed. The design is what makes the vendor relationship a real relationship rather than a captive one.”

For procurement and legal specifically

Procurement and legal teams evaluating Worthune can incorporate this piece into the documentation package. The specific commitments — public specifications, portable envelopes, machine-readable contracts, durable free tier — are what the caller’s vendor-risk framework should verify against the current product and pricing pages at the time of contracting; the offboarding path above is a working template, not a published commitment. The commitments described here reflect the state as of this writing; procurement teams should confirm each commitment against the live pages before relying on this piece as documentation.