Root Kernel > build AI agent systems

AI-SPARK and Podway

AI-SPARK validates the specs needed for server development so AI writes code against a specification approved by a person. The FSM runtime controls actual state transitions. Podway extends this approach to general tasks, defining a procedure and the conditions for advancing through each stage in advance. AI works within the permitted scope, while people make consequential decisions and give final approval.

Reviewing AI-generated code and recovering from problems

As AI produces more code, people have more to check. Reviewing whether code works as intended and approving its use still takes time and judgment.

When API contracts, permission policies, state models, and tests refer to different versions, aligning them requires rework. Recovery is also harder without a defined stage to return to and a clear scope for rechecking.

Root Kernel defines the scope of AI work and the validation and approval conditions for each stage first. Procedures also include paths for returning after a problem, making it clear where work should resume.

Specifications define the implementation boundary

AI-SPARK groups interfaces, state models, bindings, and permission policies into a spec bundle and versions them together. AI writes code against a version that has passed validation and received human approval.

Revision n Revision n+1 Interface State model Bindings Authorization policy Interface State model Bindings Authorization policy changed key A key B Implementation fail-closed
One spec bundle contains the interface, state model, bindings, and authorization policy.

The revision key derived from the spec bundle links validation results and approval records to that specification version. Implementation and deployment use the same version, so the approved content can be checked against the actual work.

Work can advance to the next stage only when revisions match and all required outputs are present. The fail-closed principle prevents progress while conditions remain unverified.

Spec revision Deterministic validation Human approval Implementation & test Deployment Revision key fail-closed Not approved
Each stage is a precondition for the next.
  1. Spec revision
  2. Deterministic validation
  3. Human approval
  4. Implementation & test
  5. Deployment

Deterministic validation and human approval

Under the same validation conditions, the AI-SPARK validator returns the same list of violations for the same spec bundle. It does not depend on model judgment, so the results can be checked by repeating validation under identical conditions.

Validated side Spec bundle Validator · managed separately Validation rules Check Same violation list Human approval Revision key Spec changed same conditions · same list
The validator returns the same result for the same input; a person approves the revision.

Validation rules are kept separate so the party being checked cannot modify them. Human approval is tied to the specification version that passed validation. If the specification changes, it must be validated and approved again.

The FSM runtime controls state transitions

After approval, AI writes code for events, transition conditions, and transition actions. The FSM runtime handles actual state transitions and concurrency, changing state according to declared rules and recording those changes.

Unauthorized events are rejected. When a problem occurs, Reverse Map traces failed requests and server logs back to the relevant operations, permission policies, and state transitions. Execution records include the specification version and identifying information for the run, preserving the context in which the problem occurred.

A core AI-SPARK invention has been filed as a Korean patent application.

Podway controls AI execution with task-specific procedures

Podway manages work procedures alongside an agent’s to-do list. It organizes work into a procedure graph, defining each stage’s conditions for progress and paths for rework in advance. When a problem requires returning to an earlier stage, the procedure governs which existing records remain valid and identifies the work and validation that need to be repeated.