Roadmap
From Luminids to a platform other teams can use.
The next stage is to extract the reusable runtime, productise the developer workflow, integrate CRI outside Luminids and validate whether external studios need it enough to pay for it.
01 Working inside Luminids
The mechanisms that already run in a real game.
Three capabilities run in Luminids today and five more run while their broader claim is still being tested.
Implemented
3 claimsRuns in Luminids, with tests and saved character state.
-
Each character keeps a stable identity, and that identity survives saving and loading.
Implemented Test suite, character layer
-
Each character keeps a bounded, curated record of what it has lived through, and that record changes how it develops.
Implemented Test suite, character layer
-
What a character says is assembled from what it has actually lived, and it stays silent rather than claim something it cannot support.
Implemented Test suite, character layer
Being tested
5 claimsRuns in the game and is undergoing broader validation.
-
Two individuals share one bounded record of the history between them, written during ordinary play.
In production validation Test suite, relationship tests
-
Evidence is held per individual, and it gates what that individual is allowed to claim.
In production validation Test suite, character layer
-
A character that has come to believe something about itself reacts when the world contradicts it, remembers the day, and lets the belief go; a character that never formed the belief does neither.
In production validation The recorded run
-
Action, designed and tested, validating
A character would act on what it believes about someone else, then find the world has moved on and adjust rather than pretend.
In production validation CRI Engine, on the platform map
-
A character can hold an expectation, discover it was wrong, and be changed by that.
In production validation Test suite, character layer
02 Extract
Make the cognition portable out of our own game.
Separate reusable CRI systems from Luminids‑specific code and establish a portable CRI Engine boundary.
- Establish the stable runtime boundary.
- Package the CRI Engine interface.
- Separate game-specific logic from reusable cognition.
- Preserve save, load and evidence contracts across that boundary.
- Define performance qualification for external use.
- What it solves Another team can integrate the cognition instead of building it themselves.
03 Productise
Make what a character does something a team can author and test.
Turn Studio, Bench and Trace into usable tools for authoring, inspection, replay and testing.
- Studio authoring and inspection.
- Trace as the causal record.
- Bench intervention and replay.
- Repeatable regression tests for character behaviour.
- What it solves A designer can find out why a character did something, and check that a fix actually worked.
04 Integrate
Connect CRI to other teams’ games and models.
Add support for additional game environments, world adapters and model connectors.
- World adapters that connect game events, state and actions to CRI.
- Optional model connectors that let a language model express CRI state.
- CRI running in game environments beyond Luminids.
- What it solves A team can keep its own engine and model, with each character’s history held in CRI.
05 Validate
The next commercial proof is CRI being useful in someone else’s game.
We will move from customer discovery to design partnerships, external pilots and paid deployments, and then towards repeatable distribution.
Success is not Nick integrating every deployment by hand. The end state is a developer product another team can adopt and operate.
Design-partner conversations are open to studios building systemic characters.
Without Luminids-specific code underneath, another team can:
- Author Set what their characters start out knowing and believing.
- Inspect Follow one of their responses back to the evidence behind it.
- Test Change one thing, replay it, and keep the difference as a test.