Current status
The developer states that data testing is still in a trial phase. Treat this as a version-risk condition: current behavior, progression and content can change, so a guide should carry the date and context of important observations.
The warning
A future update may cause player data to be lost. That makes current progress less permanent than in a fully stabilized release. The warning does not establish when a reset will happen, how much data would be affected, or whether restoration would be available.
Practical response
Keep records of any setup you would want to recreate and check update notes before assuming old data or strategies still apply. Save visible labels, arrangement choices and dates, but do not send account credentials or treat a screenshot as proof of a hidden formula.
How to interpret changing behavior
When a result changes, first check whether the game version, arrangement or test conditions also changed. Mark the result as observed until the same behavior can be reproduced. Only promote it to a guide rule when the evidence remains consistent and the source is clear.
Why the Wiki avoids unsupported numbers
A testing phase makes copied values especially risky: a number may belong to an older build, a different condition, or a community interpretation rather than to a confirmed field. The wiki therefore avoids filling pages with equipment stats, damage, rarity, rates, or formulas that cannot be checked.
Player data risk
The warning about possible future data loss affects both progression and the usefulness of old observations. Keep a dated record of important setups, but do not assume that a screenshot restores data or that a strategy remains valid after a meaningful update.
A safe evidence workflow
Start with the public statement, identify what it actually says, observe the current interface, and record the version and conditions. Label the result confirmed, observed, unverified, or awaiting verification. This workflow makes uncertainty explicit instead of hiding it behind confident prose.
Testing phase and guide freshness
A testing phase means that a guide can be accurate for the observation date and still need review later. Readers should pay attention to whether a statement is a stable description, a dated observation, or a procedure that depends on current controls. The page should preserve older observations rather than silently presenting them as current behavior.
What players should record
Record the visible version context, the arrangement state, the exact prompt or feedback, and the outcome that followed. Do not record private credentials or present a screenshot as an official backup. The aim is to make a comparison possible, not to claim that player notes can prevent a future data loss.
How the Wiki updates confidence
A claim can move from awaiting verification to observed when a current, reproducible test exists. It can move toward confirmed only when the source or behavior is clear enough to withstand review. A single successful test is useful evidence, but it is not automatically a permanent mechanic or a formula.
Confirmed, observed, unverified, and awaiting verification
Confirmed information has a clear developer statement or stable public source that supports the precise claim being made. Observed information records behavior seen under identifiable current conditions but allows for version changes and unknown causes. Repetition can strengthen an observation, yet it should remain narrower than the evidence permits. Unverified information lacks enough reliable support to publish as fact, even when it sounds plausible or appears in community discussion. Awaiting verification marks a specific question or field that the Wiki intends to leave open until suitable evidence exists. These labels describe confidence, not importance, and they help readers distinguish usable facts from unresolved possibilities.
How information becomes publishable
The verification process begins with a precise claim and a source or test that actually addresses it. For observed behavior, the record needs the current conditions, version context, visible input, and visible outcome. A second comparable observation helps show whether the result is repeatable, while conflicting results require the claim to remain limited or awaiting verification. One test or one player report can identify a useful lead, but it cannot establish a hard value, universal rule, or permanent mechanic. Reports may omit a changed arrangement, a different version, or another condition. Publishing conservatively prevents missing context from becoming false precision.
Using incomplete and older information
Readers can use incomplete information by matching the certainty label to the decision. Confirmed relationships provide the stable foundation. Observations can guide a current comparison when their conditions still match. Unverified claims should remain questions, and fields awaiting verification should not be filled with estimates merely to make a page look complete. Older information may become outdated after the interface, content, saved data, or observed behavior changes. Preserve its date rather than silently treating it as current. When an old result no longer reproduces, check the present version and conditions before deciding that a player made a mistake.
How testing affects other site sections
The Database should contain structured fields only when the entities and values can be verified; missing data is safer than invented completeness. Stats require dated snapshots because activity changes over time. Codes require a confirmed code and redemption context rather than copied lists. Updates should distinguish observable changes and public dates from unsupported patch descriptions. The same rule applies across gameplay guides: publish the strongest supported wording and show the remaining boundary. Data Testing does not promise a wipe date, reset schedule, restoration process, or developer plan. Progression and saved data may not be permanent, but the scope and timing of any future loss remain not currently documented.