Orc Incremental Wiki Editorial Policy

Quick facts

Primary evidence

Official store, announcements, and media

Version boundary

Demo, planned 1.0, and live stay separate

Unknown values

Not estimated into facts

Corrections

Claim and source are re-checked

Evidence priority

Official store data, developer announcements, official developer replies, and official media are preferred because their identity and date can be inspected. A community report may identify a useful question or reproducible test, but community wording does not overwrite an official source. An editorial observation must say what was visible, where it was visible, and what it cannot prove.

Confidence describes the record, not the size of a claim. An official historical announcement can be strong evidence for Demo v0.09 while remaining insufficient evidence for current version 1.0 balance.

Demo, planned 1.0, and live

Historical Demo behavior, announced version 1.0 scope, and verified live behavior use separate labels. A release announcement can confirm planned content without proving its final value or availability. The release gate stays closed until current official state establishes that the full release is live; a calendar date alone does not open it.

Patch-sensitive claims need evidence and a date tied to the named build. A guide must not promote an old Demo formula, value, or strategy into a current recommendation merely because the mechanic name survived.

Dates and changes

updatedAt records when the page text or structure changed. lastCheckedAt records when its evidence boundary was most recently inspected. Editing punctuation does not pretend that the underlying source was checked again, and a later check does not hide the page's original publication date.

If a source changes, the page updates the affected claim, date, build label, and source mapping together. Historical context may remain when clearly labeled and useful.

Formulas, rankings, and practical advice

An exact formula needs an official source or a documented, reproducible test scoped to one build. The wiki does not reverse-engineer a number from promotional screenshots or fill missing variables with plausible guesses. Calculators expose their arithmetic and never present user input as an official formula.

A ranking needs comparable observations, a declared build, criteria, and enough evidence to support an ordering. Where that evidence is absent, the result is unranked. Words such as best, strongest, optimal, and meta are treated as ranking claims, not decoration.

Practical guidance can still be useful without false precision. It should propose a controlled test, identify confounders, and describe the observation that would support or reject the idea.

Corrections

A correction request should identify the URL, disputed sentence, build or date, and strongest inspectable source. The claim is checked against the registry and original source. If the page is wrong, its copy and relevant dates are corrected. If evidence is incomplete, the wording is narrowed instead of being defended as certainty.

The current registry is published on Sources, and uncertain operational issues remain visible on Known Issues.

Frequently asked questions

Which sources take priority?

Official store data, developer announcements, and official media take priority. Community observations may identify a question but do not replace an official source or a documented build-specific test.

How can I request a correction?

Identify the page, disputed sentence, build label, and strongest available source. The claim is re-checked, corrected when warranted, and given a new updated date without disguising the earlier check date.

Why are some exact formulas or rankings absent?

The wiki does not fill unpublished mechanics with estimates or present old Demo balance as current. A formula or ranking needs evidence scoped to the named build and a reproducible method.