In 2022, image models were new enough that the honest question wasn't "is this pretty" but "can it carry something finished": a dozen pages that hang together, not one lucky screenshot. Two years later that question sounds quaint: the tools reset every few months and quietly swallow whole workflows. Blankie is a snapshot from inside that shift, and the clearest way I've found to show how far it's moved.

A children's book is a deceptively hard thing to point an image model at: a dozen-plus spreads, and the same teddy bear has to read as the same bear on every one, from every angle, in the same hand. Back then that one requirement (character consistency) was precisely what the technology was worst at, which is exactly why it was worth trying. The writing was the gentle part: plain couplets a sleepy kid could follow, like "But oh no! Where's his blankie red?", drafted with ChatGPT as a sparring partner for rhythm. Everything hard was in the pictures.

These were pure text-to-image systems with no memory between generations: each image an independent roll of the dice, with no notion of this character that carried from one prompt to the next. So the whole aesthetic had to be re-specified, in full, every single time, which made the prompt the only real lever. Ours lived as one long, exact paragraph of illustration rules (ink outline, no shadows, no hatching, a light watercolour palette, a bluish wash) where word order mattered. You generated in batches, cherry-picked the survivors, and leaned on the workarounds of the day: fixed seeds, image-to-image, inpainting, pose conditioning.

The turning point was Midjourney's character-reference feature, --cref. For the first time you could hand the model an approved portrait and say, in effect, this one, tuning how hard it listened with --cw. It was the single most useful thing in the whole project. We settled on a Teddy everyone agreed on, then pointed every subsequent scene back at that reference.

From there, every scene reused that same style paragraph with --cref aimed at the portrait. It helped. And it still wasn't enough.

Even the keepers weren't done. Each needed real Photoshop work: a stray extra finger, lighting matched across spreads, text composited into the art, print files prepped. The "AI-generated book" was, in practice, a lot of manual craft stitched around the generations. And the sharpest editor in the whole process wasn't a model at all: Priya went through the draft page by page, flagged that naming every character right before bed was one too many for a drowsy toddler so that page got cut, then read the whole thing aloud to her own kid and reported back on what landed.

Almost every hard-won trick in the book has since been absorbed into the models themselves. The re-typed style paragraph, the --cref reference, the seed-locking, the batch-and-cherry-pick, the inpainting, the Photoshop salvage. That entire apparatus existed to paper over one gap: the model couldn't hold a character in its head.

Now it largely can. Multimodal, in-context generation lets you hand a model your character and your instructions in the same breath, keep it consistent across a whole set without a special flag, and, most tellingly, edit in place by conversation: "same bear, now on a swing, keep the jacket," instead of rolling the dice again. That moves where the skill lives: when consistency is nearly free, taste and art direction matter more than prompt-craft. Re-made today, Blankie would be closer to an afternoon than the months it took.

This was never a portfolio exercise. It got made to be read to actual kids at actual bedtimes, argued over on WhatsApp threads, and revised because a real toddler lost interest on the wrong page. It's easy to track this shift from release notes and demos; Blankie is my argument for the opposite: you only really feel how far the tools have moved by trying to make something finished with them, then trying again a year later.

GEN:48 was RunwayML's first 48-hour film challenge. Every team gets the same three ingredients at the same moment (a location, a character, an event), then races a hard deadline with no extensions. Ours became an interdimensional cat named Luna Whisk, made with a few friends over one weekend.

The pipeline was whatever we could stitch together. DALL·E generated the interdimensional worlds. Runway's image generator handled character shots, fed reference images to keep Luna on-model. Its Gen-Turbo model turned those stills into motion. An original score came from Suno, sound effects from the Epidemic Sound library the contest handed participants, and narration from an AI-cloned voice in ElevenLabs. A friend who does this for a living wired the tools together, knew which warped takes to throw out, and did the final color and edit, exporting minutes before the cutoff.

This edition predated most of today's tooling, so those five tools were, between them, close to the entire stack. And the hard part was never the look. It was continuity. Nothing enforced that the cat in one shot was the cat in the next, so "the same cat" meant close enough, picked by eye.

A good slide is two things wearing one coat: a design (where the title sits, what the palette is, how many characters a box holds before it looks cramped) and the content that lands inside it. Models in early 2025 were strong at the second and hopeless at the first.

So I stopped asking them to do the first at all. I bought a professionally-designed template (a light modernist pitch deck, thirteen slides) and treated the design as fixed. The whole system had one job: read that deck into a spec precise enough that agents could pour new content into it without touching a single design decision. The template is the contract; the agents just honor it.

The obvious first build was to dump every slide's shapes into GPT-4o and ask it to describe the template as JSON. It demoed fine and failed in practice: the model hallucinated placeholders that weren't in the deck and dropped ones that were. It was guessing at a file it couldn't see.

So I threw it out. A .pptx is just a zip of XML, so v2 reads the actual document instead of describing it: every text frame's position, font, size, weight, color, alignment, and bullet levels, pulled from the drawing-markup, with python-pptx as a fallback when the XML stays silent. No guessing; the spec now describes the deck that exists.

Everything the extractor produces lands in one typed record per text frame. Get the schema right and the reading half and the writing half can be built and swapped independently. They only ever agree on this shape, and max_chars is the line that makes the contract enforceable:

Built from six pieces, each doing one job

Most slides don't state their own formatting. A title box inherits its font from the layout, which inherits from the master, which falls back to the theme. Read the shape alone and you get None for nearly everything, so the extractor walks the same cascade PowerPoint resolves at render time, stopping at the first level that answers.

The second part is the one that makes the whole thing enforceable. For each frame the tool estimates how much copy fits from the box's real size and font, and writes that number into the spec as a hard limit. Downstream, the content agent is told "this subtitle gets ~324 characters," not "write a subtitle." That budget is what later lets a fit-check reject a slide that overflows.

With the contract in hand, generation stopped being a single prompt and became a loop of narrow agents, each with one responsibility. Give it a topic and the spec, and:

A planner chooses which template slides to use and orders them into a story. A content agent writes copy into each slot, one frame at a time, working against that frame's max_chars. A visual agent generates the charts and imagery, reading from the same theme palette the extractor pulled so nothing clashes. Then a fit-check measures every box against its budget, and anything over goes straight back to the content agent for a tighter rewrite. Only once every slide passes does the render agent write the filled spec back into a real .pptx through python-pptx, editing runs in place so the design survives untouched.

Getting a model to respect a hard limit. An LLM treats "≤324 characters" as a polite suggestion. No amount of prompt-tuning made it reliable. The fix was structural, not verbal: generate, measure, and bounce anything over budget back for a rewrite. The fit-check loop is what turned a suggestion into a constraint, and it's the piece that made everything else trustworthy.

Rendering back without wrecking the design. Writing generated copy into a slide is deceptively easy to get wrong: replace a text frame wholesale and you lose the exact fonts, colors, and spacing the template existed to provide. The render agent had to edit runs in place, changing the words while leaving every formatting attribute the extractor had so carefully resolved.

Visuals that looked like they belonged. A perfectly-written slide still looks stitched together if the chart shows up in stock blue. Feeding the extracted accent palette into the visual agent kept generated graphics on-theme: small thing, big difference in whether a deck reads as designed or assembled.

The budget is still a heuristic. The character estimate approximates glyph width; it doesn't know an i from a W, so it's occasionally off. I shipped it anyway, because the fit-check downstream caught the misses, an imperfect budget was good enough to build a reliable loop on. Real per-typeface metrics would tighten it, and that's the first thing I'd redo.

I got it working end to end: a topic in, and the agents planned the deck, wrote to every box's budget, generated visuals in the theme palette, and rendered a real .pptx with the design intact. A few months after I had it producing decks, Claude and Gemini shipped native deck and document generation, and any reason to keep building a bespoke pipeline evaporated. That's the right outcome: if a frontier model does the whole job well, a weekend project shouldn't compete.

But it was satisfying to watch, because the thing they got right is the thing this was built around: quality comes from working within a strong design system, not from asking a model to conjure one each time. What stays with me isn't the code, it's the framing: find the taste-dependent half of a problem, make it a fixed input, and let agents do only the part they're reliable at, inside a loop that checks their work. That instinct outlives the prototype, which is the whole point of building small things at the edge of what's possible. You learn where the edge is with your hands on the file, not from the release notes.

I wanted to know if a vision model could read vibe: not “this is an email with a button,” but “this is trying to be your funny friend, and mostly pulling it off.” One weekend turned into several, because the diagnoses kept coming back sharper (and funnier) than I expected.

What kept me building: the gap read turned out useful. Most creative isn’t bad, it’s mismatched. It intends one thing and signals another, and naming that gap in plain, slightly rude language turns out to be something a multimodal model is weirdly good at. Somewhere along the way the prompt chain grew a scout, a referee, and opinions about evidence, and became an actual app.

This is the app mid-diagnosis: Streamlit on top, a crew of Claude agents underneath. Left pane: the uploaded email with numbered evidence pins, drawn from OCR boxes a Python scout measured before any model said a word. Top right: the crew tracker, tagger to critic to referee to goblin, ticking green as each agent lands. The verdict: the Contraband Cookie Bandit.

That one scan fills six tabs. Each is a different read on the same pixels, and every screenshot below is real output, from this Zomato scan or the Olaplex one further down:

To prove the ring reads vibe and not a checklist, I picked the Bandit’s exact opposite: an Olaplex nurture email. Premium, clinical, five thousand pixels of bond science. The ring named it the White-Coat Rapunzel, and the flaw it found is structural, not tonal: one email wired for two customer journeys, a welcome gift up top and a cart-recovery button right under the science. This is also the scan where the referee earned its keep, bouncing the critic’s first draft for ungrounded claims and forcing a redo.

Ingest normalizes the input: images pass straight through; raw HTML gets rendered to pixels by headless Chrome and parsed for its DOM facts, so the model reads what the email says and what it looks like. Then a deterministic Python scout runs OCR and k-means clustering to produce the receipts: text blocks with ids and pixel boxes, a palette with exact percentages. Only after that does the crew speak: a tagger sorts, a critic interprets, a referee bounces any claim the scout can’t back up, and the goblin and remixer go last.

Taste has no ground truth, so I test around it. The bar is three properties I can measure:

Someone sent me "creatine causes hair loss" as a fifteen-second clip. Checking it properly means knowing which of forty thousand PubMed hits actually speak to the question, which ran on people instead of cells, and which are strong enough to change what you’d do about it. That’s a researcher’s afternoon, and nobody watching the clip has one to spare.

Consensus and tools like it already proved people will use an evidence search engine as long as it talks plainly. I wanted something narrower and more opinionated: not a search box over papers, but a claim checker. You hand it the exact sentence you heard, and it does the translation, because people think in claims and PubMed thinks in papers. Everything Sift does lives in the gap between those two, and it always starts from the claim, never from the paper.

I kept the home page deliberately plain: one input, a few example claims so you’re not staring at an empty box, and a single button. Underneath it I put a wall of trending checks with their verdict chips already attached, so the vocabulary teaches itself before you type a word. You see "Unsupported" and "Likely supported" and "Overstated" sitting next to real claims and get the idea. There are no accounts and no dashboard. All the complexity I could push backward, I did; the page you land on doesn’t show any of it.

Health claims almost never arrive while you’re sitting at a browser. They show up mid-conversation, in the chat you already have open, so I put Sift there too. Send it a single claim and it replies with the verdict, the confidence, a couple of plain sentences, and a link to the full report if you want to go deeper. Paste a whole influencer rant and it does something I like more: it reads the blur, pulls out the separate claims hiding inside it, and asks which one you want checked. Both of these screenshots are the actual bot, on my phone.

The bot isn’t a one-off integration I hand-wired. It runs on OpenClaw, a local-first, messaging-first agent runtime, which means the Telegram gateway, the conversational state that remembers which claim you picked, and the agent loop all come for free and all stay on hardware I control, which matters more than usual for a health tool. My side is a small TypeScript plugin that registers exactly three whitelisted, read-only tools, sift_check_claim, sift_extract_claims and sift_search_pubmed, each a thin proxy to the core. OpenClaw runs the plumbing and never touches the verdict; that still happens downstream, in the deterministic engine.

This is the whole report for "creatine supplementation causes hair loss," exactly as it renders, top to bottom. The verdict leads, with confidence, evidence quality and directness as separate chips so none of them can quietly stand in for the others. Then the bottom line, the caveats, and the field I care about most (what would change this answer), which is stored in the report, not improvised, because a fact-checker that can’t tell you what would move it isn’t being honest. Below that sit the evidence pyramid and the direction chart, the split between mechanism and human outcome, the claim broken into checkable subclaims each with its own verdict, and finally the study cards, every one carrying its weight in the verdict and a live link out to PubMed.

I picked this claim on purpose, because it’s the perfect stress test. The creatine-and-hair-loss scare traces almost entirely back to one three-week study in twenty rugby players that measured a rise in a hormone marker, not actual hair loss, and was never replicated. The report says precisely that: mechanistic evidence weak, human-outcome evidence weak, a single small trial, and a "what would change this answer" list that asks for the study nobody has run yet. That shape, a real mechanism doing the work of a conclusion it hasn’t earned, is how most viral health claims are built, and I designed the report to make it visible.

A binary verdict is the fastest way for a fact-checker to lose people on health topics, because the honest answer is almost always "there’s something real here, but the claim runs well past it." So I never let Sift say true or false. It chooses from eight cautious labels instead, and shows confidence and evidence quality right next to the label, so the uncertainty is part of the answer rather than something the tool quietly hides to sound sure.

"Seed oils are bad for you" can’t be answered as written, because it’s hiding four or five different questions that have four or five different answers. So before Sift checks anything, the parser splits the claim into subclaims and checks each one on its own terms. It’s the same machinery that lets a single influencer sentence unpack into several linked reports instead of one mushy verdict.

A claim checker is only ever as honest as what it can pull up, so this is the part I spent the most time on. My bet was that the text search is the replaceable piece and the structure around each study is the durable one. So I hid the store behind one narrow interface (available, store_source, search → list[Source]) and nothing downstream knows or cares which backend answered. That’s what lets me swap the whole retrieval engine without touching the pipeline, the verdict, or the UI.

The unit I store isn’t a passage of text, it’s a typed Source: the title and citation, yes, but also the study type (systematic review, RCT, cohort, animal, in-vitro), the human relevance, the directness to the claim, the evidence direction (supports, mixed, contradicts, not relevant), the weight it earns in the verdict, the main finding and its limitations, each as its own field. The backend indexes the study’s text for search but also tucks away a lossless JSON copy of the object, so retrieval hands the pipeline fully-typed studies rather than paragraphs it has to re-read. That typing is the reason the report can say "mechanism only, low weight" and mean the exact same thing every single time.

Underneath that interface I run two backends. The default is SQLite FTS5, ranked by BM25 (no install, no keys, deterministic), which is the right call for a portfolio-stage build because anyone can clone the repo and it just works. The optional one, behind an EVIDENCE_BACKEND=gbrain flag, is a hybrid vector-and-keyword semantic store I ported from an earlier Dataclaw project, and it catches the case plain keyword search misses: "does linoleic acid raise cancer risk" and "are seed oils carcinogenic" are the same question wearing different words. Because both backends satisfy the identical interface, moving from keyword to semantic retrieval is a config change, not a rewrite.

Retrieval only finds candidates; deciding what each one is worth is a separate job, and that part is fully coded rather than aspirational. A claim taxonomy (causal-risk, benefit, superiority, mechanism, absolutist) sets what a good answer to that kind of claim should even look like. A study-design hierarchy (the evidence pyramid) assigns each design a quality value, from a meta-analysis at 1.00 and an RCT at 0.85 down through cohort at 0.60 to animal at 0.20 and in-vitro at 0.10. The ranker folds that together with human relevance, recency, sample size, directness and risk of bias into one transparent 0..1 score per study, and that score becomes the High, Medium or Low weight you see on each card. Every number in the report walks back to it.

I’ll be straight about what’s built and what isn’t. What runs today is a typed store with pluggable keyword or semantic retrieval and a ranking taxonomy that’s real and working. Where it’s headed is ontology-guided GraphRAG: storing each study as an exposure acting on an outcome, so retrieval can walk from a claim to evidence that never shared its vocabulary. I drew the interface the way I did specifically so that becomes the next backend, not the next rewrite.

A claim runs through a chain of deliberately narrow steps: parse it, decompose it, build the queries, retrieve from the store, classify each study, rank it, synthesize the direction, map that to a verdict, and run the safety layer. But the decision I care about most isn’t any one of those steps: it’s what I refuse to let the language model touch.

The model never grades evidence from memory, and I keep it boxed into three jobs, all of which I can audit. It parses messy input into testable claims. It labels each retrieved study’s stance (supports, contradicts, mixed, or not relevant), judging only from that study’s own finding text. And it writes the plain-English summary, but only after the verdict is already fixed. The verdict itself is a pure function over the direction tallies, the evidence quality, the directness and the claim type. Which means swapping the model can only ever move a verdict by relabelling an individual study, something you can check against the abstract yourself, and it can never cite a paper that wasn’t actually retrieved. That, more than anything else, is how I keep it from hallucinating a confident answer.

How a study earns its weight

The verdict engine reads and writes one structured object per claim, and it’s worth looking at the last field. "What would change the answer" is stored right alongside the verdict, generated as part of the same pass rather than tacked on, so the report always carries its own falsification conditions.

The stack, one job each

The first thing I got wrong was assuming quality and directness were the same axis. A rigorous meta-analysis on vitamin retention in pressure-cooked vegetables is genuinely high quality, and it still barely answers "is pressure cooking bad for you." Until I split those into two separate scores, both computed and both shown, the report kept quietly overweighting a precise answer to the wrong question.

Then there was mechanism inflation, which turned out to be the whole game. Almost every viral health claim points at a real mechanism (oxidation, a hormone marker, an inflammatory pathway), and the mechanism usually is real. The hard part was making "this mechanism exists in a dish" and "it matters at the amount you eat at dinner" land on different verdicts, so a rat study about overheated oil never gets to read as proof your cooking causes cancer.

Pulling claims apart was harder than it looked too. Influencer posts weld four claims into one breathless sentence, and the extractor had to separate them without inventing a claim that wasn’t there and without dropping one that was. That’s a much narrower target than "just split on the conjunctions," and it took real iteration to hit.

I was also surprised by how much work the tone took. Writing verdict language that informs without frightening ate as many revisions as the ranking did. "Overstated" has to read as a fair, slightly boring assessment, not a scold, because the moment it feels like a scold, people stop trusting the tool on exactly the topics that scared them enough to check.

And then the trade I made on the database itself. Seeding a snapshot kept the demo deterministic and honest, with no hallucinated citations, at the cost of breadth. I made that call on purpose for a portfolio-stage build, and I made it survivable: because the store sits behind one interface, the default SQLite/BM25 backend, the optional gbrain semantic one, and live PubMed at query time are all the same shape to the pipeline. That’s why live retrieval already backfills a novel claim when the local shelf is thin, without anything downstream needing to change.

A detector watches for the topics where a breezy evidence summary could actually do harm (pregnancy, children, cancer, kidney and liver disease, medication interactions, eating disorders, severe symptoms), and when it sees one it escalates the caveats or refuses to give treatment advice at all. Sift will never tell someone to stop a medication or hand out a personalized plan, because it has no tool that could. And every report carries the same disclaimer whether the claim was about frying oil or something far more serious, so the line never blurs.