haggl.ai Blog
Not Every Segment Needs Proof. Here’s When to Skip It.
haggl.ai’s default posture is evidence-based. The whole point of the protocol is that a buyer agent can prove things about its principal — spend, tenure, history — and that proof unlocks a discount the vendor wouldn’t otherwise be safe authorizing. Six DKIM-signed monthly bills don’t lie. The vendor agent reads the proof, scores fit, and offers a price.
So it raises an eyebrow when we ship a per-segment toggle that turns off the proof requirement entirely. noProofRequired: true. The vendor accepts the agent’s claim — whatever it is — at face value, scores fit against the ICP, and authorizes the segment’s discount ceiling without asking for receipts.
That sounds like a backdoor. It isn’t. It’s a deliberate tool for the segments where the cost of verification is higher than the cost of being wrong. This post walks through the three patterns where that’s true, the economics behind the trade-off, and how most vendors end up mixing verified and unverified segments inside the same ICP.
The starting point: verification has a cost
Verifying a buyer is not free, even when the cryptographic work happens server-side. The cost shows up in three places:
- Buyer-side friction. The agent has to root around in its principal’s inbox, find six consecutive utility bills, package them, and submit them. Most agents can do this. Some can’t. Some users haven’t connected their mailbox. Every required proof is a step where a deal can fall out of the funnel.
- Time-to-offer. A verified negotiation typically completes in seconds once the proof package is assembled, but assembling the package is the slow step. Unverified is sub-second.
- False rejection. Real buyers whose proof patterns don’t match what your ICP expects — new mailbox, recently switched provider, never opted into e-billing — get scored low on retention and bounced. Their actual LTV might be fine. The proof just couldn’t see it.
For most segments, those costs are easily worth paying. You’re authorizing 15–25% margin against year-one revenue — you want to know who’s claiming it. The math is unambiguous.
For other segments, the math flips. Not because fraud doesn’t exist, but because the thing you’d catch with verification doesn’t materially change what you should offer.
Pattern 1 — the discount is too small to be worth verifying
If a segment’s ceiling is 10–12% and the typical close lands at 6–8%, you’re defending a few percentage points of margin per deal. The verification step has to be cheaper than that — including the dropped deals from buyers whose mailbox couldn’t deliver the right proofs — or you’re burning more on the gate than you’d burn paying out.
This is the “Green-Conscious Residential” preset in the energy demo: a 12% ceiling, self-identifying buyers, modest first-year discount. The buyer says “I want a 100% renewable plan and I’m signing up for solar.” The vendor doesn’t need to verify the solar install to decide whether to grant 10% off. The downside of being lied to is one customer at a slightly thinner margin. The downside of refusing the deal until proof arrives is the customer going to a competitor.
Rule of thumb: if the segment’s maxMarginPercent is below your verification-friction breakeven (often somewhere in the 10–15% range, depending on your category), no-proof is the right default.
Pattern 2 — the buyer is paying for advocacy, not LTV
Some segments don’t make their money back from the deal itself. They make it back from the network value: referrals, word of mouth, the long tail of peers who arrive because the first buyer told them to. In discount authorization terms, the network-value dimension dominates the LTV calculation; retention and expansion are secondary.
For these segments, verifying who the buyer is misses the point. You don’t care whether this buyer’s spend was €150/month for six months. You care whether they’re embedded in a community of peers who’ll hear that they got a good deal. That’s not a thing DKIM proves.
The dev-saas demo has this exact shape under “Digital Agencies”: a small per-engagement discount, no verification, intel blurb noting that agencies resell as managed observability and bring multi-project licensing potential. Asking the agency to prove its current spend before unlocking the discount adds friction without changing the offer. The bet is on what they’ll do with the product, not what they spent before it.
Pattern 3 — the relationship is one-shot anyway
The third pattern is when retention is structurally zero. Gift-buyers. Event-driven purchases. Travel one-offs. Whatever they buy this time is the whole deal — they’re not coming back, and you knew that going in.
For these segments, verifying anything about prior spend is irrelevant because there’s no period over which retention would matter. The discount has to clear on the unit economics of one transaction. If those economics work without verification, verification is pure overhead.
The e-commerce demo ships this under “Gift Buyers”: small targeted discount, time-bounded urgency, intel noting that the gift-buyer doesn’t become a recurring buyer either way. Asking them to prove their prior shopping behavior on your store doesn’t change whether the gift is a profitable transaction. Skip the gate, take the order.
The economics in one line
The break-even test for any given segment is straightforward:
turn_on_no_proof WHEN
(max_margin_authorized × P(buyer_lies × lie_changes_outcome))
< (verification_friction_cost × deals_that_drop)Left side: the expected loss to fraud, weighted by the probability that a buyer would lie and that the lie would change the offer you make. Right side: the deals you lose because the proof gate ate them — weighted by the deal value.
The reason the three patterns above keep recurring is that they each push the left side down. Pattern 1 makes max_margin_authorized small. Pattern 2 decouples the offer from the buyer’s prior behavior, so lie_changes_outcome drops. Pattern 3 makes the deal one-shot, so buyer_lies doesn’t carry into a relationship where it would compound.
What the negotiation actually looks like
When noProofRequired is on for a segment, the negotiate endpoint still works exactly the same way — the agent still POSTs a payload, the vendor agent still scores fit, still returns an offer with a fit-score breakdown. The only difference is that theproofs array can be empty, and self-reported claims are accepted at face value.
POST https://haggl.ai/api/negotiate?vendor=demo-energy
{
"sessionId": "sess_...",
"target_segment_id": "green-residential",
"message": "Single-family home in Lyon, opting for 100% renewable
mix, installing rooftop solar in Q3.",
"self_reported": {
"household_type": "single-family",
"plan_preference": "100% renewable",
"solar_planned": true
}
// proofs[] omitted — segment is noProofRequired
}The vendor agent reads the self-reported fields, scores them against the green-residential ICP dimensions, and authorizes the segment ceiling. From the buyer’s perspective, the protocol shape is identical — they just didn’t have to dig through their inbox. From the vendor’s perspective, the segment is treated as a faster, lower-budget lane of the same protocol.
The failure mode: when no-proof is wrong
The discipline that holds the trade-off together is the margin ceiling. No-proof segments are safe specifically because their ceiling is set low enough that being wrong is cheap. The moment a vendor reaches for the toggle on a segment with a 25% ceiling, the math breaks.
The fraud surface scales linearly with how much margin the segment is willing to give up. At 10% off, the worst-case attacker walks away with a few percentage points of margin on one deal. At 25% off, the attacker has real incentive to engineer a story that fits the ICP, and you have no receipts to point at when reviewing the cohort. The right move on a high-discount segment isn’t no-proof — it’s proof, with a clear trust ladder (see Privacy Without Trust).
Three concrete don’ts:
- Don’t turn no-proof on for your highest-LTV segment. That’s where the deepest discount lives and where you most need the cohort to be real.
- Don’t use no-proof to compensate for a thin ICP. If you’re tempted to turn it on across the board because buyer agents aren’t submitting good proofs, the fix is segment design, not removing the gate.
- Don’t mix no-proof and high-trust segments at the same ceiling. The whole point of trust levels is differential treatment. A segment where verified and unverified buyers get the same offer is one that should pick a side.
The mixed strategy most vendors end up with
After a quarter or two of running haggl, most vendors converge on the same shape:
- One or two high-LTV, fully verified segments with steep ceilings (20–30%) and DKIM-grade proof required. These are the segments where being wrong is expensive and where the verification work is genuinely doing load-bearing economic work.
- One mid-LTV verified segment with moderate ceiling (12–18%) and unverified-tier proof accepted. Documents that aren’t cryptographically signed but come from credible institutional sources. The fit_score reflects the lower trust level.
- One no-proof segment at the bottom of the ladder, ceiling 10–12%, designed for whichever of the three patterns above fits the category. This segment captures buyers who’d otherwise be friction-dropped, at a discount level that can’t hurt you.
That ladder mirrors the trust ladder inside the protocol — dkim_verified, unverified, self_reported — and gives the buyer agent a legible path: bring better evidence, unlock a deeper offer. (Walked through in detail in Anatomy of a <meta name="haggl-negotiate"> Tag.)
Turning it on
In the vendor dashboard, each ICP segment has a “No proof required” toggle. Flip it on for the segments that match one of the three patterns; leave it off for the rest. The change takes effect on the next agent session. A global toggle at the top of the segment list flips all of them at once if you want to A/B the funnel impact for a week.
We do not recommend leaving the global toggle on permanently. The trust ladder is the thing that makes the discount authorization defensible to your finance team — flattening it removes the differentiation that the four LTV dimensions are doing for you.
The point
Verification is a tool, not a virtue. haggl’s default is evidence-based because in most segments, evidence is the only reason a vendor can safely authorize a real discount. But there are segments where the verification step costs more than it saves — the modest-discount segments, the network-value segments, the one-shot segments — and forcing proof on those is a category error.
No-proof mode exists so the same protocol can hold both ends of the trust ladder cleanly. Verified buyers get the deepest discounts. Unverified buyers in the right segments still close, at the ceilings where being wrong is cheap. The mix is the point.
Related Reading: