№ 08·0308 · Proof of Business2 min read · Section 3 of 6
8.3 What does not count
The inputs the Proof Ledger refuses — surface activity, intent without a result, duplicate claims, and unadopted output — and why exclusion protects scarcity.
Updated
8.3 · Exclusions
Half the credibility of PoB comes from what it admits. The other half comes from what it refuses to record.
The scarcity of PoB rests on a double gate: it admits a high-standard result and it refuses inputs that are easy to forge, repeat, or outsource. Without exclusions, the network repeats a distortion Web3 has already seen — optimizing the snapshot rule instead of optimizing delivery.
What this page doesMarks the outer edge of PoB and the basis for review
Reading highlightsPlain exclusions; the gaming surface; why proxies fail
Activity that has not reached a result
Posting, reposting, group-building, an introduction with no follow-through, an intent negotiation, and "help" with no deliverable do not form a PoB object. The reason is structural: the marginal cost of copying these actions approaches zero, and none holds a stable causal chain to a business outcome. Record them, and incentives flow to volume and visibility rather than output.
Pure reachImpressions, likes, and member counts on their own. Like airdrop interaction volume, they can be farmed and rarely link to delivery.
Introduction without a loopKnowing someone is not advancing a signature or a payment. The observable result and evidence of 8.2 are still required.
Plans and intentA letter of intent, a verbal consensus, an exclusive negotiation — none counts as a closed deal.
Claim without evidenceClaiming to have led, with no dated material and no third-party trace, means the result cannot be re-reviewed.
Pseudo-contribution and the gaming surface
Some inputs reach the result layer but distort attribution. The verification process targets each one, and escalates to a Verdict when a dispute cannot be reconciled.
Duplicate claimSeveral parties each claim sole lead on one result. Event numbering, timestamps, and mutual-exclusion rules apply; a contested case ends in a Verdict.
Last-mile captureA party appears only at the final step with no record at the key nodes. Attribution follows whoever cleared the blocking condition (see 8.5).
Volume over valueThe same failure as a points system: what is loud is noise, and what is quiet is often the real advance.
Output not adoptedAgent or script output that no human or customer adopted is the same as undeployed code. It is not a business result.
Wash and recyclingWash volume and circular liquidity. When evidence comes only from controllable parties with no external beneficiary, review tightens.
Stitched or backdated evidenceTimestamps are cross-checked against third-party records. Material must be complete, accurate, and not misleading; fabrication is rejected outright.
Why this differs from common Web3 rewards
Each common reward optimizes a proxy that detaches from real work. PoB raises the cost of scoring so that a real closed loop is worth more than a farmed one.
Airdrops and tasksOptimize rule-programmability, not delivery quality. The cost of a fake can fall below the cost of a real customer.
StakingOptimizes capital lock, not service completion. A large holder may close no customer loop at all.
Points rankingOptimizes short-term action frequency, which detaches easily from real advancement.
The PoB responseA real closed deal outpays a high score. That is the economic core of anti-gaming, not a moral appeal.
If "what does not count" is enforced loosely, PoB dilutes into another marketing score. Strong enforcement rests on consistent review standards and transparent records of every supplement and rejection (see 8.4).
Exclusions protect the scarcity of results and the return to honest nodes. What they harm is the settlement meaning of the whole network.
