MODIFIED CLASSIC GAMES · REQUIREMENT-FIRST BUYING GUIDE · 2026
A familiar original is the starting reference, not the final compatibility answer.
Before buying a handheld for a ROM hack, identify the exact base release, modification version and resulting game, then verify the intended play and progress on the actual device software. A demonstration of the unmodified original does not establish the modified result. Neither a large preloaded library nor a platform label confirms your wanted build.
R36S is a compact candidate when the exact suitable classic build, controls and ownership plan fit. Its checked USD base options are $79.99 for 64GB and $89.99 for 128GB. Compare R36MAX for a wanted larger physical view, at $99.99 for 64GB or $109.99 for 128GB.
Choose the experience first and the hardware second. If a particular modification is purchase-defining and its required workflow is unconfirmed, resolve that condition before ordering. This guide does not certify a named project or provide unauthorized game downloads.
The 30-second modified-game buying verdict
Buy for the exact build and task, not the familiar base title. A modified release can be a worthwhile reason to want a dedicated handheld, provided the relevant conditions are established.
| Your goal | What to establish | Buying direction |
|---|---|---|
| A new campaign or revised stages in a familiar classic. | Exact modification version, applicable base and intended gameplay. | Review R36S if that suitable build and compact play fit. |
| A translated story or changed information screens. | Actual text coverage, build identity and game behavior. | Compare viewing only after the readable content is established. |
| A larger physical view of the modified interface. | The real interface and chosen presentation. | Compare MAX for screen preference, not universal patch support. |
| Continue existing progress. | Source build, progress type and supported destination route. | Protect the current campaign; do not assume version portability. |
| A ready-made supplied modified game. | Selected content and preparation explicitly confirmed. | A library count or capacity does not answer it. |
| A modification with unconfirmed special requirements. | Project instructions and relevant device/software evidence. | Resolve the requirement or compare a documented alternative. |
The conclusion can be a suitable personal handheld, a separate preparation plan or keeping the current working setup. No model is a universal ROM-hack guarantee.
1. What do you want the modification to change?
You may want unfamiliar stages, another campaign, a different balance or a story you can read. These are different interests even when they begin with the same original game.
Describe the experience that would make the purchase worthwhile. Is it new content, a preferred challenge, a revised interface or one specific feature? Keep optional changes separate from essential requirements.
A modification does not need to be called better than the original to be worth exploring. It can simply offer the experience you want. Its actual scope and behavior still need identification.
Do not turn interest in one community project into a requirement for thousands of files. A focused suitable build can be a more meaningful buying target than an unexamined collection.
2. Separate the base game, patch and resulting release
These objects have related but different roles. Treating them as one interchangeable game name makes both buying and later support questions imprecise.
| Object | What it identifies | What it does not establish |
|---|---|---|
| Original platform release. | The edition used as the starting reference. | Every revision is suitable for a particular patch. |
| Applicable base file. | The exact input required by the project instructions. | Permission to obtain it from any source. |
| Patch or modification. | The documented change and its version. | A complete ready-to-play game in every distribution format. |
| Resulting modified game. | The specific output or prepared release to be assessed. | Complete behavior from a successful patching message. |
| Device software. | The firmware, emulator or core and relevant settings. | Identical results on every handheld with a shared chipset. |
| Progress data. | The actual normal save, state or other identified record. | Automatic portability between builds. |
Some projects distribute or prepare changes differently. Follow the actual documentation rather than assuming every item uses the same patch format or installation method.
These distinctions do not certify any particular file. They tell you what must be identified before a compatibility claim becomes useful.
3. The applicable base is more precise than a title
A patch can target a particular platform, region, revision or file representation. A similarly named release may not be the input the instructions require.
Record the documented base requirements without guessing from a renamed file. If the project publishes an identification value or checksum, use its stated method and scope rather than assuming any matching name is enough.
Do not alter headers, extensions or file contents at random to force a match. A preparation instruction should come from the relevant documentation and apply to the actual lawful files.
A base that is unclear is a condition to resolve. Buying a larger card or another color does not identify it, and a device change does not correct an unsuitable input.
4. Version identity belongs in the purchase question
A project name alone may describe several revisions. A video, compatibility comment or supplied library entry can refer to a different version from the one you intend to play.
Write down the modification name, version and relevant optional choices. Where the documentation describes prerequisites or additional components, keep those attached to the record.
An older working result is useful within its scope, not a promise about every newer build. Equally, a newer number is not automatic evidence of improved suitability on your chosen setup.
A useful recommendation therefore says which result it concerns. Avoid claims that every version works when the available evidence identifies only one.
5. Use a five-link compatibility chain
| Link | Question | Common shortcut to avoid |
|---|---|---|
| Applicable base. | Does the documented input match the actual file? | The title is similar, so it must be correct. |
| Preparation. | Was the relevant method used for this version? | Every patch uses one universal procedure. |
| Result identity. | Is this the exact resulting build wanted? | The launcher label proves everything. |
| Actual execution. | Does the identified emulator/configuration perform the important tasks? | The unmodified original works. |
| Continuing play. | Do the required progress and later-use routines fit? | The title screen loaded once. |
A gap in one link should not be hidden by a confident statement about another. A preparation success is not a complete-game test, and a functioning original is not the modified result.
This is a decision framework, not an instruction to patch files blindly. Use appropriate documentation, lawful content and a supported preparation route.
6. Start with the platform, but do not stop there
R36S's description focuses on NES, SNES, GBA and PS1-oriented classic gaming. MAX describes classic interests including GBA, SNES and PS1. Those references help create a shortlist.
They do not establish the behavior of every modification built from those systems. Relevant software, changed requirements and the exact result still matter.
If a project documents a particular emulator feature or constraint, inspect that requirement directly. Do not assume a shared platform label supplies it automatically.
N64 and PSP results are variable, Dreamcast is limited and neither linked model is a PS2 buying solution. A franchise's classic roots do not make every later installment or modification a suitable target.
7. The actual software matters more than a generic model claim
Identify the firmware, emulator or core and relevant configuration used for the proposed modified build. A model name is not a complete software record.
Both descriptions identify a Linux-based retro gaming OS with ArkOS community firmware. ArkOS is within the Linux-based environment, not a second operating system alongside Linux.
Exact firmware can vary by batch and can be updated or re-flashed. Menus, mappings, emulator choices and progress routines may differ. Follow instructions for the actual setup.
This guide does not recommend a universal core or guarantee a fixed firmware release. If the required configuration is missing, clarify whether an appropriate supported route exists before relying on the purchase.
8. A game modification is not a firmware upgrade
Changing a game file and replacing device firmware are different jobs. Do not assume one requires the other or that both use the same backup and recovery procedure.
A game patch should follow its own applicable instructions. A firmware change needs device compatibility, a clear purpose and appropriate data protection.
Do not re-flash a working system simply because an unidentified modified game behaves unexpectedly. First establish the base, result and relevant emulator context.
A purposeful software remedy may be appropriate when documented. That is different from treating every issue as a reason to replace the entire setup.
9. Decide who will prepare the lawful result
Ordinary play and preparation can be separate responsibilities. You may want to manage the work yourself, ask a trusted helper or use a specifically confirmed prepared arrangement.
Identify the applicable tools and instructions. A phone, charging cable or storage adapter is not a universal substitute for every preparation or preservation task.
| Ownership preference | What needs agreement | Purchase condition |
|---|---|---|
| I will prepare it myself. | Lawful inputs, documentation, appropriate tools and separate copies. | A supported route for the exact project. |
| A helper will prepare it. | Named tasks, version record and realistic availability. | The helper actually accepts the job. |
| I expect it supplied. | Actual selected contents and configuration. | Explicit confirmation, not an assumed library entry. |
| I want no file work. | A suitable confirmed starting experience. | Resolve preparation before choosing the hardware. |
| I already have a working result. | Actual source build and intended new role. | Evaluate destination behavior separately. |
The computer-access guide addresses tools. The play-not-tinker guide addresses task tolerance. Neither promises that every modified release arrives prepared.
10. Patch availability and game rights are separate
Use only game files, software and modifications you are legally entitled to use. A project being publicly discussed does not certify permission for every way of obtaining or distributing its content.
A patch download is not automatically a license for a complete commercial game. Owning a copy does not automatically establish that any download, redistribution or modification method is permitted.
Consult the relevant terms and applicable rules for the actual material. Project credits, technical compatibility and a store listing are different from a rights determination.
No unauthorized sources or complete copyrighted game files are supplied here. This guide does not certify any named project's legal status or treat a technically working result as a permission record.
11. Check the feature that makes the modified build worthwhile
If the main attraction is another campaign, revised stages or a changed challenge, identify that feature explicitly. A new title screen is not proof that the intended content is present or behaves as expected.
Ask for relevant documentation and observations. A demonstration near the beginning can establish that portion, while later areas or features remain unshown.
Do not call a project complete, polished or equivalent to an official release from a short sample. Scope, quality and personal preference are different judgments.
The buying question is whether the exact feature you care about has a suitable supported path. It is not whether every possible modified classic should be recommended.
12. For a translation, verify useful text rather than the label
A translation is one kind of modification, not the whole category. If readable story or menus are the goal, confirm coverage for the parts you actually need.
Dialogue, objectives, item information and menus can be separate requirements. A familiar English logo or launcher entry does not establish all of them.
Confirm the actual translated build and relevant screens before choosing display size. A larger panel does not translate missing content or correct an unsuitable base.
The language-and-edition guide handles the readable-content question. Here the primary task remains identifying and assessing the complete modified result.
13. Changed content can still need its own control check
Identify the actions required in your intended build. Some modifications change mainly content; others can affect features, menus or input expectations. Do not assume every project does either.
Check the actual mapping and important actions with the relevant instructions. The original release's button arrangement is a starting reference, not an observed result for the modification.
A visible stick or shoulder control does not establish a particular assigned function, macro, turbo mode or input precision. Assess the specific task.
If a special action is essential, include it in the purchase question and relevant demonstration instead of assuming that an unrelated base-game video answers it.
14. Choose the physical view after the build is established
R36S lists a 3.5-inch IPS display at 640×480. MAX lists a 4-inch IPS display at the same resolution. The larger panel is a physical-view choice, not additional pixels.
Use the actual interface to assess the preferred presentation. If a modification changes text, layout or scene information, ask about that result rather than relying on the original's screenshots.
Choose MAX when the larger view is wanted. Do not convert that preference into a claim of stronger emulation, better translation or wider patch support.
Neither device is universally comfortable or readable. Physical preferences can support a purchase without being dressed as a measured result.
15. Current description facts and their boundaries
| Reference | R36S | R36MAX | Meaning for a modified game |
|---|---|---|---|
| Display. | 3.5-inch IPS, 640×480. | 4-inch IPS, 640×480. | Physical viewing, not patch compatibility. |
| Chipset. | Listed RK3326. | Listed RK3326. | No processor advantage established by panel size. |
| Memory. | Listed 1GB DDR3L. | Listed 1GB DDR3L. | Not a test of the wanted build. |
| System. | Linux-based OS with ArkOS community firmware. | Linux-based OS with ArkOS community firmware. | Identify the actual firmware and emulator. |
| Capacities. | 64GB or 128GB. | 64GB or 128GB. | Space, not a universal patching service. |
| Connections. | USB-C, 3.5mm audio and MicroSD listed. | USB-C, 3.5mm audio and MicroSD listed. | Confirm the actual tool or accessory function separately. |
| Wireless expectation. | Built-in Wi-Fi and Bluetooth not confirmed. | Wi-Fi and Bluetooth not listed as included. | Do not assume online distribution, automatic updates or linking. |
| Prepared modified library. | No specific project certified here. | No specific project certified here. | Selected-content confirmation is a separate task. |
These facts support a candidate comparison. They do not prove a patch application, successful modified campaign or save transfer.
The product titles still contain library-count language, and MAX's description contains listed counts and review references. Those are not an audit of modified content or evidence of a project's actual behavior. They are not used as compatibility authority here.
16. Current USD base options and complete listed configurations
The full variant connections were reread October 4, 2026: fourteen R36S variants and ten MAX variants with no unread pages. These USD references do not promise current stock, particular files or a destination-specific checkout total.
| Configuration | USD base price | Useful reason to consider | What it does not establish |
|---|---|---|---|
| R36S 64GB. | $79.99 | Lower-priced compact option when actual space and build fit. | The wanted modification is supplied. |
| R36S 128GB. | $89.99 | Additional nominal room in the same format. | Faster modified gameplay or better compatibility. |
| R36MAX 64GB. | $99.99 | A wanted larger physical view. | A stronger patching or translation engine. |
| R36MAX 128GB. | $109.99 | Larger viewing and useful additional room. | Automatic preservation or conversion of progress. |
R36S lists Purple, Black, White, Red, Yellow, Green and Blue across both capacities. MAX lists Black, White, Blue, Gray and Red. Finish is personal preference, not a project or software tier.
Select the actual color and capacity in the purchase form. Confirm current applicable pricing, package and charges. Comparison tables explain choices; they do not select the order option.
17. Capacity solves a space need, not an identity problem
A lawful content plan can require useful storage room. Decide what you intend to keep rather than assuming a larger card contains a particular modified release.
More capacity does not resolve an unsuitable base, undocumented patch version or missing emulator requirement. Those are compatibility and preparation questions.
Nominal capacity also does not identify card brand, quality, health or the maximum supported expansion. Backups need an appropriate separate preservation route, not just another slot on active storage.
The preloaded-library guide separates supplied entries from behavior and rights. A large count should never stand in for confirmation of the exact modified build.
18. New progress needs a supported persistence routine
If you are starting the modified game from the beginning, identify its supported saving behavior and the actual emulator routine. A visible save command alone is not a successful later load.
Use disposable progress to check the ordinary path before investing in a valuable campaign. Exit and reopen with the appropriate instructions, then identify the intended checkpoint.
Normal game saves, emulator states and independent backups are different. A state is not automatically portable across emulator versions or modified releases.
No permanent access or impossible-to-lose progress is promised here. A supported routine and preserved context are more useful than an absolute slogan.
19. Existing progress belongs to the exact source build
A campaign from the unmodified original, another region or an earlier modification version is a separate compatibility question. A shared title does not prove that the result accepts its data.
Identify the source release, software and progress type. Preserve the working source and appropriate separate copies before trying a supported candidate route.
Do not overwrite the only working campaign, rename an extension as if that converted the contents or swap a whole card on an assumption. A successful import message is not proof of meaningful continuation.
The existing-save migration guide addresses continuity. If that continuity is essential, establish it before recommending the new purchase.
20. A modification update can change the task you must assess
When a project releases another version, read the actual instructions and change information. Identify whether an update is relevant to your goal and whether progress or preparation requirements are specified.
Do not assume every newer build improves your setup or that every update breaks it. The version-specific facts decide the question.
Keep the working baseline and useful data separate from experiments. Record the version and configuration that produced a known useful result before changing anything.
Change for a named purpose, then validate relevant play and persistence again. This guide does not supply a universal update procedure or guarantee that saves survive every revision.
21. Choose a daily role, not an endless preparation project
A dedicated handheld can be attractive for a focused campaign away from your phone. You may want to enjoy one suitable modified adventure rather than continually prepare new builds.
That preference is valid. Agree on the starting version, ordinary play routine and who handles non-routine work. Optional experimentation can remain optional.
If you already have a working campaign elsewhere, keeping it there while starting another suitable game on the handheld can be a deliberate role, not a failed migration.
Do not promise a fixed session length, battery runtime or instant resume. The actual game, firmware, settings and routine determine practical use.
22. For a gift, make the prepared experience explicit
A recipient may love the idea of another story or a revised challenge without wanting file preparation as a hobby. Confirm that preference before making the modification the gift's main attraction.
State the exact build and what remains to be done. Agree who handles initial preparation, basic instruction and occasional maintenance. A giver's technical confidence is not a permanent support plan.
Check the actual content and suitability for the person receiving it. A modified classic may differ from the original experience; nostalgia and colorful presentation do not establish age suitability.
Do not promise a prepared project, guaranteed arrival deadline or unlimited support without applicable confirmation. The practical handover should be clear before buying.
23. Confirm package contents and tools separately
Match the selected model, color and capacity to the order, then confirm essential accessories. A wall adapter, case, reader or other tool is not automatically included because it appears in a scene.
USB-C is a listed connector, not a universal file-management or power guarantee. Follow actual charging instructions and verify the relevant data or accessory function.
If preparation relies on a computer or helper, confirm the complete route and availability. Do not buy a speculative accessory to solve an unidentified requirement.
Hardware, content, preparation and tools are separate parts of the plan. Confirm the ones that are essential instead of treating the base price as every prerequisite.
24. Request evidence at the level of the intended task
A useful result identifies the exact modified build and actual software. It distinguishes documentation from observed behavior and explains what remains unshown.
| Claim you need | Relevant evidence | Limit to retain |
|---|---|---|
| The intended build is present. | Version identity and selected-content confirmation. | A familiar label is not the full identity. |
| The changed feature is accessible. | Relevant modified content or action. | Not every later feature or complete campaign. |
| The controls fit. | The important input in the actual setup. | Not measured latency or every mapping. |
| The text meets the reading need. | Relevant dialogue, menus or instructions. | Not complete translation quality from one sample. |
| New progress persists. | Supported save, exit and relevant later load. | Not universal state portability or automatic backup. |
| Existing progress can continue. | Identified source, supported destination and meaningful continuation. | Not every edition or version. |
The gameplay-evidence guide helps interpret a recording. A displayed counter or successful startup is only part of the information.
No named modification was physically tested for this article. No FPS, latency, completion percentage or full-library compatibility score is used to create authority.
25. A copyable exact-build buying question
I am considering this model and selected configuration for this modification name and version, based on this documented original release. My essential features are these changed stages, story elements, controls or other tasks. I plan to start fresh or continue this identified source progress. Please distinguish what is actually supplied, what preparation is required, which firmware and emulator were used, and which relevant actions or save behavior were demonstrated. Which conditions remain unconfirmed?
If you require a helper or cannot perform file work, add that boundary. If another compatible edition is acceptable, state it rather than letting a familiar title conceal the substitution.
A precise answer can support the compact option, the larger physical view or another documented route. It should not rely on a promise that every hack works.
26. Seven steps to choose a handheld for a modified classic
Identify the intended result, preparation, actual software and progress requirements before selecting a retro handheld configuration.
- Define the wanted change. Name the campaign, stages, balance, text or feature that makes the modified build worthwhile. Separate essential requirements from optional discoveries.
- Identify base and modification version. Record the applicable original platform release, documented input requirements and exact project version. A renamed filename is not an identity check.
- Establish a lawful preparation plan. Use content and software you are entitled to use, appropriate instructions and tools, and a confirmed responsible person. Patch availability does not certify every acquisition method.
- Check the result on the actual software. Identify firmware and emulator context and relevant gameplay. Do not substitute a demonstration of the unmodified original for evidence of the result.
- Separate new saves from existing progress. Check a supported new-progress routine or a source-specific continuation route. Preserve valuable source data and keep states distinct from normal saves and independent backups.
- Choose physical format and useful capacity. Review R36S for suitable compact classic play or MAX for a wanted larger view. Select room for the actual content plan and confirm the complete order and preparation conditions.
- Validate low-stakes use before relying on a campaign. Follow actual instructions, check version, required actions and supported saving and reopening. Record a useful baseline before meaningful changes.
These are buying and validation steps, not a universal patch-application recipe. The documentation and actual configuration determine the technical method.
27. Keep a small build record with the campaign
| Record | What to identify | Why it matters |
|---|---|---|
| Base. | Applicable release and documented identifier where provided. | Prevents another edition from being assumed equivalent. |
| Modification. | Project version and meaningful optional choices. | Keeps evidence attached to the intended result. |
| Software. | Actual firmware, emulator or core and relevant settings. | Supports a precise repeatability or support question. |
| Progress. | Normal save or state, source build and known checkpoint. | Prevents an unidentified candidate from replacing a working campaign. |
| Evidence. | Observed tasks, documentation and remaining limitations. | Keeps a partial result from becoming a universal claim. |
| Preservation. | Appropriate separate copies and a responsible person. | Protects useful context before experiments. |
A record is not a score or a promise of recovery. It makes future questions answerable without reconstructing the entire setup from a vague title.
Do not send complete copyrighted game files or private credentials to prove a support question. Describe the version, relevant instructions and observed behavior through an appropriate support route.
28. On arrival, validate the device before a valuable import
Match the unit and selected option to your order, read the applicable instructions and identify the actual software. Confirm essential contents and preparation instead of assuming they match a scene.
When the supported plan is ready, check the intended modified result and important actions with low-stakes progress. Test the relevant save and later load before relying on it.
For existing campaigns, keep the working source separate and follow only the established candidate route. Confirm meaningful continuation before retiring the source or making it unavailable.
If something differs, record the base, modification version, software and specific task. Do not reformat storage, overwrite the only useful data or change several unrelated settings to force a match.
The honest fit boundary
A suitable handheld direction
You have an identified suitable classic build, lawful access, a supported preparation and progress plan, and wanted physical controls and viewing.
Review R36S for compact value. Compare MAX when the larger physical view is relevant. Choose capacity for room rather than a promise of universal modification support.
A condition to resolve first
The base or version is unclear, the essential feature is unverified, preparation is unwanted and unarranged, or existing progress lacks a supported route.
Clarify the task or choose another documented fit. A bigger library, higher price or a similar original-game demonstration does not resolve it.
If the original already offers the experience you want, a modification is optional. If the modification is essential, its actual requirements belong at the center of the recommendation.
ROM hack handheld buyer FAQ
How should I choose a handheld for a ROM hack?
Identify the applicable base release, exact modification version and resulting game. Establish lawful preparation, actual device software, essential play and progress requirements before choosing physical format and capacity. A model name alone is not an exact-build answer.
Does the original game running prove the modification works?
No. Evidence for the unmodified original does not establish the modified result. Check relevant behavior on the identified emulator and configuration, and keep unshown content or later play unconfirmed.
Is a familiar base-game filename enough?
No. Follow the project's applicable release, revision and input requirements. Where it provides an identification value, use the documented method. Renaming a file does not prove its contents match.
Does a successful patching message prove complete playability?
No. Preparation, result identity, startup, meaningful play and persistence are separate checks. A short successful task should not be presented as verification of the entire campaign.
Are particular hacks guaranteed to be preloaded?
No specific modified project is certified as supplied here. Confirm the exact selected contents and version independently. Capacity, a library count or an illustrated screen does not establish inclusion.
Does a translation patch make every screen readable?
Do not assume full coverage from a label or short sample. Check dialogue, menus, instructions and the relevant project version. A larger screen changes physical viewing, not the text contained in the modified release.
Will my existing save work in another modified version?
No automatic portability is established. Identify source build, software and progress type, preserve the working source and confirm a supported candidate route. Normal saves, states and backups are different.
Is R36MAX more compatible with ROM hacks than R36S?
No comparative modification-compatibility result is supplied. Both descriptions list RK3326 and 640×480 displays. MAX has a larger 4-inch physical panel versus R36S's 3.5 inches; that is not a universal patch-support advantage.
Does 128GB make modified games run faster?
No performance benefit follows from nominal capacity alone. More room does not resolve base identity, software requirements, missing content or save conversion. Choose capacity for the actual lawful space plan.
Does owning the original permit every download or modification method?
Do not assume that. Rights, relevant terms and applicable rules need separate consideration. Patch availability and technical success are not universal permission records. Use only content and software you are entitled to use; this guide does not certify a particular project or source.
What current USD options were checked?
October 4, 2026 complete variant reads show R36S 64GB $79.99 and 128GB $89.99, and R36MAX 64GB $99.99 and 128GB $109.99. Confirm the selected current option, market price, package and applicable charges. These are not stock or modified-content guarantees.
Will every unit use the same firmware and preparation instructions?
No uniform setup is promised. Both descriptions identify Linux-based retro gaming systems with ArkOS community firmware. Exact firmware can vary by batch and can be updated or re-flashed, so emulator choices, mappings and routines may differ. Follow the actual configuration and project instructions.
Choose a handheld for the modified experience you actually want
Review R36S when the exact suitable classic build, controls and compact personal role fit. Compare 64GB at $79.99 and 128GB at $89.99 according to useful storage room.
Compare R36MAX when its larger physical view matters. Review 64GB at $99.99 or 128GB at $109.99 without calling the panel an automatic compatibility upgrade.
Keep the wanted build, lawful preparation and progress plan at the center. If an essential condition is unresolved, establish it before treating either recommendation as ready.
Review compact R36S configurationsCompare the larger MAX viewEvidence and editorial scope
Product descriptions and complete variant connections were reread October 4, 2026. They establish the listed hardware, capacities, colors and USD base references used here, not a test or inventory of modified games.
This article supplies an exact-build buying framework. No named patch was applied, campaign completed, progress converted or compatibility percentage measured for it. Store images are product context; no fresh visual inspection or identification of an illustrated modified game is claimed.
Project requirements, lawful access, preparation, actual software and relevant observations remain attached to each proposed build. The objective is a useful suitable purchase, not a promise that every modification runs everywhere.
