Someone on r/PromptEngineering just shared an open prototype called INKBOT, and the twist is a step most of us skip: it makes the model show you what it thinks you meant before it builds anything.
What’s new
INKBOT is a local-first tool that lives in a single web file. That means no account, no server and no waiting on a hosted service. You open the file and it runs on your machine. The builder (u/Traditional_Peak1459) got tired of the gap between what a person means and what a multimodal model infers. You describe something subtle, the model confidently builds the wrong thing, and then you spend your time repairing a big, heavy output. Anyone who has asked for “a calm, slightly retro dashboard” and received a neon gradient mess knows exactly this pain.
There are two versions. One is the full architecture edition for poking at the plumbing. The other is INKBOT Lite 71, a lighter entry-level version of the core prompt translation loop. If you just want to feel the idea, start with Lite. If you want to see how the pieces connect, open the full edition and read how it is wired together.
The twist
The model’s guess and your approved meaning are kept separate. Most tools blur those two together. The model guesses, builds on the guess, and the guess quietly becomes the truth. Here, before the final build, the system produces an inspectable “Visual Brief”. It shows where each piece came from, what constraints apply, and how the pieces relate. If the model guessed wrong, you fix the brief, not the finished result.
Think about why that matters. Fixing a wrong assumption in a short brief takes seconds. Fixing the same assumption after it has spread through a finished build can mean starting over. The brief is the cheap place to catch the error, and it keeps the expensive output from being built on a shaky foundation.
The builder describes the loop as Describe, Make it Visible, Recognize, Correct, Refine. You are not asked to become a prompt engineer. You are asked to be a reviewer, and reviewing is a much lighter skill than writing perfect prompts from scratch. You only have to notice “that’s not what I meant” when you see it.
The mini-workflow, in plain terms
- 📝 Describe what you want in your own words. Messy is fine. You do not need clean phrasing, just honest intent.
- 👀 Let the tool turn your description into a structured brief, with parts, sources and constraints you can actually read. Each item should tell you where it came from, so you can tell your words apart from the model’s additions.
- 🔍 Scan the brief for false inferences. Did it assume something you never said? A color, an audience, a tone, a layout? Anything you did not say is a candidate for a wrong guess.
- ✏️ Correct the brief, not the output. Your approved meaning stays separate from the model’s raw guesses, so a correction sticks instead of getting overwritten on the next pass.
- 🔁 Refine, and let the version history carry the context forward. You can see what changed between versions and why, which beats scrolling back through a long chat hoping you remember.
The post mentions mixed inputs too, like matching a person’s profile data against technical examples, with the system tracking images, coordinates and version states together. That is where a brief earns its keep. When several kinds of input collide, a written-out structure makes it obvious which source influenced which decision.
Pro tips
- You can steal the idea without installing anything. Next time you hit a vague task, ask your model to write back a short brief of what it understood (assumptions, constraints, what it will ignore) and approve that before it generates the real thing. One extra message at the start can save you five repair rounds at the end.
- Pay special attention to the “what it will ignore” part. Models often drop details silently, and asking them to list what they plan to leave out surfaces those losses while they are still cheap to fix.
- Keep a tiny “approved meaning” note that you paste back into every follow-up. That is the poor man’s version of the separation INKBOT builds in. Five or six lines is plenty: the goal, the key constraints, and anything you already rejected.
- When you correct a brief, be specific about the wrong guess. “Not corporate, more like a friendly neighborhood shop” works far better than “make it better.”
- If you open the source, the author left raw notes and a design roadmap as comments at the very bottom of the file. That is where the interesting thinking is, including hints about where the design might go next.
Fair warning
This is a prototype with 4 upvotes, and the top comment points out that it resembles structured reasoning loops people played with a couple of years back. That is a fair point, and worth keeping in mind before you treat it as a breakthrough. The local-first angle and the visual brief step are the new bits. The author is asking directly where it duplicates existing work and where the design breaks, so it is a good one to poke at, not a finished product. They also state it is independent and non-commercial, so there is no pitch hiding behind it.
Call to action
Try the Lite version, break it, and tell the author where separating intent from inference falls apart. Feed it something deliberately vague and see what it assumes. And if you build your own review step into a prompt, I would love to hear how it goes ☠
Frequently Asked Questions
Q: How is INKBOT different from structured reasoning approaches that already exist?
Most alignment work either trains better models or teaches you to write killer prompts. INKBOT takes a different angle, it adds an intermediary layer that formalizes your intent before the model even runs, keeping everything human-reviewable and easy to fix. The local-first design and visual briefing step mean you’re not turning yourself into a prompt engineer; instead, you get structured feedback that actually helps the model understand what you mean.
Q: Can corrections cause the system to spiral if they’re misinterpreted?
Totally fair question, it’s a real risk. The safeguard here is the stateful revision history: every approved state gets locked in, so if a correction gets misunderstood, you can always rewind and try a different angle. You’re not stuck in a compounding error loop; you just back up to the last known-good state and iterate from there.
Q: How does the visual brief step improve alignment between intent and output?
Instead of finding misalignments after heavy generation, the visual brief lets you spot them before, you see your intent formalized and can catch the model’s misreading early. It’s like a human checkpoint that prevents wasted inference and keeps the feedback loop tight and fast.
Q: How does revision history help on long-running projects where model outputs drift?
On longer projects, models can gradually drift from your original intent across multiple rounds of refinement. The revision history keeps your approved intent locked in as the foundation, so you’re always building on something human-vetted instead of watching the model slowly reinterpret what you meant.
[D] INKBOT: Separating human intent from model inference via structured intelligence architecture
by u/Traditional_Peak1459 in PromptEngineering