There's a screen on the operator side of our platform where everything our machines think they've learned goes to wait. Not a dashboard. A queue. Every claim an AI system has mined from a document, extracted from a website, or inferred from a brand's own materials lands there as a proposal, and the section header over the list is the whole philosophy in four words and a count: "Waiting for your yes."
The system behind the screen doesn't pretend otherwise. Its own description opens with "what Jinn learned, waiting for your yes." When the queue is empty, the screen says so in the same voice: "Nothing waiting for your yes." — "When a product learns something new about your brand, or a fact starts to decay, it lands here for your review."
I want to walk through this one screen, because the interesting decision isn't the inbox. It's where we didn't put the control. If you're a brand operator starting to hand AI tools real access to your business (your documents, your site, your history), this is the design question that decides whether those tools stay yours.
Two places to put a human
Anyone building AI systems that ingest information at scale eventually gets scared of the same thing: pollution. Models are confident, prolific, and wrong just often enough. Let them write freely into your knowledge base and every downstream product is soon reasoning from claims nobody ever looked at.
The reflex fix is to control the intake. Cap how much the machine may learn. Filter by confidence score. Only ingest the executive summary. I understand the instinct, and I think it's exactly backwards, and I said so while we were designing the document-ingestion path. From the session record, my words: "We don't need to cap the knowledge, we just need to make sure it's all signed off… someone could drop a massive doc and we don't want to miss things. It just should be gated."
Missing things is the worse failure mode. An intake filter is a decision-maker you can't see: every threshold quietly deciding, on your behalf, which parts of your own document weren't worth your attention. A confidence cutoff is still a judgment call; it's just one that got made by a number instead of a person, before you ever saw the candidates. Pollution, meanwhile, doesn't need an intake filter at all. It's prevented by a gate at the other end: the machine can surface everything it finds, and nothing becomes true until a person signs it.
| Cap the intake | Gate the approval | |
|---|---|---|
| Who makes the call | A number instead of a person, before you ever saw the candidates. | Nothing becomes true until a person signs it. |
| What you get to see | A decision-maker you can't see. | The machine can surface everything it finds. |
| The debt it leaves | A silent intake filter is an invisible one. | A full inbox is a visible debt. |
One precision about "uncapped": the intake does have limits, an upload size cap and walls against compressed files that lie about how big they really are. But those are bomb guards. A safety cap protects the machine from the file. A knowledge cap would protect the human from information, by deciding without them. We kept the first kind and refused the second.
Cap the intake and you'll never know what you missed. Gate the approval and nothing becomes true without a yes.
What a row owes you
So everything lands in one inbox. What does one row have to show you before "yes" is a fair thing to ask of you?
Four things, it turns out.
The claim itself, in quote marks.
A chip saying where it came from: "from your document" for a mined claim, "from your brand read" for one extracted during onboarding, plain "pending" otherwise. The note we wrote on that chip sets the bar: the label is worked out by the system from the record itself, not by the screen, "so the chip never guesses." A claim learned while you were still a prospect carries its provenance precisely so it "reads as 'confirm what we learned', never as settled truth."
A badge showing where the fact will land if you approve it, which part of the record it updates.
Add to brain. Reject. And a fold-out labeled "Edit before approving," because the most common honest answer to a machine's claim is "almost."
Every one of those buttons routes through the same single path into the brand's record, the one where machines propose, only people confirm, and every action is logged permanently. That signature machinery has its own essay; the short version is that the inbox is the door, not the lock.
Proof over confidence
Here's my favorite mechanism on the screen, because it encodes a rule I'd hand any operator reviewing AI output, in any tool: never accept the model's word for what the source said.
A document-mined proposal arrives carrying a receipt: the source document and the exact character positions of the passage it came from. When you expand a row, the surface shows you the actual slice of the stored document at those positions, highlighted, with context around it. Not the model's quotation of the document. Our note on the model's version is blunt about the distinction: that text is "The MODEL's excerpt", and the screen shows the stored document's own passage at those positions, "never this, as the proof."
Models paraphrase. Documents don't.
It goes a layer deeper. Documents get re-read by the system from time to time, and positions recorded against an older reading can point at different text in the new one — still in range, now wrong. So every receipt is stamped with a fingerprint of the reading it was mined from, and on mismatch the screen refuses to show the passage as evidence, because (the note again) "rendering that slice would present wrong text as the honest proof." It degrades to the excerpt with a shrug instead of showing you a confident wrong highlight. And a claim the miner could only fuzzily anchor gets its own badge: "needs excerpt review."
Approval here is no easier, but it is informed, which is the only kind worth collecting. You can't sign what you can't see.
The massive-doc test
The obvious objection to gating at approval instead of intake: scale. If nothing is capped, someone really will drop the massive doc, the miner really will propose everything it finds, and your elegant one-at-a-time inbox becomes a punishment.
This is where the design has to put up or shut up. The requirement we wrote at the top of the document-review screen states it as a number: "a 100-proposal document batch reviewable in minutes." The mechanics of getting there without losing the gate are worth spelling out, because they generalize to any bulk approval you'll ever be offered.
You can select everything on a page. Approving every proposal from the document is a separate, explicit action.
The system works out for itself which proposals that includes, rather than trusting what your browser reports, because select-all "never trusts a client list."
The confirmation dialog restates exactly what you're about to do (the true cross-page count, a breakdown by category) before anything fires. A bulk yes never exceeds what was restated to your face.
↩ Back to 01 · re-review and re-confirm
Then the results are named, not summarized. The rule for bulk actions: "never a silent partial: every id that failed is named with its reason."
And the rows that most deserve your attention cut the line — any proposal that contradicts something already confirmed sorts to the top wearing a warning: "Conflicts with your record." The queue spends your first, freshest seconds on the disagreements.
That's the answer to "does this scale": the gate didn't move. The ceremony compressed — from a hundred clicks to a handful — while every property that made the gate a gate survived: explicit counts, a system that checks its own list, refusal when the count changes, named failures.
What the gate costs
The honest ledger, because there is one.
The gate's throughput is a person's attention, and attention doesn't autoscale. Proposals can sit. Some will sit a long time. That's the deal we took, not a flaw we're patching: a full inbox is a visible debt, and a silent intake filter is an invisible one.
You get to choose which kind of failure you can see.
The operator this inbox serves is mostly me. That's what the approval point looks like at our stage: not a staffed review team, one founder saying yes and no with receipts attached.
Where the human stands
If you're evaluating an AI system that learns (yours or a vendor's), I'd ask one question before any demo: where, structurally, does a human stand between "the model found this" and "the system now believes it"?
If the answer is at intake (thresholds, caps, filters), you have a bottleneck pretending to be a safety feature, silently discarding what nobody got to see. If the answer is nowhere, you have a knowledge base filling itself, and you'll meet its contents later, in front of a customer.
The answer we build toward is: at the approval point, with proof on the table. Let the machines read everything, surface everything, and assert nothing. Cap the intake and you'll never know what you missed. Gate the approval and nothing becomes true without a yes.
Which is why my favorite piece of copy we've shipped sits not on a landing page but over a queue: "Waiting for your yes."
The inbox runs on our operator console for a short list of pilot accounts; it isn't customer-facing yet.
Machines propose, people confirm
The single path every approval in this inbox routes through.
See how verification worksWhy not just filter what the AI is allowed to learn?
An intake filter is a decision-maker you can't see: every threshold quietly deciding, on your behalf, which parts of your own document weren't worth your attention. A confidence cutoff is still a judgment call; it's just one that got made by a number instead of a person, before you ever saw the candidates.
So the intake has no limits at all?
One precision about "uncapped": the intake does have limits, an upload size cap and walls against compressed files that lie about how big they really are. But those are bomb guards. A safety cap protects the machine from the file. A knowledge cap would protect the human from information, by deciding without them.
What happens to a claim I reject?
A reject only ever moves a fact to a retired status, "never an ACTIVE one"; the live record "is never touched by a refusal." Every refusal notice ends with the same sentence: "Nothing was changed here."
Does an approval gate survive a hundred proposals at once?
That's the answer to "does this scale": the gate didn't move. The ceremony compressed — from a hundred clicks to a handful — while every property that made the gate a gate survived: explicit counts, a system that checks its own list, refusal when the count changes, named failures.