"What Should We Embed First?" Decision Wizard

Callers evaluating a catalog of models often ask which one to start with. The answer depends on what the caller is trying to prove, not on which model is most complete.

A team evaluating a verified-model catalog for the first time usually asks the same question: which model should we integrate first? The answer is not the same for every caller. A team trying to prove out the integration mechanics wants a model with a short input list. A team trying to prove out user value wants a model whose output moves a real decision. A team trying to prove out defensibility wants a model whose sources are the ones a reviewer will ask about. This wizard is the six-question decision aid the caller’s product lead can walk in half an hour to route to a defensible starting point.

The six questions

Q1. What is the caller trying to prove with the first integration? Options: (a) that the integration mechanics work end-to-end; (b) that user value is visible; (c) that defensibility survives a compliance review; (d) that a specific product feature is now unblocked. The answer here shapes which of the subsequent questions carries the most weight.

Q2. Which surface will the first calculator appear on? Options: (a) a marketing site or content page; (b) an authenticated product surface; (c) an AI assistant; (d) an internal tool. Each surface has an integration pattern that matches (embed widget — one div and one script tag via embed.js — backend API, MCP server, and backend API respectively), and the first-integration choice is faster if the surface and the pattern are aligned.

Q3. What is the caller’s risk tolerance for the first user-visible answer? Options: (a) low — users will act on the answer immediately; (b) medium — users will consider the answer alongside other information; (c) high — users are exploring, not deciding. Low tolerance argues for calculators whose outputs are less consequential per interaction; higher tolerance permits more consequential calculators for the same integration effort.

Q4. Which audience is the primary user of the first calculator? Options: (a) consumers with no financial background; (b) consumers with moderate literacy; (c) advisors or professionals; (d) internal teams. Each audience has different expectations about how much explanation surrounds the answer and how sophisticated the underlying model can be.

Q5. What is the caller’s existing capability? Options: (a) the caller has a UI team that can build a custom surface around the API; (b) the caller has a content team that can place a calculator on an article page; (c) the caller has an engineering team building an assistant; (d) the caller has all of the above and is choosing where to start. This question filters which integration patterns are available on realistic timelines.

Q6. Which specific decision does the caller’s target user need help with today? Options: (a) a housing decision; (b) a retirement or saving decision; (c) a debt or lending decision; (d) an insurance decision; (e) a tax or contribution decision; (f) something else. This is the question the wizard uses to route to a specific model in the catalog.

• ✓Q1. What are you trying to prove?
• ✓Q2. Which surface will it appear on?
• ✓Q3. What is the user’s risk tolerance?
• ✓Q4. Who is the primary user?
• ✓Q5. What team capability do you have?
• ✓Q6. Which decision does the user need help with?

How the routing works

The wizard does not produce a single recommendation from a scoring function; it produces a short list of candidates from the catalog that match the answers. An interactive version could filter the live model catalog by the caller’s answers to Q2 through Q6 and rank by the answer to Q1. The article version of the wizard walks the questions and lists candidate patterns rather than specific model names, since the shipping catalog changes and the article should not.

Common routing patterns

Callers whose primary goal is to prove out integration mechanics (Q1 = a) tend to succeed fastest with a small, self-contained model that has a short input list and unambiguous output. Refinance break-even is a common starting point for this pattern, because the inputs and outputs are both compact and the answer is directly interpretable. For a content page, the embed is a div with a data-worthune-embed attribute naming the model, plus one script tag; prefill any input with a data-input-* attribute. It is free with attribution — the badge lives inside the frame.

Callers whose primary goal is to prove out user value (Q1 = b) benefit from models whose output visibly moves a user’s decision. Decisions the user was already considering — whether to refinance, when to claim Social Security, whether to contribute to a Roth — produce more visible value on the first integration than decisions the user was not planning to make.

Callers whose primary goal is defensibility (Q1 = c) benefit from starting with a model whose sources are the ones a reviewer will ask about first. Retirement and Social Security models draw on IRS and SSA sources that any financial reviewer will recognize; starting with these produces a strong first-integration precedent that the reviewer can apply to subsequent integrations.

What the wizard does not do

The wizard does not attempt to answer whether the caller should build in-house instead of embedding. That question is the Table Stakes vs. Moat worksheet, which produces a different kind of recommendation from a different question. Callers who have not yet resolved the buy-versus-build question should run that worksheet first; the embed-first wizard applies only after the caller has decided that embedding is the direction.

The wizard also does not route to a specific model by name because the catalog changes. An interactive version, if one is ever published, would route against the live catalog at the time the caller runs it. The article version stays generic on purpose; it points at the questions that survive catalog changes, not at answers that would age.

“The first integration is a proof, not a portfolio. Pick a model that proves what you are trying to prove.”

After the first integration

The wizard is designed for the first-model decision. Subsequent-model decisions are usually easier because the caller has resolved the surface, the pattern, and the audience question through the first integration; the remaining question is which additional models compose well with the first. Callers who ship a refinance-break-even integration first commonly add extra-payment and points-break-even next, because the three compose into a mortgage-decision surface. Callers who ship a Roth-versus-traditional first commonly add adjacent retirement models next. The catalog is designed for composition; the first-model choice sets up which compositions come cheapest.

The wizard is a starting point, not a lock-in

A caller who runs the wizard and ships a first model is not committed to that model as the anchor of the surface forever. If the first integration succeeds, the caller has evidence that supports either expanding on that model or trying a different model with more confidence. If the proof fails, the caller has diagnosed something specific about the surface, the audience, or the integration pattern that a broader commitment would have exposed more expensively. Either outcome is a legitimate result of running the wizard well.