About The Sift Minecraft: Sources & Editorial Standards

An independent Sift wiki with a clear scope

These editorial standards explain how this independent fan resource documents the Minecraft dimension and the different experiences associated with it. The site is not an official Minecraft website and is not approved by or associated with Mojang or Microsoft. Its purpose is to organize reliable information into practical reading paths for players, especially when official announcements and community mods appear in the same search results.

The first edition is in English, with the same editorial standards applied to every public guide. It covers the dimension overview, edition differences, entry information, two separate mod projects, a field guide, a dated timeline, and a version-checking tool. It does not present the unrelated Roblox Sift experience as Minecraft content, and it does not offer a browser version of either game.

The site’s authority should come from visible evidence and useful explanations, not from claiming official status or an invented expert biography. Our editorial standards prohibit claiming an independent gameplay test where none was performed. A reader should be able to identify what a statement means, which implementation it concerns, and where to check it.

The Sift wiki evidence hierarchy

Official publisher material is the first reference for the official product, announced schedule, and expressly documented features. A mod author’s project and file pages are the first reference for that author’s implementation. Community discussion can reveal useful questions, but it does not automatically establish an official mechanic or release state.

The editorial standards keep these evidence classes visible because they answer different questions. An official announcement can establish a plan without supplying a detailed walkthrough. A file listing can establish a distribution record without proving that an entire modpack works. A player observation can be valuable when its conditions are recorded, while remaining narrower than a universal game rule.

A source on an official domain is not necessarily an official announcement. User-submitted feedback, for example, must still be treated as a player’s suggestion unless the publisher separately confirms it. Likewise, several summaries repeating one source do not create several independent confirmations. The useful task is to trace the claim to its actual origin.

Version context is part of every claim

A mechanic belongs to a game and often to a particular version or project. Our editorial standards separate Dungeons II, vanilla Java, vanilla Bedrock, Mielon’s mod, and Wellspring. A shared dimension name does not collapse those contexts into one dataset. The version checker follows the same rule as the articles.

When a claim needs a file-level reference, the record should identify the actual game version, loader, and mod release. Project-wide tags are not enough to create every possible pairing. If the dependency set has not been checked, the record should say so. A partially verified installation reference must not be made to look complete through inference.

The same principle applies to entry instructions. A sound-based mod procedure and a key-based mod procedure should remain separate. An official rift concept should not inherit either one merely because it lacks a full walkthrough in the reviewed material. Clear scope is often more useful to a player than a longer list of instructions.

How dates are used

These editorial standards accompany the first edition, whose source review date is September 27, 2026. That date describes source checking, not gameplay testing or a publisher’s release event. Publication dates, file-upload dates, announced launch dates, and editorial review dates have distinct meanings. The updates log preserves those distinctions.

A relative phrase such as “next year” should be interpreted in the source’s publication context. An announced date should remain an announcement until additional evidence establishes the release state. The tool also avoids automatically promoting a schedule to “available” when the calendar passes the expected date.

A page should receive a new review date when its evidence is meaningfully checked, not because a server rendered it today. This gives readers a useful way to judge freshness. A historical article can remain accurate about an announcement while requiring a new check before it answers a present-tense question about availability.

What completeness means here

The editorial standards define completeness as answering the meaningful questions supported by the game and its evidence. Completeness does not mean filling every possible table with guessed numbers. At the current snapshot, detailed official creature statistics, full biome mapping, recipes, drop rates, and some access conditions remain unverified.

The field guide makes those gaps visible in one coherent reference. It avoids creating a separate, nearly empty page for every speculative name. A dedicated article becomes useful when it has enough sourced information to answer an independent question. Until then, a consolidated page is easier to navigate and less likely to imply that a finished catalog exists.

This standard also applies to wording. “Not verified in our reviewed sources” is different from “does not exist.” “The author lists a matching file” is different from “your installation will work.” Our editorial standards preserve those distinctions even when a shorter, more absolute answer might sound more confident.

Original writing and visual material

The articles organize and explain the research in original language, with links to primary sources for the claims they support. They are not copies of competing wiki pages. Search terms help us understand player questions, but they do not justify copying another site’s text, images, or unsupported game data.

Under these editorial standards, the site’s original landscape illustration must be identified as concept art. It is labeled as concept art and is not a gameplay screenshot, map, or proof of a specific in-game object. Decorative visual choices should never be used to settle a factual question about the dimension.

The editorial standards for third-party material require separate attention to origin, permission, and attribution. A mod project’s license label does not automatically establish rights over every texture, trademark, image, or embedded asset. This site links to the official and author pages rather than presenting those materials as its own. The visual identity is deliberately distinct from an official Minecraft product interface.

Corrections and reproducible research

To meet the editorial standards for corrections, identify the page, disputed statement, relevant game or version, and a source or test record. If a claim concerns an installed mod, include the exact filename and loader. If it concerns an announcement, include the original URL and publication date. These details make the difference between an actionable correction and an ambiguous disagreement.

The editorial standards also apply to contact information: the first edition does not publish an unconfigured contact form or pretend that a support inbox is monitored. Keep the source details if you discuss a correction with the site operator through a channel they provide. For game bugs and mod support, use the relevant publisher or author’s actual support channel rather than treat this independent guide as the maintainer.

Do not include account passwords, private tokens, or unrelated personal information in a public report. A concise reproduction record should focus on the technical conditions and observed result. The editorial goal is to establish what needs changing and why, then update every affected guide and tool record consistently.

A useful starting point, not a promise of perfection

These editorial standards are designed to make research easier: choose an edition, understand its evidence, and find the next relevant source or guide. It does not guarantee rankings, exhaustive future coverage, uninterrupted third-party availability, or compatibility with every installation. Those outcomes cannot be established simply by publishing a confident page.

Use the overview to begin, the checker for a scoped setup question, and the timeline for the current research boundary. The source directory below provides direct routes to the material used in this edition. Read the privacy policy and terms for information about using the website and its local tools.

The lasting standard is straightforward: make the answer useful, make the source visible, and keep uncertainty honest. Applying these editorial standards gives the wiki room to grow with the subject while protecting the trust of readers who arrive with a specific question and limited time.