FFT Social
the algorithm

what's actually under the hood.

people who build recommendation systems and language-model pipelines keep asking the same question: so what is your algorithm, really? this page is the longer answer. it's the same story as our standards, but written for someone who wants to know how the pieces fit together. it is intentionally honest about what we do, and intentionally quiet about the parts that took the longest to get right.

the one-sentence version

FFT Social is a structured-debate engine: every public menu passes through a pipeline of small, single-purpose AI critics — each with one job — before a single stranger ever votes on it.

we did not build a feed ranker. there is no engagement score, no outrage multiplier, no "for you" model trained on which takes made you stop scrolling. the algorithm's job is not to decide what you see next. its job is to decide what is good enough to be seen at all. those are very different products and they produce very different internets.

where the ideas come from

the engine is a mash-up of a few well-known frames from outside computer science. we name them on purpose; pretending you invented good ideas is how products get worse.

the pipeline, phase by phase

the engine is a chain of small critics rather than one big prompt. each one has a single job. failures earlier in the chain short-circuit the rest. later passes only run if the menu is structurally sound.

phase 1 · the structural editor

the publish gate. checks that every dish is labeled with the correct stance toward the menu, that no dish has drifted onto a different topic, that the menu isn't sneakily one-sided, that each take is falsifiable, and that the menu is worth arguing about in the first place. this is the only phase that can block a publish. if a menu doesn't clear this bar, the author gets specific, dish-by-dish feedback and a draft rewrite they can accept, edit, or reject.

phase 2 · lens coverage

the Six-Hats pass. reads the menu as a whole and asks: which modes of thinking are missing? if every dish is a facts-and-numbers dish, the menu is one-eyed. the critic suggests draft dishes for the lenses that aren't covered. the author is never forced to take the suggestion; unbalanced menus ship with a visible label rather than a block.

phase 3 · time horizon

short-term vs long-term balance. a debate that only argues next quarter is reactive. a debate that only argues the next century is detached. honest menus do both. the critic suggests a missing-horizon dish when one side dominates.

phase 4 · the bias auditor

reads the menu and dishes for unfair framing along protected dimensions — gender, race and ethnicity, religion, age, disability, sexuality, nationality, socioeconomic class. its job is not to decide whether a take is correct; its job is to flag when the framing treats some groups as default and others as deviation. it suggests, never rewrites. the author keeps the pen. this phase is the one we tune most carefully — false positives are louder than false negatives — and it ships behind a flag we can dial.

phase 5 · plain-language pass

readability and jargon check. if a take needs a glossary, it's a research paper, not a debate. the critic offers simpler rewrites the author can accept or reject. never a gate, always a suggestion.

phase 6 · worked examples

for any dish whose claim is abstract, the engine drafts one concrete example that illustrates what the dish would look like in practice. "space data centers will be commercially viable" becomes, alongside the dish, a single worked example a reader can react to. examples are stored next to the dish, never substituted for it.

how the phases combine

each phase emits its own little audit blob. the publish gate looks at all of them together. phase 1 can block. phases 2 and 3 emit warnings and suggestions but ship the menu with a visible label if the author insists. phase 4 is warn-only by default. phases 5 and 6 are always suggestions, never gates.

the structural phase runs synchronously when you hit publish — it's the gate, it has to. the rest run in the background and stream their results into the menu screen as they finish ("the bias auditor is reading your menu…"). the author can publish immediately; suggestions appear afterward as editable notes.

what we deliberately don't do

what the engine is actually optimizing for

if you wanted to write our loss function in one line, it would be something like: maximize the chance that a thoughtful stranger, reading this menu cold, walks away slightly sharper than they walked in.

that's a hard thing to score directly. so the pipeline scores the things we believe are necessary conditions for it — coherence, balance, falsifiability, plain language, fair framing — and trusts that a menu that clears all of them tends to produce the thing we actually care about. when a menu ships through the check and a reader still walks away dumber, that's a bug in the checklist, and the checklist gets edited. every override an author types is a small piece of training data for the next version.

what we don't publish

we don't share the exact prompts, the scoring weights, the thresholds, the model choices per phase, the eval sets, or the override-derived training data. those are the parts that took the longest and are easiest to copy. the shape of the system — phased critics, single jobs, author-keeps-the-pen, no engagement ranking, no AI votes — is the part worth publishing, because it's the part worth defending.

if you can hold a menu up against the criteria on this page and feel good about it, it's an FFT Social menu. the engine is just the part that makes that judgment cheap enough to apply to every menu, every time, before any stranger sees it.

more reading