One schema. Every part it compiles.

One .conjure schema declares tables, indexes, queries, commands, mutations, modules and frame systems. The compiler binds, type-checks, plans with a cost-based optimizer and emits plain C# — nothing is parsed or planned on the device.

A feature is a module of the schema: its tables, commands and queries in one place. Moving it to another game means pointing its declarations at that game's items and currencies and overriding what differs — the compiler re-derives the rest.

Battle pass, store, inventory and similar features shipped as schema modules you can read, override and extend — not as a closed SDK.

Compiled queries, commands and mutations over your game's persistent state. Declared indexes, UI views that update themselves by applying only what changed, local persistence with snapshots and a write-ahead journal.

Per-frame state for positions, projectiles and hit events: chunked struct-of-arrays storage, generational handles and declared systems scheduled per phase, at 0 B per frame. It joins live frame state to persistent tables and their indexes.

Commands are deterministic by construction: a fixed-point math library (Fixed64) instead of floats, seeded random declared in the schema, and tests that hold the device and the server to the same answer. This is what makes server replay possible.

The same compiled commands run on the server, one grain per player (Orleans). The player's state lives there as the source of truth; the device keeps a replica and a journal of what the player did. Validated in a backend prototype.

The server replays the device's command journal and compares state hashes. Forged or divergent sessions are rejected and the device is rolled back to the server's state. Commands that need the server travel with the journal and run against the verified state.

Clans, leaderboards and other state that belongs to many players, declared in the same schema and served by their own owner on the server.

Rules, offers and queries delivered after the build and executed identically on the device and on the server. Change the game without a release and without the two sides disagreeing. Validated in a prototype.

Game configuration served per version from its own grains, so old clients keep the config they shipped with while new ones get the new one. Validated in the backend prototype.

A no-JIT, allocation-lean bytecode lane for queries that arrive as content after the build. Same semantics as the compiled lane, verified by differential tests, running wherever AOT runs.

Experiment groups declared in the schema, assigned on the server and read by the same queries the game already runs.

Google Play Games and Game Center sign-in wired to the player server.

Unity IAP with regional prices; receipts verified on the server and granted by a command, like any other change.

Events declared in the schema, with part of the questions answered on the device before anything is sent.