How we evaluate game evidence.

What counts as a primary source?

The project called AnyPS5 is an experimental system for relinking console executable code for host operating systems. Our database is built from identifiable reports on the original GitHub project. Each game-detail page links directly to the issue, pull request, discussion or historical official table that supports its statements. We read the source for the game identifier, operating system, program stage, build identity and concrete result. The GitHub publication time is not evidence that the game was tested on that same day.

The primary source matters because the word “works” can mean very different things to different reporters. A developer might write that imports resolve successfully; a tester might mean the title screen renders; another person may have entered a playable level on a heavily patched branch. Converting those into a single success percentage would erase the distinction that readers most need to understand. Our role is to preserve what was observed, and where it was observed, rather than count a feature merge as another compatible game.

How Playable, Testing and Issues are assigned

Playable is reserved for an explicit designation in the upstream project's published compatibility table for the relevant platform. The historical table, now preserved at an immutable GitHub revision, records Dreaming Sarah as playable on Windows with named historical machine configurations. The live upstream main branch removed that Markdown file in October 2026. The designation applies to the dated configurations in that archived table.

Testing means a clearly described milestone was reached by a community tester without a concrete blocking defect in that particular record. A successful launch, menu or short gameplay capture may warrant a Testing record when the tester and environment are identifiable. It does not mean the whole title can be completed or that the public release behaves identically. Issues means the tested configuration has a documented blocker, such as a conversion failure, missing import, crash, rendering corruption or a game that cannot progress past a transition. A report can contain impressive partial gameplay and still belong in Issues because the blocking behavior materially affects actual use.

These three labels describe the scope of particular evidence. We do not create a fourth “official playable” label from GitHub activity. The upstream may merge a graphics PR without anyone running the affected commercial title again. An issue being marked closed can mean only that a narrow reproducer was fixed or superseded; it does not automatically alter a site's game compatibility status.

Why builds, operating systems and GPUs matter

AnyPS5 has evolving host implementations for libraries, graphics, memory operations and system behavior. A Windows result cannot be transplanted onto Linux, and a Linux result may depend on a particular Vulkan driver. Records include the documented branch or commit, applied patches, hardware and highest stage observed. A modern desktop build and a tagged binary package are not interchangeable sources of evidence.

A particularly important distinction is a contributor fork versus an upstream unmodified main run. A fork can combine multiple pull requests, private patches, environment variables or local assets. Its success is useful to track the direction of development, but users downloading the stable tagged release cannot assume it contains those fixes. An experimental flag that helps one title may introduce a different problem on another GPU. We link these observations as scoped reports rather than promote the flag as a universal solution.

What the dates and identifiers mean

For a game record, test date refers to an actual reported run when the original author supplies that date. Report date refers to when an issue or discussion was posted. Reviewed date refers to when our editor checked the source and recorded the interpretation. These dates are not interchangeable. A source updated this morning might merely contain an additional log, moderation action or new test on a different machine. The page's most recent review date does not prove a new executable was tested that day.

A PPSA identifier is significant because similar product names, regional releases, remasters and demo editions may be distinct applications. We do not merge test results with different IDs just because their display titles resemble one another. We keep reported spelling and explain identity uncertainty when it changes the interpretation of a compatibility claim. A release version and game content version, where supplied, are separate from the source-code commit used to build the runtime.

Three examples of evidence interpretation

Dreaming Sarah: a historical official baseline

The official archived compatibility document records Dreaming Sarah on Windows as Playable. The two hardware-specific FPS observations belong to the original testers and that historical baseline. Later Linux crashes and candidate Nvidia fixes remain separate reports. They do not silently replace the Windows official record, nor do they establish that a present-day Windows download guarantees the old measurements.

Ghost of Yōtei: an A/B experiment with a remaining cause question

The October 20 upstream investigation compares a contributor fork where the player spawns in a T-pose under the map with runs using APS5_NO_RESIDENT_LINEAR=1 that spawn normally. A separate renderer test on unmodified main demonstrates overwriting of CPU-modified pixel data. The author explicitly has not established whether that rendering hazard causes the game-level defect. Our Ghost of Yōtei record lists the fork-level spawn comparison and main-branch rendering reproducer separately.

Astro Bot: one blocker fixed does not remove the next

Some Astro Bot contributors reached gameplay on integration branches, while other unmodified-main tests encountered missing sound configuration or GPU driver failures. An open ASOBI_ROOT environment PR addressed one path-resolution scenario, but the author had not rerun the actual title on that candidate build when reviewed.

How an entry is created and maintained

Before publishing a new game page, we check that a source identifies a genuine title-level run and offers a useful outcome. We prefer the original issue or discussion over second-hand social media recaps, clickbait screenshots or automatically generated claims. Our update routines collect candidate references, but automated GitHub watchers are review queues; they do not assign Playable, invent measurements or generate authoritative test conclusions. Where an existing page already explains the same failure, we generally update that page.

Editorial review also checks whether later comments supersede the initial result. For example, a report titled “black screen” might later identify missing fonts, a failed Vulkan feature or the wrong runtime library. The corrected explanation should be closer to the actual source than the old symptom-based headline. We preserve useful earlier milestones so a fork test or newer failure does not erase the history of what was observed on a different configuration.

What users can verify and how to request a correction

For each title, compare the source-linked test record with your intended operating system, game ID, graphics device, driver, exact branch and point reached in the software. Prefer a reproducible log and a timestamped source discussion over a compatibility percentage or a promotional claim. Use the documented build, platform and observed stage when comparing reports.

If our summary changes the meaning of a test or a source link breaks, send the specific page URL and evidence to [email protected] through the Contact page. We can correct the affected record and its source context without redesigning a stable search URL.