How Kizaki Works
Kizaki turns one schema into a full application workflow: database shape, runtime rules, generated client surfaces, and deployment artifacts.
Kizaki is easiest to understand if you start with its center of gravity: the schema.
You define the application model in Inspire, then the rest of the system is built to preserve that model as it moves through local development, runtime enforcement, generated code, and deploys.
At a high level, the flow is:
- you define your app in Inspire
- Kizaki compiles that schema into runtime artifacts and generated TypeScript packages
- your app code adds server workflows with
/** @expose */ - the browser uses the generated client and query stack
- deploy promotes the same app shape into hosted environments
What The Platform Is Trying To Eliminate
In a typical stack, each of these concerns lives in a different system:
- database schema
- auth provider configuration
- authorization middleware
- backend endpoints
- frontend API typing
- migration tooling
- deployment configuration
Kizaki deliberately pulls those closer together. It does not remove application code, but it does try to remove the glue code that usually sits between core systems.
The Practical Consequence
When the model is coherent:
- local development matches the shape of deploys
- generated packages match the schema
- policies apply consistently across reads, writes, routes, and live queries
- schema changes move through committed migrations instead of ad hoc SQL
That is why the docs keep returning to the same theme: define the platform-level facts once, then build on top of them.
If you are learning the platform, read this page once and then move back to the Learn section.