Questions about the review board

Everything below describes what suggestibility.ai actually does today. If an answer here disagrees with the privacy notice or the terms, those documents govern.

What it is

What is suggestibility.ai?

suggestibility.ai is an AI expert review board. You submit a technical artifact — an architecture decision record, a policy, a design doc, a runbook, an incident postmortem, a model card, a migration plan — and it convenes a panel of reviewers drawn from independent model families to evaluate it separately. A synthesis pass then turns those separate reviews into one review package: consensus, preserved dissent, ranked recommendations, and findings with severity and provenance. It runs on Cloudflare Workers and D1, and boards range from three reviewers up to seven depending on how much scrutiny the artifact needs.

What is an AI expert review board?

An AI expert review board is a structured process for evaluating a document from several perspectives at once, without averaging them into mush. Each reviewer — a separately queried model from a different independent model family — reads the artifact and writes an independent review: findings, severity, a recommendation. A synthesis pass then reconciles those reviews, and reconciling doesn't mean erasing disagreement. Where reviewers agree, that becomes consensus. Where they don't, the minority position is preserved with attribution rather than smoothed into the majority view. The result reads like notes from a room of specialists, not one opinion restated with more confidence.

Why is it called suggestibility.ai?

You may know the word from elsewhere, where suggestibility describes how readily a person takes on an idea that came from outside them. Here it means something narrower and far more useful: the willingness to genuinely consider a suggestion before deciding. That is a mark of good engineering, not a weakness. A team that cannot be moved by a good argument is not rigorous, it is stuck. Most review tools optimise for the opposite — confidence, a single voice that sounds certain. suggestibility.ai exists to produce suggestions worth being moved by, and to keep the ones that did not win on the record rather than smoothing them into false agreement. Hold the decision loosely enough to hear a real objection, and still decide yourself. The board advises, dissent included. You decide.

What makes this different from asking one AI model for feedback?

A single model has one set of blind spots, and it applies them consistently to every part of your document without ever noticing. A review board draws reviewers from different independent model families — different training data, different failure modes, different defaults — so a blind spot in one is usually visible to another. Where reviewers land on the same finding, you get real consensus, not a model agreeing with itself. Where they don't, you get a recorded disagreement with attribution, which is information a single-model review structurally cannot produce no matter how many times you re-run it.

What is preserved dissent, and why does it matter?

Preserved dissent is a minority position from the review that gets recorded on its own terms — who held it and what the majority concluded instead — rather than folded into an averaged summary. Most synthesis processes treat disagreement as noise to resolve before the output ships. This one treats it as a finding in its own right, because the reviewer in the minority is sometimes the one who's correct, and even when it isn't, knowing that one reviewer flagged a risk the others waved through is decision-relevant information. Averaging it away doesn't make the disagreement go away. It just hides it from the person who needed to see it.

Who is suggestibility.ai for?

Anyone who has to put their name on a technical decision and wants it checked before it ships: engineers finalizing an architecture decision record, platform teams writing a migration plan, security or compliance staff drafting policy, SREs closing out an incident postmortem, ML teams shipping a model card. It's built for the moment before a document goes to a real review meeting or a real audit — cheaper and faster than convening a room of senior people, and unlike a single reviewer, it can't rubber-stamp something just because nobody wanted to be the dissenting voice. It placed in the top 100 of 26,457 submissions in the Build with Gemini XPRIZE.

How the board works

How does a review actually run, step by step?

You submit an artifact and choose a board size. Each reviewer — a separate model from a separate independent model family — receives the same artifact and produces an independent review with no visibility into what the others wrote, so early answers can't anchor later ones. Once every reviewer has finished, a synthesis pass reads all of the individual reviews together, groups findings that overlap, marks agreement as consensus, and keeps disagreements as preserved dissent with attribution. The output is the review package: consensus, dissent, ranked recommendations, and severity-tagged findings you can trace back to the reviewer that raised them.

How does board size change what I get, not just how much it costs?

More reviewers means more independent model families weighing in, which raises both the odds that a real problem gets caught by at least one of them and the odds that a genuine disagreement surfaces instead of getting lost in a small sample. A three-reviewer board is fast — 45 to 90 seconds — and fine for routine documents. A five-reviewer board (1 to 3 minutes) and a seven-reviewer board (2 to 4 minutes) add more perspectives and proportionally more synthesis work, since each additional reviewer is a full separate review, not a longer prompt to the same model. Size is a call about how much dissent you want the chance to see, not just how fast you want an answer.

What is a synthesis pass, and who or what produces it?

The synthesis pass is a separate step that runs after every reviewer has finished, and its job is to reconcile — not average — the individual reviews into one coherent package. It groups findings that multiple reviewers raised independently into consensus, keeps positions that didn't reach agreement as preserved dissent with the holdout identified, and produces one set of ranked recommendations from across the board. It never sees another reviewer's output while that reviewer is still forming an opinion, because independence already happened at the review stage; its job is purely to reconcile what already exists, so it can't quietly erase a disagreement it doesn't like.

How long does a review take?

It depends on board size: a three-reviewer board finishes in 45 to 90 seconds, a five-reviewer board in 1 to 3 minutes, and a seven-reviewer board in 2 to 4 minutes. Every reviewer runs as a separate, complete review rather than a shortcut on a shared prompt, and the synthesis pass only starts once all of them are done, which is most of where the extra time on larger boards goes. There's no queue to wait in beyond that — you get the review package back in the same session you submitted the artifact in.

What's actually in the review package I get back?

Four things, every time: consensus, which is what the reviewers agreed on; preserved dissent, which is any minority position recorded with who held it and what the majority concluded instead; ranked recommendations, prioritized rather than left in the order reviewers happened to raise them; and findings, each tagged with a severity level and traceable back to the specific reviewer that raised it. Nothing here is an averaged score or a blended paragraph — every claim in the package can be traced to a reviewer, and disagreement between reviewers stays visible instead of being collapsed into one verdict.

How do you decide a finding's severity, and can I see who raised it?

Severity comes from the reviewer that raised the finding, and carries through into the synthesis pass rather than getting reassigned by some separate scoring step — if two reviewers raised the same issue at different severities, both severities and both reviewers stay visible in the review package instead of being averaged into one number. Every finding carries provenance: which reviewer raised it, so you can weigh a security finding from a security-focused reviewer differently than the same finding echoed by all of them. Provenance is what makes a finding checkable instead of a claim you have to take on faith.

What to submit

What kinds of artifacts can I submit?

Any technical document you need a second set of eyes on before it ships: architecture decision records, policies, design docs, runbooks, incident postmortems, model cards, and migration plans are the common cases, but the review board works on anything written down clearly enough for a reviewer to evaluate the reasoning in it. The common thread isn't the document type, it's that the artifact makes a decision or a recommendation someone downstream is going to rely on. If getting it wrong would cost you an audit finding, an outage, or a bad migration, it's a good candidate.

Does my artifact need to be finished before I submit it?

No. A draft with known gaps is a legitimate submission, and often the more useful one — catching a problem in an architecture decision record before it's finalized is cheaper than catching it after implementation starts. If a section is intentionally incomplete, say so in the artifact itself; reviewers work from what's on the page, so an unmarked gap can get flagged as an oversight instead of a known open question. The review board is as useful for pressure-testing a direction while it's still changeable as it is for a final check before sign-off.

What makes an artifact a strong candidate for review versus a weak one?

The strongest submissions state a decision or a recommendation and the reasoning behind it, not just a description of the current state. A design doc that says "we chose Postgres over DynamoDB because of X, Y, Z" gives reviewers something to actually evaluate; one that only describes the schema doesn't. Weak candidates tend to be documents where the hard decision was made somewhere else and isn't written down here, so there's nothing for a reviewer to agree or dissent on. If your artifact would generate an actual debate in a room of senior engineers, it will generate one on the board too.

Should I add my own context, or just paste the raw document?

Paste the artifact as it exists, but add anything a new reviewer joining the project would need and wouldn't otherwise have: constraints that don't appear in the document itself, prior decisions it depends on, or the specific question you actually want answered. Reviewers evaluate what's in front of them, so a migration plan reviewed with no mention of a hard compliance deadline will get feedback that's correct in general and wrong for your situation. You don't need to over-explain — the same amount of context a new hire would need is about right.

Can I run the same artifact through the board again after revising it?

Yes, and it's one of the more useful ways to use it. Submit the revised artifact as a new review — the board doesn't carry memory of the earlier version, so you get a clean independent read each time, not reviewers checking whether you did what they said. Comparing the two review packages side by side tells you whether the changes actually addressed the earlier findings and dissent, or just moved them somewhere else in the document. Treat it the way you'd treat sending a revised draft back to a human reviewer for a second pass.

Pricing and plans

How much does a review cost?

Three tiers, priced by board size: three reviewers for $15, five reviewers for $29, seven reviewers for $69. Each price buys one complete review of one artifact — every reviewer on the board does a full independent review, and the price covers that plus the synthesis pass that turns those reviews into your review package. There's no subscription requirement to run a single review; you can buy one board at a time for as long as that suits you.

What's the actual difference between a 3-, 5-, and 7-reviewer board?

More reviewers means more independent model families represented on that run, which means a wider spread of blind spots covered and more chances for a genuine disagreement to surface instead of staying invisible. It also takes longer: 45 to 90 seconds for three reviewers, 1 to 3 minutes for five, 2 to 4 minutes for seven, because each additional reviewer is a full separate review rather than a bigger prompt to one model. Three is a reasonable default for routine documents; seven makes sense when the artifact is about to be defended in an audit or a real incident review.

How does the subscription credit work?

Buy a single review, then subscribe within 30 days, and the full amount you paid for that review becomes account credit rather than a sunk cost. That means trying the board once, at whatever size fits the artifact in front of you, costs nothing extra if you decide to subscribe afterward — the $15, $29, or $69 you already spent carries forward. There's no separate trial tier or discounted first review; the credit mechanism is what makes a single purchase a low-risk way to evaluate the board before committing to ongoing use.

Why isn't a seven-reviewer board priced like a simple multiple of the three-reviewer price?

Because it isn't the same shape of product scaled up — a seven-reviewer board is one synthesis pass reconciling seven independent reviews of the same artifact into a single review package, not seven unrelated outputs stapled together. That reconciliation step, and the higher odds of catching a genuine three- or four-way split in reviewer opinion, is what the price on larger boards is actually buying. Every tier is priced against the same underlying work: separate, complete reviews plus one synthesis pass, scaled by how many independent perspectives you want represented before you decide.

Privacy and data

Is the artifact I submit kept private?

Your artifact and the resulting review package are tied to your account and aren't published, shared, or made visible to other users. Submitting a document for review doesn't put it anywhere public — it's processed to produce your review package and stored so you can come back to it, the same way any document you'd upload to a work tool would be. If your artifact contains information you wouldn't want outside your own organization, treat it the way you'd treat sending it to any third-party service: redact anything genuinely sensitive that isn't needed for the reviewers to do their job.

Do the reviewer models train on the artifacts I submit?

suggestibility.ai never trains on your content, on any tier. Where a review runs is what differs. Paid reviews run only on paid model endpoints whose terms do not permit the provider to train on submitted content. Free-tier reviews run on free endpoints, where a provider's own policy may allow it to retain and train on what it receives — that exposure comes from the provider's terms rather than from anything done here, and it is why the free tier suits trying the product rather than sensitive material. The privacy notice states this distinction directly, and each provider's current policy is the authority on its own terms.

Can I delete an artifact or a past review from my account?

Yes, by request. Your artifacts and review packages are tied to your account, and removal is handled by contacting the privacy address named in the privacy notice. There is no self-serve delete button in the product yet, so deletion today is a request rather than a click — worth knowing if you have a retention obligation that depends on timing. Signup records are kept until you ask for them to be deleted or until the early-access programme closes, whichever comes first, and consent records are retained as long as needed to evidence that consent was properly obtained.

Who can see the artifact I submit — is it visible to anyone besides me?

Just your account and the reviewers processing that specific run. The reviewer models see the artifact for the duration of that review, in order to produce their independent write-up; other users of suggestibility.ai never see it, and it isn't used to build any shared or public dataset. The findings, consensus, and dissent generated from it are scoped to your account, not aggregated into a benchmark, leaderboard, or anyone else's review.

For agents and developers

Can an AI agent submit an artifact for review on its own, without a person driving the browser?

Yes, through a WebMCP integration built for exactly that. A browsing AI agent working on a task — reviewing an architecture decision it just helped draft, for instance — can convene a review board directly, rather than needing a human to copy the document over and click through checkout. The review package comes back through the same integration, so the agent can read the findings and act on them, or hand them to the person it's working for.

Can an agent choose the board size itself?

An agent can recommend a board size based on what it knows about the artifact — flagging that a security policy probably warrants seven reviewers, for instance — but it can't set the size directly. Board size is determined by what's actually purchased, the same as for a human user, so an agent's recommendation still routes through a real purchasing decision rather than silently picking the most expensive option on your behalf. That keeps cost control with whoever is paying, not with the agent making the request.

What is WebMCP, and why build the agent integration on it instead of a custom API?

WebMCP is a standard for letting browsing AI agents interact with a website the way a person would, through the same interface, rather than requiring every site to publish and maintain its own bespoke API for agents to call. Building on it means an agent that already knows how to use WebMCP-enabled sites can convene a review board without suggestibility.ai having to hand-integrate with every agent framework separately. It's the same logic as building for a web standard instead of one browser: the integration surface is shared instead of duplicated per agent.