Puzzle design research
What We Refuse to Claim About Our Own Games
It would be easy to describe every game as popular, brain-boosting, and the best in its category. None of those statements would be backed by anything this project has measured. The repository's evidence contract treats claim, evidence, and review as separate steps, and that separation has a visible cost: there are things these guides simply do not say. Naming them is more useful than implying them.
What this guide helps you decide
A game publisher can claim anything about its own games. What does BeanNest decline to claim, and why?
This research states the claim boundary applied to BeanNest game documentation. It is a description of policy and practice in this repository, not a statement about other publishers.
Try it on the anchor product: BeanNest Games /games/.
No popularity or ranking claims
Describing a game as the most played, the best, or a favourite requires traffic data that this project does not publish and would not use in marketing anyway. A game page states what the game is and how it works. It does not state how many people play it, because that number is not offered as evidence.
No difficulty guarantees
Describing a puzzle as easy, hard, or suitable for a skill level is a claim about how players experience it. This repository has not measured completion rates or solving times, so difficulty language is limited to what is structurally true, such as the number of difficulty presets a game offers. A preset name is a fact; a difficulty judgement is not.
No cognitive or health benefits
The repository explicitly excludes brain-training, memory-improvement, and medical claims. Even phrasing a puzzle as good for your brain implies an outcome study that does not exist here. Games are described as what they are: structured problems with stated rules.
No performance promises
Statements about speed, battery use, or frame rate depend on the device and the browser. A guide can describe a mechanism, as the device research does, but it cannot promise a performance result on hardware it has not measured. This is why the device guides publish measurement limits rather than benchmark tables.
No comparison claims against competitors
A comparison against another product requires evaluating that product, which this repository does not do. Comparisons here are between BeanNest games, using each game's published rules, and they are scoped to mechanics that both games actually document.
Why the boundary is worth stating
A reader who knows what a publisher will not claim can calibrate the claims it does make. Publishing the boundary costs nothing and makes every other statement more credible, which is the same reasoning behind publishing measurement limits in the other research clusters.
Why a claim needs evidence to be useful
A claim backed by nothing cannot be checked, so a reader has to accept or reject it on trust. A claim backed by a measurement can be verified, which makes it more useful even when the measurement is unflattering. This is why the guides prefer a small measured statement about a corpus over a large unmeasured statement about a category.
How the exclusion list is written
Each game guide declares the claims it intentionally excludes, alongside the claims it makes. That turns an absence into an explicit statement, so a reader knows a missing claim was a decision rather than an oversight. The same structure is used in every research guide in this corpus, which is why the exclusion lists are comparable across clusters.
Why the boundary applies to research guides too
The research cluster about puzzle design follows the same rule as the game guides. It cites repository evidence, states what that evidence supports, and declines to generalise beyond it. Applying the boundary consistently means a reader can calibrate every page in the corpus rather than adjusting expectations by page type.
What a reader gains from the boundary
Knowing what a publisher will not claim makes the claims it does make easier to weigh. A guide that declines to rate difficulty is more credible when it does report a measured byte count, because the reader can see the same standard applied to both. The boundary is therefore not a limitation on the corpus but part of what makes it usable.
How the practice shows up in this corpus
Every guide here carries an exclusion list alongside its claims, and every measured figure names the file that produced it. The practice is therefore visible in the published pages rather than only described in this guide, which lets a reader verify that the standard is applied rather than merely announced.
Why difficulty and popularity are excluded together
Both would require data about player behaviour that this repository does not collect and does not publish. Excluding them together keeps the rule simple: a claim about how people experience or choose a game is not made, while a claim about what the game does is. That line is easy to apply and easy for a reader to check.
How the exclusion applies to performance claims
Performance depends on hardware and browser, so a claim about speed would require measurement across a device set this repository does not maintain. The device cluster instead publishes measurement limits, which is the honest version of a performance statement: it describes what can be measured rather than asserting an outcome.
What a reader should expect across the corpus
Expect measured figures with named sources, explicit exclusions, and stated limitations. Expect no ratings, no benefit claims, and no comparisons against products this repository has not evaluated. A reader who knows that in advance can weigh every page against the same standard.
How the standard is enforced rather than announced
Each guide declares its exclusions in the published page, and each measured figure names the artifact it came from. A reader can therefore check that the standard is applied by reading any guide in the corpus, which is a stronger form of assurance than a policy statement about intent.
Why this guide belongs in the corpus
A reader who encounters measured figures throughout the corpus benefits from understanding the rule behind them. Stating the boundary explicitly makes the rest of the corpus easier to interpret, which is why this guide sits alongside the others rather than in a separate section about policy.
How a reader can verify the standard across the corpus
Open any research guide and look for two things: a measured figure with a named source artifact, and a list of claims the guide declines to make. Both are present in every guide here, so the standard can be checked by sampling rather than by reading the whole corpus. That checkability is what makes the boundary a practice rather than a statement of intent.
Why the boundary costs nothing to publish
Declining a claim removes an obligation rather than creating one, so publishing the exclusions adds no risk and no maintenance burden. It does make the remaining claims easier to trust, because a reader can see that the same author is willing to say what is not supported. The guide treats that trade as obviously favourable, which is why the practice is applied everywhere in the corpus.
First-party evidence and provenance
How we checked this
We reviewed the repository's evidence contract for its stated claim exclusions and confirmed that each exclusion is reflected in the published game documentation and in the research guides in this cluster.
- Method
- We reviewed this repository's evidence contract and the published game metadata, then traced the shipping behaviour to confirm the mechanism described here. We deliberately did not read or publish a hidden solution state.
- Environment
- Repository source review of the current main branch. No live traffic, account data, or player-identifying information was read.
- Captured
- Reviewed by
- BeanNest Studio
Repository evidence artifacts:
docs/gameplay-reconstruction/EVIDENCE-CONTRACT.mddocs/platform/MODULE-OPERATING-MODEL.md