Research and Publication Methodology

Moonlight Peaks Tools turns public evidence into task-focused guides and browser tools. It does not treat search snippets, repeated claims, or an attractive interface as proof. Each published result should preserve enough source, date, platform, version, and confidence context for a later review.

Experience boundary

The site owner did not purchase or play Moonlight Peaks for this launch. The current material is desk research, not a firsthand review or a claim that a route, performance result, gift reaction, or bug was reproduced in the owner’s save.

That limitation is reflected in the language. “Official notes say this was fixed” is different from “we tested the fix.” A storefront compatibility label is different from a performance benchmark. A community recipe revision can support material arithmetic without proving that the recipe remains unchanged on every later patch.

Source priority

Sources are evaluated for the specific claim, not assigned one permanent score for every topic.

1. First-party and official platform sources. The game website, developer or publisher announcements, official patch notes, and storefront listings are preferred for release status, supported systems, prices, features, and stated fixes. Dynamic fields carry a check date and region where relevant.
2. Fixed community revisions. A community-maintained page may support a recipe, gift result, or reference fact when the exact revision can be reopened. It remains labelled as community material rather than developer confirmation.
3. Corroborated editorial evidence. A current, accountable guide can help confirm a gameplay observation or expose a platform/version difference. The project extracts the necessary fact and writes its own explanation; it does not copy the source’s prose, table, map, or walkthrough structure.
4. Single reports and moving pages. These are research leads. They do not become definitive defaults unless stronger, reproducible evidence is found.

A search result, AI summary, forum repetition, or another guide citing no source is not treated as an independent confirmation.

Fact extraction and original presentation

Research notes break a source into small claims: subject, value, unit, platform, region, game build or patch, source URL, source revision when available, and check date. Public pages then reorganize those facts around a visitor task such as choosing a platform, checking a patch status, or calculating materials.

The project does not publish a competitor article after swapping synonyms. It avoids reproducing proprietary paragraphs, complete tables, screenshots, maps, dialogue, or another guide’s selection and ordering. Where a source’s text is openly licensed, its license, attribution, modification, and share-alike requirements must still be considered separately.

Versioning and freshness

Changing values are snapshots. Platform availability, prices, discounts, demos, compatibility, patch status, and issue lists must show the last source check. A source date is not the same as a page-edit date, and an edit date is not advanced merely to make content appear fresh.

Evergreen facts can still change after a balance patch. Fixed wiki URLs include a revision identifier so that the input used by a calculator or table can be reopened even if the current wiki page changes. When a later source changes the fact, the site should update the displayed value, its dependent examples, tests, verification date, and any stale-status note together.

Conflicts, unknowns, and negative claims

Source conflicts are preserved with their context. The project checks whether the values refer to different platforms, regions, editions, demo builds, patches, quality levels, or measurement rules. If the difference cannot be explained, the values remain conflicting and no hidden default is selected.

Blank data remains blank. An unpublished character, gift, platform, or issue row does not prove that the subject does not exist. Negative claims such as “not available,” “not romanceable,” or “fixed” require evidence that actually supports that conclusion. Older official issue lists are labelled “not reconfirmed” when a later patch neither confirms nor rejects the item.

Calculators and interactive tools

Each calculator separates three layers:

• source inputs, such as a fixed recipe quantity and its revision;
• visitor inputs, such as desired bars or materials already owned;
• derived outputs, produced by visible arithmetic in the browser.

Units, rounding rules, minimum values, and exclusions should be stated next to the tool. Unknown processing time is not converted to zero, and a material calculator must not invent throughput, profit, or an optimal route that its source cannot support. Important formula paths are covered by deterministic tests before publication.

The Gift Finder’s public evidence rows are separate from a visitor’s observation log. A saved personal observation can disagree with a public row without changing the site’s dataset or confidence label.

Publication gates

A page can exist as a noindex research preview without being promoted as a complete search result. Initial indexable pages must have a clear intent, an early answer or usable interaction, source and version labels, sufficient evidence for their public claims, internal links, and no known launch-blocking technical errors.

Incomplete gift and character coverage stays outside the initial index set until reproducible source revisions are recorded. An index gate is a quality control, not evidence that preview content is secret or guaranteed accurate.

Review and correction

Before a dynamic page is promoted or materially updated, its primary sources are reopened and the displayed snapshot is compared with the current evidence. The Sources page lists the source classes and launch evidence register. The Corrections page explains how a confirmed error changes the public record and why unsupported observations remain research leads.