1
1 Comment

I built a verification system for my product. Its first act was to catch me inflating my own score.🐝

🐝MoltyBeeAI™ — M2 Shipped: Introducing 🐝 MoltyBeeAI™ v3.2 🚀

Two weeks ago I posted here about scoring my own startup with my own product and shipping the 34/100 it gave me. Here's what happened next.

The ceiling nobody could see

My scoring rubric tags every criterion VERIFIED or self_reported, and only VERIFIED criteria count toward benchmarks. Sound rigorous. There was one problem:

Nothing could ever become VERIFIED. The intake collected claims, not evidence. So every business — good, bad, honest, exaggerating — hit exactly the same benchmark-eligible score of 16/100. Percentiles computed on that distribution would have been noise wearing a suit.

So M2 started with evidence intake. And the design took three attempts, because my first two were quietly dishonest.

Attempt one: does the URL resolve? A server answers, you get credit. I built it, tested it, and realised it verifies nothing. A customer could paste their homepage into every field and pass. You cannot call that "verified" and keep a straight face.

Attempt two: read the page, let the AI judge. Better — but an LLM asked "does this page support the claim?" is a system you can talk your way past.

Attempt three, the one that shipped: a deterministic marker floor before any model reasoning. A checkout page must contain a currency pattern AND a purchase action. A case study must contain measured outcome AND verifiable or checkable named attribution. Regex doesn't negotiate. Only artifacts that clear the mechanical floor become eligible for VERIFICATION — and then the model can still refuse, but it cannot grant beyond the eligible list.

Test results, on real pages:

real checkout page: PASS
generic homepage: BLOCKED — missing: a stated price, a purchase mechanism
coming-soon page: BLOCKED — missing: a stated price, a purchase mechanism
real case study: PASS
vague testimonials: BLOCKED — missing: measured outcome language, attribution

Then it caught me:
First live run with evidence: my benchmark score jumped 16 → 37. Ceiling broken. I was delighted for about ninety seconds, until I read the flags.

I'd pasted www.moltybeeai.com into four separate evidence fields. All four passed — my pricing, FAQ, positioning and metrics genuinely do live on one homepage. But the system had flagged same_url_multiple_fields, and I'd built flags as advisory rather than binding.

Here's the uncomfortable part: the system couldn't tell my honest one-page site apart from someone else lazily pasting the same link four times. Identical evidence, opposite intent. When a rule can't distinguish honest from dishonest, the right call is to refuse both and give the honest party a way to prove it.

So I shipped duplicate-URL exclusion. My own score dropped. Correct outcome.

Verdicts, not vibes™.
That's the whole product.🐝

What else shipped:
•Real auth. Lockout in Postgres so it survives redeploys. Timing equalised so unknown emails still burn a full hash comparison — you can't probe which accounts exist by watching response times. Every auth event in an append-only trail.

•A member dashboard that shows the truth. Score, verified standing, dimension bars, evidence findings, gap roadmap. Nothing fabricated. The demo dashboard I'd built earlier — deleted. Live data & full integrations coming-soon, on top of your current Live Hive Member™ dashboard. And your available real data now.

•Structured roadmaps. Here's the piece I'm most proud of. The 30/60/90 roadmap used to be prose inside a PDF. Now each initiative is a record, and each record carries the scoring criteria it claims to move. Mark it complete, re-audit, and the system checks:

verify M1-1: CONFIRMED | RA-3 moved 0→4 | +4 points
verify M1-2: unconfirmed | no linked criteria moved

Evidence verification, applied to work instead of claims.

•Trajectory that respects noise. Four production runs on an unchanged business gave 34, 34, 36, 34 — so run-to-run variance is about ±2. The improving/declining threshold is 3. If it says you improved, you improved.

Verdicts, not vibes™.
That's the whole product.🐝

The thing I'd tell anyone building something similar.

Every mechanism that moves judgement from the model to the server makes your system more defensible. Deterministic markers, server-side arithmetic, database constraints, version pinning. The AI should do what only AI can do; everything else should be checkable & verifiable by someone who doesn't trust you.

And build the integrity layer before you have customers. Mine cost three days at under ten customers. At a thousand it's a migration, a credibility problem, and a lot of awkward emails. So I'm grateful we've already built a future proofing mechanism to ensure that we never have to experience that problem or issue at massive scales.

Introducing 🐝 MoltyBeeAI™ v3.2 🚀

The all new audit is now LIVE at www.moltybeeai.com. Founding Hive™ pricing while it lasts. It rises soon.

We recently ran 🐝MoltyBeeAI™ through the platform again, it scored us 48. Real initiatives, real scores, based on a moving & improving startup business.(VERIFIED & checked)

I'm super excited to hear about what you discovered & your honest feedback on everything. Go now!

Phase 1 of 4.
Phase 2 shipping next.🐝🚀

•Building 🐝MoltyBeeAI™ in public.

🐝Thank you,

— Sihle Dimaza, Founder & Operator
🐝MoltyBeeAI™

on August 8, 2026
  1. 1

    The strongest design choice here is putting a deterministic evidence gate before the model. A URL resolving only proves availability, not that it supports a claim; requiring domain-specific markers creates a much clearer boundary for what counts as evidence. The duplicate-URL case was especially revealing too: the same evidence can represent a legitimate one-page site or lazy overclaiming. Will you eventually distinguish those cases through provenance, or is refusing both the safer default?