AxiomDownload
Roadmap

From the first commit to 1.0.

The technical road from Axiom's first commit to 1.0, area by area, in the order the pieces depend on each other. Status reflects what is built today, not what is hoped for, and there are no dates.

Done
10 of 20
In progress
2 of 20
Planned
8 of 20
  1. Interface
  2. Runtime
  3. Sandbox
  4. SDK
  5. Overlay
  6. CLI
  7. Launcher
  8. Registry
  9. Server
  10. Game support
  11. Profiles
  12. Installs
  13. Unity
  14. Unreal
  15. Conformance
  16. Authoring
  17. Ecosystem
  18. Platforms
  19. Release
  20. Engines

What no phase will ever do

These are hard constraints, not tradeoffs. Nothing below crosses one, and a phase that would have to is not on this roadmap.

  • Never attach to a game with active anticheat protection. No override, no developer mode.
  • No aim, recoil, trigger or wallhack features.
  • Never write to a game's own files.
  • No obfuscation and no detection evasion.
Read the policy
Stage 1

Foundations

The pieces everything else stands on: one definition of the mod surface, a runtime that enforces it, and the tools people touch first.

  1. Interface

    One definition of the mod surface

    Done

    A single interface definition generates every language binding and the reference docs, so they cannot drift apart.

    • Sandboxed mods never receive raw addresses or pointers.
    • Capabilities that need explicit permission are marked at the source.
  2. Runtime

    The core runtime

    Done

    Loading, lifecycle, scheduling and permissions, with no knowledge of any specific game.

    • Limits are enforced by the runtime, never left to the mod.
    • A capability a game cannot offer is declared unsupported up front, not discovered as an error.
  3. Sandbox

    Sandboxed mods run

    Done

    WebAssembly mods run with only the capabilities they declared, inside a budget the runtime enforces.

    • A mod that asks for something it did not declare does not load.
    • A runaway mod is stopped without taking the game down with it.
  4. SDK

    A first mod, end to end

    Done

    A compiled mod built against the generated bindings runs every frame and shows its own settings panel.

    • Proven against a stand-in game before any real one, so the mod side was settled first.
  5. Overlay

    The in-game overlay

    Done

    Axiom's own UI, where mods draw their panels inside limits the host sets.

    • Mod-drawn UI is kept apart from Axiom's permission prompts, so a mod cannot fake one.
    • Input is handed back cleanly when the overlay closes.

    Built on macOS. Drawing inside a running game comes with the engine backends.

  6. CLI

    The axiom command line

    Done

    Managing mods, games and signing keys, checking a mod before it ships, and publishing it.

    • Commands that wait on later phases say so plainly rather than failing silently.
  7. Launcher

    The launcher, first on macOS

    Done

    The desktop app: finds the games on this machine and browses the registry, on real data only.

    • No login. Publishing is managed from an account on this site.
  8. Registry

    The central, signed registry

    Done

    One registry, at repository.axiommods.com, with accounts on this site for publishing mods, packs and providers.

    • Packages are signed on the author's machine with a key that never leaves it.
    • The registry signs its own index, so tampering, rollback and stale data are caught.
    • There is no second registry and no self-hosted one.
Stage 2

One mod, three engines

The goal that proves the design: one unchanged mod binary runs on a headless server, a Unity game and an Unreal game.

  1. Server

    Headless backend

    Done

    The first backend: no window and no injection, driven by a server tick.

    • Attaches only to a build it recognises exactly.
    • Mods that need a screen are turned away before they run.
  2. Game support

    A pack for a first real game

    In progress

    Game knowledge ships as packs. The first one answers entities, transforms and the camera for a single-player game.

    • One pack per game session, kept separate from mods.
    • Only game builds verified as unprotected are supported.

    The pack system is built. The first real game's support is what remains.

  3. Profiles

    Settings that persist

    Planned

    Mod settings changed in the overlay are saved to a profile and there next time.

    • Stored in Axiom's own folders. A game's files are never touched.
    • Upgrades can always be rolled back without losing settings.
  4. Installs

    Installing from the registry

    Done

    The launcher installs mods it has verified itself, rather than trusting the registry's word.

    • Approval covers exactly what a mod can do. An update that asks for more asks again.
  5. Unity

    Unity backend

    Planned

    The second engine: Unity games, with the overlay drawing in the game itself.

    • The same mod binary as the headless server, unchanged.
  6. Unreal

    Unreal and native backend

    Planned

    The third engine, and the one where protection detection matters most, which is why it comes last.

    • Attaches only to game, build and launch-mode combinations verified as unprotected.
    • Anything uncertain is treated as unsupported. There is no override.
    • Switching a session from offline to multiplayer is refused.
  7. Conformance

    Proving it across all three

    Planned

    A conformance run showing which behaviour holds on every engine, published as it is, even where the common ground is thinner than hoped.

Stage 3

A finished product

From a proven design to something anyone can download, trust, write mods for and keep up to date.

  1. Authoring

    Writing mods

    Planned

    From a new project to a published mod with only the docs, in every supported language.

    • Project templates, and live reload while you work.
    • More languages and a wider capability set.
  2. Ecosystem

    Publishing, discovery and updates

    In progress

    Publish from the CLI or this site, find mods and packs for the games you own, and stay up to date safely.

    • Updates follow the same rules as installs.
    • Mods declare the packs they need and never bundle one.
    • Tools for building, testing and publishing packs.

    Publishing, browsing, installing and updating mods are built. Tools for packs come next.

  3. Platforms

    The launcher on every desktop

    Planned

    Windows, macOS and Linux, launching into a modded game from a button.

    • No terminal needed from install to playing.
  4. Release

    Release and auto-update

    Planned

    Signed installers for each platform, and an updater for Axiom itself.

    • Updates to Axiom are verified the same way the registry is.
  5. Engines

    More engines and more games

    Planned

    More runtime families and more packs, each game added through the same pack path anyone can use.

    • Java games and dedicated servers, and emulated titles in single-player.
    • Games with active protection are refused by name and stay refused.
The finish line

What 1.0 means

Axiom is 1.0 when all five of these hold at once, with the hard constraints intact through every one of them.

  1. 1
    One binary, three engines

    The same mod runs on a headless server, a Unity game and an Unreal game.

  2. 2
    Trustworthy installs

    Everything installed is signed and verified, and approval covers exactly what a mod can do.

  3. 3
    Anyone can write a mod

    From an empty folder to a published mod with only the docs.

  4. 4
    A real desktop app

    On Windows, macOS and Linux, with no terminal required.

  5. 5
    It ships and stays current

    Signed installers and verified updates for Axiom itself.

A phase changes status here when the work behind it is merged.Releases