Big Blue Ceiling

Frndo

Inside Frndo

How we train, bench and choose what Frndo runs, why safety outranks everything else in that choice, how people's data is protected, and what moves the avatar's face.

Most of what makes a companion good happens where nobody sees it: in how each model is trained and benched, in the gates a new model or prompt has to pass, and in the care taken when stored data changes. This page shows that work at the level of stages and relative results. Every bench and gate ran on synthetic conversations, every run and configuration is anonymized, and scores are relative, either to a scale's maximum or to the version already in use.

Safety comes first

We run benches for safety and crisis response alongside the benches for conversation, and they carry more weight. Bench results are what drive changes to Frndo. A new model or prompt reaches people only after it passes a gate: a side-by-side test against the version in use, run end to end through the real backend with synthetic conversations. A candidate that handles crisis moments worse is rejected even when it's better at conversation.

One prompt change scored better at keeping conversations going in our synthetic benches, then failed its gate. Among other shortfalls, it flagged fewer crisis disclosures than the version already in use, and our gates never let a conversational gain offset a weaker crisis response.

We don't publish the safety scores themselves, because numbers like these mislead out of context and they concern people at their most vulnerable.

Your words stay yours

Frndo doesn't train AI models on any user data, including people's conversations, memories, voice and health information. None of it is used for advertising or marketing either. Every model and bench on this page runs on synthetic or curated conversations, never on people's chats.

For account data:

  • Encrypted field by field. Personal details such as names, contact information, journal entries and health records are encrypted field by field before they're stored, so a copy of the database alone doesn't expose them.
  • No passwords to leak. Most people sign in with Apple. Where there is a password, it's never stored: we keep only a one-way, memory-hard hash built for password storage, and older hash formats are upgraded automatically at the next sign-in.
  • Administrators only. Administrative access to user records is restricted to accounts explicitly flagged as administrators, and that flag can't be set through self-service registration.
  • Audited. Security-relevant account events, including failed sign-in attempts, data exports and erasure requests, are written to an audit log.

Our app's performance telemetry doesn't include your name, account or device name. It carries a random app-installation ID, which our telemetry service replaces with a code that changes every month, so reports from different months can't be linked to each other or to your account.

How we train and bench a model

Every training job runs through one orchestrator, from the run definition to a benched, ranked model that's deployed for testing. Promotion to production is always a separate, deliberate step. Across 47 trained runs, every one has been benched the same way, and the charts below follow them run by run.

Eight stages left to right: define, build the payload, schedule, train, merge and quantize, bench, rank and publish, serve.
The orchestrator runs every training job as the same eight-stage pipeline, and promotion to production is never automatic.
Five stacked layers: dashboard, engine, job types, workers, outputs.
Each job type is defined in one place, and the scheduler, workers and dashboard all read that definition, so they can't drift apart.
A central orchestrator with four spokes: ownership, spend rails, rehearsal, collection.
The orchestrator's design rules came out of real failures, and each one guards against something that once went wrong.
A line of tool-calling pass rate per training run, mostly between 85 and 96 percent, with one sharp dip.
Synthetic, scripted tool-use scenarios; where a run had several variants the point is their mean, and the dip is a run that changed one corpus and was not carried forward.
Four lines, warmth, variety, persona stability and continuation, lower in early runs and higher in later ones.
Synthetic multi-turn conversations with a simulated user, scored by an automatic judge; the suite was expanded at run 29, so points either side of it are not strictly comparable.
Bar chart of scenario counts for six suites, from 14 to 48.
Every scenario is synthetic and written for the bench, and none comes from a user conversation.
Five cards, each naming one question a bench suite asks.
Suites were added as the work grew, and a run is ranked only on the suites it shares with the runs it is compared against.

How we choose a configuration

A configuration is a trained checkpoint, a system prompt and a set of sampling settings. We change one dimension at a time against the served baseline and score each combination on several families of benches.

Five-step flow: candidates, sweep, bench, read against baseline, gate.
A configuration reaches users only after beating the served baseline offline and then in a side-by-side gate on synthetic conversations.
Six cards: checkpoint, system prompt, sampling (swept), and conversation, safety, tools (measured).
Each arm changes one thing so a difference can be traced to its cause.
Bar chart: Config A 104, B 100, C 87, D 82, E 76, F 86 against baseline 100.
Synthetic conversations, blind-judged. Only a prompt change on the served model beat the baseline at keeping conversations going.
Table comparing the baseline and three configurations on six measures, normalized to baseline 100.
Synthetic benches. Newer checkpoints gained on lookups while giving up conversational warmth, which is why the choice went to a gate.

How a reply candidate is tested

Before a candidate replaces the baseline, the bars it has to clear are written down, both arms run side by side under the same synthetic conditions, and blind raters mark every reply without knowing which configuration wrote it.

Seven steps from left to right: pre-register, build the arms, rehearse, run paired conversations, check where consumed, blind rating, verdict.
A candidate earns a verdict only after a rehearsal, a paired live run and blind rating against bars fixed in advance.
Four stacked layers: memory recall, remembering the why, everyday conversation, hard moments, each with the checks it carries.
One test spans memory, reasons, everyday tool use and conversation, and difficult moments.
Six cards: false memory, invented lookup, recall hit, warmth, stays with the person, watch-for hit.
Every reply gets the same six labels, so a reply cannot reveal which arm it came from by what is asked about it.
Eight bars, one per check, showing candidate A as an index against the baseline at 100; most sit near 100, two well above.
In synthetic conversations candidate A matched or edged the baseline on most checks but missed the bars it had to clear, so the baseline stayed.

Tone and curiosity, set at inference

Some of Frndo's personality isn't trained in at all. Steering adds a small learned direction inside the model as it writes, which gives us dials for how bright its tone is and how often it asks questions, without retraining and without extra prompt text. Steering isn't the classifiers that pick tools or recognize languages; it's a separate layer of control over the voice.

Six-step flow from trait definition through contrast pairs, activation capture, direction extraction, judged sweep and dial calibration.
Each steering vector is built from synthetic contrast pairs and validated by judge models before it is offered as a dial.
Four-step flow: conversation in, dial settings, steered generation, reply out.
Steering is applied at inference time, so one trained model can serve several personalities without retraining.
Line chart: for seven checkpoints the share of replies asking a question falls from between about 22 and 36 percent to near zero as the dial is turned down.
Counted directly from replies to synthetic conversations: every checkpoint goes from its natural question rate to almost none.
Line chart: judged brightness rises well above the unsteered level as the dial goes positive and dips only slightly below it as it goes negative, for seven checkpoints.
Judge-panel scores on synthetic conversations; brightness travels much further upward than downward on every checkpoint.
Bar chart: reproducibility between about 98.9 and 100 percent for seven checkpoints.
A Guttman-style coefficient of reproducibility: once a conversation stops asking questions it almost never starts again.
Bar chart: between about 93 and 100 percent of dial combinations pass on each of seven checkpoints.
The two dials compose: almost every combination stays coherent, and the few failures sit at the extreme corners.
Line chart: under deployment instructions question rates start between 10 and 35 percent and reach about zero well before the strongest setting.
Synthetic conversations under deployment-style instructions: the starting point moves, but the dial still takes questions to near zero.
Six cards summarizing findings: transfer, countable traits, asymmetric brightness, context, per-conversation noise, calibration.
Qualitative findings from the steering study, all measured on synthetic conversations.

Memory in Frndo's own voice

Frndo remembers what people share. Those memories used to be stored as a record about someone; we moved them into the voice Frndo actually speaks in, and treated the change like any other change to stored data: counted, rehearsed, verified and compared before it shipped.

Two columns. Left: three invented memory lines written in the third person, such as 'User doesn't like cilantro.' Right: the same lines in the second person, such as 'You don't like cilantro.'
Every memory is stored and shown to the model in the second person, so what Frndo recalls already reads the way it talks to you.
Four stacked layers: extraction, storage, prompt assembly and recall, each listing how memory voice is handled there.
The same conversion rules govern new memories, stored memories and the prompt, so no layer drifts from the others.
A six-step flow: count, rehearse on a synthetic profile, dry run, run with originals kept, verify nothing is left, and compare rebuilt prompts before and after.
A memory change ships only when a fresh pass finds nothing left to fix and the rebuilt prompts match what the model saw before.
Bar chart of percentages: facts rewritten 91.0, patterns 78.5, profiles 23.9.
Most stored facts needed the new voice, while most profiles already had it.
Six cards listing the checks a memory change must pass: nothing left, same prompt, reversible, synthetic first, no text in logs, no collisions.
Memory changes are judged by what the model ends up seeing, and every one can be undone.

The face, layer by layer

The avatar's face is driven by separate layers, from speech to expression to idle life, blended into one set of shape weights every frame.

A grid of seven cards, one per mouth shape (SIL, TH, FF, SS, O, E, I), each describing the lip and teeth position and example words.
Each viseme moves matching sculpted shapes on the head, teeth and eyelashes together, so any avatar whose shapes follow the naming convention lip-syncs without extra setup.
A seven-step flow: listen, decide the user has finished, the reply streams in, choose a mood, speak, lip sync, animate.
Speech synthesis runs one sentence ahead of playback, so the avatar starts talking before the whole reply has arrived.
Four stacked layers: speech visemes, emotion expressions, idle life such as blinking and eye movement, and body gestures and posture.
The layers are blended on the phone each frame, so the face keeps moving naturally between sentences.
Bar chart of 216 lip-sync model configurations by relative accuracy: 160 scored 95 to 100 percent of the best, 38 scored 90 to 95, 7 scored 85 to 90, and 11 scored below 60. None fell between 60 and 85.
An early development sweep, scored on held-out clips from a curated speech set, never user conversations. Three in four setups reached at least 95% of the best; the few failures fell well short, with none in between.

  • AI Storybook

    News stories, autonomously retold for children.

    • AI
    • Apps
    • Pipelines

  • B2C Payments

    A reusable billing framework for subscriptions, invoicing, prepaid credits and usage billing, dropped into any app.

    • AI
    • Tools
    • Apps
    • Pipelines

  • BigBlueBam and the B-Suite

    A work suite where AI agents work alongside people, with the same permissions.

    • AI
    • Tools
    • Apps

  • Convo

    Synthetic conversations for training chat assistants, planned, checked and reviewed before export.

    • AI
    • Tools
    • Apps
    • Pipelines