The README is the three-step version: register a question, your server asks the model, <When> shows the content or the fallback. This page is what that feels like in the app, and what Adaptif adds around a direct call to the model.
Important
The model's answer takes about 100 ms to a second. Until it arrives, and whenever it doesn't, users see the fallback.
Server render, hydration, first mount → fallback
↓ the question is sent (batched with others on the same frame)
Answer arrives (~100 ms–1 s) → content replaces the fallback, if likely enough
↓ no answer within 1.3 s
Timeout, error, or rate limit → fallback stays
- The content replaces the fallback, it isn't added next to it. If the two differ in size, the page can shift. Put adaptive content where a late appearance is fine (a sidebar, a banner slot with reserved height, below the fold), or make the fallback the same size.
- Server rendering always renders the fallback, so there's no hydration mismatch; the switch happens on the client.
- Slow connections get the fallback. The server gives the model 1 s and the browser gives up at 1.3 s, so on a slow mobile connection the normal UI stays put rather than appearing late.
- Answers are cached for 30 s, so remounting a component or navigating back within that time shows the answer at once instead of the fallback.
- Once shown, content stays for at least 8 s and hides only when the probability drops below a lower line, so a wobbling answer doesn't make it flicker.
You can. Adaptif's answers come from Jev, TypeSafe AI's decision model, and for a single classification on the server, such as routing a support ticket, calling it with TypeSafe's SDK takes a few lines. Adaptif is for asking that kind of question from the browser, many times per session. A few decisions shape it:
The config is the allowlist. Questions live in adaptif.config.ts, keyed by their text. The browser only sends a question's id, and the server rebuilds the question from its own copy of the config. Nobody can spend your key on questions you didn't write, and a typo in JSX is a compile error instead of a silent miss.
The fallback is the normal case. Server rendering, the first paint, timeouts, errors, rate limits, and missing consent all render the fallback. The app has to work as if Adaptif weren't installed, because some of the time it effectively isn't.
Nothing is read from the page. The model sees the state you pass, the events you emit, the routes you report, and elements you've marked, all by names you wrote. Input values and page text stay in the browser unless you allowlist a field.
Probabilities get damped before they touch the UI. A situation shows at p ≥ 0.6, hides below 0.4, and stays up for at least 8 s, so an answer that wobbles around 0.6 doesn't make the page flicker. Requests are batched per frame, cached for 30 s, and only re-sent when their inputs change.
Measuring is there when you want it. The model being right about a user doesn't mean acting on it helps. Optional holdouts keep a share of users on the fallback and log exposures and goals for both groups, so you can check. See Measure outcomes.
Next: Architecture.