Version history answers when a guide’s evidence was true, while a patch note answers what changed. Sephiria has an Early Access history and a public 1.0 release listed by Steam on 31 July 2026. Treat an Early Access guide as historical context unless its exact mechanic, item pool, progression gate, or achievement condition is checked again in the current base game.
Use release milestones correctly
A public release boundary does not prove that every mechanic changed, and an old guide is not useless simply because it predates 1.0. A control explanation or decision framework may remain valid, while an exact balance number or unlock route may not. Keep stable concepts and version-sensitive details in separate paragraphs.
The Updates hub can link the official source, while this page explains how to label the evidence. When a source is silent about a particular system, do not infer a change from the date alone.
Compare a historical claim
Copy the old claim, its publication or update date, and its source. Then reproduce the smallest relevant test in the current public build. For a weapon, fix target and range. For an inventory layout, preserve the shape. For a boss, compare the telegraph. For progression, capture the visible gate. For an achievement, compare official wording and client result.
If the result differs, state both eras and remove a present-tense universal recommendation. If the result matches, say it was retested rather than erasing the historical context. This gives returning players a reason to trust the change log.
Branch, platform, and product
Record Windows or macOS when a behavior may be platform-specific; Steam lists Linux as unsupported for the base product in the current metadata. Record solo or co-op mode for systems whose space or timing can change. Exclude the separate demo and any test branch unless the page is explicitly historical and out of the current site scope.
Keep the handoff actionable
When a version boundary affects a page, link it to Weapons, Artifacts, Tablets, Builds, Chapters, Bosses, Multiplayer, or Achievements. The next editor should know what to retest and what evidence to preserve. Link official changes to Patch Notes and keep community leads labeled.
Label guide eras in place
Put the era in the version scope and in the prose near any exact claim. “Early Access guide” and “1.0 launch observation” should not be hidden in a footer. If a page combines a stable decision framework with an old number, keep the framework in present tense and mark the number historical until it is reproduced.
A future-proof comparison
For a historical route, preserve the old source, its date, and the current retest. State whether the route still works, works with a changed condition, or is unresolved. This is useful to players returning after a break and to editors investigating why a community report disagrees with the current menu.
If a later patch supersedes public 1.0, add the new public version as a separate observation instead of overwriting the launch record. Link the detailed change to Patch Notes, then send affected mechanics to their system pages.
The history is most useful when it preserves both the old claim and the reason a reader should trust, retest, or ignore it today.
Readers can then decide whether to follow a current route or treat an old report as background only.
Editors can make the same decision without reopening every historical discussion.
That is the purpose of preserving the version boundary.
It keeps current advice separate from useful historical context.