---
title: "How It Works"
description: "The human defines the product, the AI writes the code, and Gabion provides the architectural boundary and deterministically verifies the critical rules."
canonical: "https://gabion.dev/how-it-works"
site_index: "https://gabion.dev/llms.txt"
---

> Index of this site: <https://gabion.dev/llms.txt>. Every page in one file: <https://gabion.dev/llms-full.txt>.

The Gabion Workflow

# Three participants. One architecture.

The human defines what the product has to do. The AI works with the code and the stack. Gabion provides the production pipeline and verifies that a change does not break its critical rules.

The architecture stops being a set of aspirations in documentation and becomes part of the development process itself.

[See the Workflow](https://gabion.dev/how-it-works#workflow)

[Gabion Technology](https://gabion.dev/technology)

## Plausible code does not always mean a correct decision.

A modern model can quickly produce clean code, explain it, and correct an obvious error. But an explicit requirement describes only part of the task.

Outside the request lie the implicit assumptions: the method of access control, the transaction boundaries, the permitted direction of a dependency, the data lifecycle, the specifics of a library, and the rules for integration with the rest of the system.

An experienced developer applies many of these rules automatically. The AI may not see them, may confidently select a similar but unsuitable pattern, and may produce a result that looks convincing in review.

The ordinary cycle leaves the model too many hidden decisions:

1. a human describes the required feature;
2. the AI reconstructs the architectural context on its own;
3. the AI selects the libraries and the patterns;
4. the code is verified mainly by its visible result;
5. the architectural error is detected later, or not detected at all.

The problem is not that the AI writes code. The problem is how many critical decisions it has to guess.

## Do not make one participant responsible for everything.

| Participant | Responsible for | Should not do alone |
| --- | --- | --- |
| Human | The goal, the business logic, the priority, the evaluation of the result | Remember every technical constraint of every library |
| AI | Analyzing the task, creating and changing code, correcting the discrepancies found | Reinvent the architecture and define the critical security rules |
| Gabion | The project context, the permitted tools, the architectural boundaries, the modules, and the checks | Decide what value a feature has to give the user |

### The human keeps responsibility for the product

Gabion does not determine what the user needs, and it does not turn a vague idea into correct business logic automatically. The human sets the goal, explains the exceptions, and accepts the result.

### The AI keeps room to work

Gabion does not reduce the AI to inserting pre-written code from a template. The model analyzes the task and implements the change, but does so within a known technical boundary.

### Gabion keeps the rules between requests

The architecture does not depend on whether the developer remembered to add it to a new prompt, or on whether the current model knows every decision taken a month ago.

## Gabion creates and changes a separate project. Production runs without it.

The Gabion working cycle does not begin with an endless chat against an empty repository.

First a project is created on the coherent stack. The human and the AI then change it through the tools, modules, contracts, and checks provided. Once verified, the project is built by standard means and deployed independently of Gabion.

1. ### 1. Gabion creates a separate project

   A new project is initiated by a command of the form `gabion init my-project`. Gabion creates a separate application directory.

   The following appear in it:

     - a coherent structure;
     - a Java backend;
     - the Spring configuration;
     - a TypeScript frontend;
     - Thymeleaf;
     - CSS;
     - the database configuration;
     - the initial migrations;
     - the test structure;
     - the build configuration;
     - the starting set of provided modules.

   Gabion Runtime and the internal module storage are located outside this directory.

   The Runtime creates the project, but does not become part of the project.
2. ### 2. The Starter sets the foundation

   The Starter is responsible for the initial shape of the application:

     - the directories;
     - the base dependencies;
     - the configuration;
     - the stack conventions;
     - the build commands;
     - the initial extension points.

   The Starter is not a module.

   The Starter creates the foundation. Modules add vertical capabilities.
3. ### 3. Modules form repeatable capabilities

   A Gabion module can include several layers at once:

     - Java;
     - TypeScript;
     - Thymeleaf;
     - CSS;
     - a page;
     - a data structure;
     - Flyway migrations;
     - tests;
     - checks.

   The contents of a module are declared through `gabion.manifest.json`.

   The manifest tells Gabion:

     - what the module contains;
     - which contracts it uses;
     - which integration points it provides;
     - which migrations are required;
     - which checks are mandatory;
     - whether the module is compatible with the current pipeline.
4. ### 4. Modules interact through contracts

   A module must not know the internal structure of another module.

   Permitted interaction goes through:

     - interfaces;
     - events;
     - extension points;
     - permitted services;
     - agreed data structures.

   Gabion verifies the properties of this boundary available to it.

   A direct import of an internal implementation, an arbitrary change to another module's files, or a hidden dependency has to be detected by the checks provided.
5. ### 5. The human states the change

   Once the project is created, the human describes:

     - the required behavior;
     - the user-facing result;
     - the business conditions;
     - the roles affected;
     - the data constraints;
     - the external integrations;
     - the verification criteria.

   Example:

   "A project manager can see the financial indicators only of projects in their own organization. An organization administrator sees all of that organization's projects. Access between organizations is prohibited."
6. ### 6. The AI receives limited context

   The AI does not necessarily receive the whole repository and all the project data.

   Through the permitted MCP boundary it can receive:

     - the project structure;
     - the files relevant to the task;
     - the available contracts;
     - the extension points;
     - the diagnostics;
     - the tests;
     - the permitted commands.

   The scope of access is determined by the project, the tool, and the decision of the human.

   Secrets and production data must not enter the context automatically.
7. ### 7. The AI proposes a plan

   Before making a change the AI can:

     - find the elements affected;
     - explain the existing behavior;
     - determine the layers required;
     - list the files;
     - identify the migration;
     - name the tests;
     - identify an ambiguity;
     - request a decision from the human.

   The plan produced by the AI is not proof of architectural correctness. It helps the human understand the intended diff before it appears.
8. ### 8. The AI changes the project

   The AI creates or changes files inside the permitted directory.

   For unique business logic, changes are made directly in the client project.

   For a repeatable feature, an existing contract or module is used, if the production pipeline provides one.

   The AI does not receive direct access to the internal Pikiner module storage.
9. ### 9. If a new module is required

   If an existing shared component is not sufficient for the agreed result, Pikiner separately determines whether it should become a module.

   A new module is created outside the client project as an anonymized reusable template.

   The following are not transferred into it:

     - client data;
     - secrets;
     - the name of the product;
     - unique business logic;
     - confidential rules;
     - the source code of the client's old system.

   The internal Pikiner production CLI applies the module to the project and runs the necessary checks.

   The project edition of Gabion for the client does not provide the module-management CLI or direct access to the internal storage.
10. ### 10. Gabion verifies the change

    After a change, the deterministic checks run.

    They can verify:

      - the structure;
      - the dependencies;
      - the manifest;
      - the contracts;
      - the data;
      - the migrations;
      - the configuration;
      - the mandatory tests;
      - the absence of the Runtime from the production dependencies;
      - other properties implemented for the current pipeline.

    A check evaluates a specific property of the project, not the persuasiveness of the explanation given by the AI.
11. ### 11. An error becomes feedback

    If a rule is broken, the result has to explain:

      - what was checked;
      - where the problem was found;
      - what condition was expected;
      - what was found;
      - why the change was not accepted;
      - what action is required.

    The AI can use this diagnostic output to make a correction.

    The human sees the same problem and does not have to reconstruct it from the internal dialogue of the model alone.
12. ### 12. Tests verify behavior

    An architectural check does not replace a test of the user-facing result.

    After a correction, the following run:

      - unit tests;
      - integration tests;
      - contract tests;
      - migration checks;
      - the agreed user scenarios.

    The specific set depends on the project.

    A successful structure does not prove the correctness of an unknown business rule.
13. ### 13. The human evaluates the result

    The human verifies:

      - whether the feature matches the task;
      - whether the business logic was understood correctly;
      - whether the UX is acceptable;
      - whether the data is correct;
      - whether the risks can be accepted;
      - whether the change is ready for release.

    Gabion does not take product, legal, or ethical decisions on behalf of the team.
14. ### 14. The project is built by standard means

    After the technical and product verification, the project has to build without Gabion Runtime.

    The standard cycle includes:

      - installing the application dependencies;
      - building the backend;
      - building the frontend;
      - running the tests;
      - creating a deployment artifact;
      - preparing the environment configuration.

    The Runtime, the internal storage, and the Gabion token are not part of this path.
15. ### 15. The human decides on deployment

    A successful Gabion check does not publish a change to production automatically.

    An authorized person or a client process decides separately:

      - which artifact to release;
      - to which environment;
      - when to perform the deployment;
      - whether migrations are needed;
      - whether a maintenance window is required;
      - whether a rollback is ready;
      - who monitors the result.
16. ### 16. Production runs independently

    After deployment the user interacts only with the application and its agreed external services.

    Production must not access:

      - Gabion Runtime;
      - the Gabion MCP;
      - the internal module storage;
      - the license token;
      - the Gabion browser UI;
      - the Pikiner server for executing business logic.

Gabion takes part in changing the project. The request from the user is executed by the application itself.

## From describing the correct path to controlling the permitted path.

In a traditional project an architectural decision often exists in documentation, in a code example, or in the memory of a senior developer. A new participant may not know about it, and the AI may select a different approach that also compiles and looks reasonable.

In Gabion a repeatable rule is expressed, where possible, through one or more mechanisms:

- a defined project structure;
- a limited set of extension points;
- a typed contract;
- a ready-made module;
- a tool that performs the operation in the permitted way;
- a static or dynamic check;
- a test of an architectural property;
- an explicit refusal when a boundary is broken.

### Documentation

- explains how one should proceed;
- requires the participant to find and read the rule;
- can go out of date separately from the code;
- an error depends on the attentiveness of the reviewer.

### Executable constraint

- verifies that the permitted method was followed;
- is present in the workflow;
- is versioned together with the production pipeline;
- a violation can be detected automatically.

Not every architectural decision can or should be turned into a prohibition. Gabion distinguishes verifiable boundaries from the areas where the engineering judgment of a human is required.

## One error, two different explanations.

The AI and the human consume technical information differently. A model needs a structured result tied to a specific action and to a possible correction. A human needs a clear overview: what was happening, why the change was stopped, and whether a decision is required from them.

### For the AI

Gabion has to return:

- the identifier of the rule that was broken;
- the location or the object of the violation;
- the expected property;
- the actual result;
- the available ways to correct it, or a reference to the permitted tool;
- the difference between a blocking error and a warning.

### For the human

The interface displays:

- the current task or action;
- the state of the checks;
- a short explanation of the problem;
- the impact on the project;
- the decision required from the user;
- the history of significant actions, where the operating mode provides for it.

Information for the human is displayed in the browser — in an overlay or a separate window. The workflow is not tied to the interface of a single IDE.

## The architecture of a project must not live inside a single LLM.

If the rules of the system are held only in the context of the model, they have to be supplied again in every session and verified after every change of provider.

Gabion moves the durable part of the context into the production environment. The model gets access to the same tools and checks regardless of its brand, its size, or where it runs.

This makes it possible to choose a model on the basis of:

- the complexity of the specific task;
- the confidentiality requirements;
- the acceptable latency;
- the cost of inference;
- the local compute environment;
- the acceptable number of iterations.

Gabion does not make a weak model equal to a strong one. Models differ in their ability to understand a task, build a plan, and correct errors. The environment reduces the number of decisions they have to guess, and detects certain violations before the result reaches the human.

[Models, Data, and Cost](https://gabion.dev/models-and-data)

## The boundaries of automation stay visible.

Gabion does not:

- define the product strategy;
- decide whether a user needs a feature;
- guarantee the correctness of an undescribed business rule;
- make all LLMs the same;
- make any generated code safe;
- remove the need to test behavior;
- remove human review of high-risk changes;
- take legal or ethical decisions on behalf of the company;
- hide irreducible uncertainty behind a green status;
- make the application dependent on a permanent connection to Gabion.

The task Gabion sets itself is narrower and more practical: to take the repeatable technical decisions that can be standardized in advance away from the human and the AI, and to make the critical boundaries of the project verifiable.

## What remains at the end is an independent application project.

The result of the work of Gabion is a separate project on the coherent stack, not a script executed inside a closed Pikiner platform.

The source code of the project is available to the client. This does not mean the project has to be published as open source: the client can keep the product closed.

### What is inside the project

Depending on the agreed contents, the project directory holds:

- a Java backend;
- the Spring configuration;
- a TypeScript frontend;
- Thymeleaf templates and sections;
- CSS and assets;
- the business logic of the product;
- the roles and access rules;
- the data structure;
- Flyway migrations;
- the integrations;
- the tests;
- the build configuration;
- the deployment configurations;
- the project documentation.

All contents of the delivered project directory belong to the client under the terms of the contract.

### What is outside the project

The following remain outside the client application directory:

- Gabion Runtime;
- the Gabion MCP interface;
- the Gabion browser UI;
- the internal module storage;
- the internal module-management CLI;
- the original anonymized module templates;
- the tools of the Pikiner production pipeline;
- the Gabion license token.

These elements must not enter the production artifact of the application.

### What the independence of the project means

The project can be:

- stored in the client's repository;
- read and changed without Gabion;
- built by standard means;
- tested without the Runtime;
- deployed without a token;
- handed to another team;
- developed with a different AI model;
- opened in a different IDE;
- moved to another agreed infrastructure;
- operated after the Gabion license ends.

Independence does not mean that any future deployment method is automatically supported by Pikiner documentation. It means the absence of a mandatory technical dependency on Gabion.

### A clean check of the result

The project being delivered has to pass a check in a separate environment:

1. obtain the repository;
2. do not install Gabion Runtime;
3. do not provide the license token;
4. do not connect to the module storage;
5. install the standard application dependencies;
6. build the backend;
7. build the frontend;
8. run the tests;
9. create a deployment artifact;
10. start the application;
11. pass the agreed scenarios;
12. confirm the absence of any calls to Gabion.

This check has to be reproducible rather than dependent on the machine of a Pikiner developer.

### What happens to module code

If a Gabion module was used when the project was created, the files the application needs are in the project directory.

The application must not:

- load the module from the storage while running;
- verify its license through Gabion;
- require the Runtime to execute code;
- lose the feature when the token expires.

Pikiner keeps the original anonymized module template outside the project. The client keeps the contents of their own project.

### What depends on Gabion

Valid access may be needed for:

- running the Runtime;
- using the MCP tools;
- the browser UI;
- architectural diagnostics;
- the AI integration features;
- Gabion updates;
- support for the tool.

The exact contents are determined by the license.

### What does not depend on Gabion

Access is not needed for:

- the operation of the production application;
- user requests;
- the client's access to data;
- the standard build;
- the project tests;
- deployment;
- access to the source code;
- manual development;
- the work of another team.

### Choices after handover

The team can:

- continue development with Gabion;
- use Gabion until the included period ends and not renew it;
- adopt the standard process without Gabion in parallel straight away;
- bring in specialists of their own;
- hand development to another contractor;
- use a different IDE or AI model.

Gabion has to remain a useful way to work with the project, not the only way to keep it working.

### What independence does not guarantee

Independence from Gabion does not by itself guarantee:

- the absence of errors;
- the safety of any future change;
- compatibility with any version of the dependencies;
- operation on any infrastructure;
- the preservation of the architectural constraints after manual changes;
- access to future Pikiner updates;
- access to the internal module storage.

After giving up Gabion the client is responsible for further changes, or transfers that responsibility to a team of their choosing.

### The open-source boundary

The following have to be distinguished:

- the client has the source code of their project;
- the client owns the project;
- the client can change the project;
- the project is published under an open-source license;
- Gabion Runtime is open.

The first three properties do not require the last two.

The client receives the source code of their own application. Gabion Runtime remains closed. The production product runs without it.

[Gabion for Pikiner Clients](https://gabion.dev/for-pikiner-clients)

## Choose the next level of explanation.

### Study the technical design

The technology page explains in detail:

- the coherent stack;
- the separate project directory;
- Gabion Runtime;
- the Starter;
- vertical modules;
- `gabion.manifest.json`;
- the contracts;
- MCP;
- the deterministic checks;
- updating the production pipeline;
- the independent production build.

[Gabion Technology](https://gabion.dev/technology)

### If you are considering a product migration

The first step happens on the Pikiner site.

At the first free meeting the client demonstrates their working product to the Pikiner team:

- the roles;
- the user journeys;
- the administrative functions;
- the business rules;
- the data;
- the integrations;
- the current stack;
- the deployment model;
- the known constraints.

This does not require handing over the entire repository in advance or carrying out a paid technical audit.

[How the Migration Works](https://pikiner.com/migration)

### If the project is a preliminary fit

Pikiner may separately offer the CTO or the technical team a free Gabion Live Showcase.

At the Showcase the Pikiner team demonstrates:

- a real project;
- the Runtime;
- the interaction with the AI;
- an architectural error;
- the diagnostics;
- the correction;
- the repeated check;
- a clean build without Gabion.

This is a second, separate meeting.

At the first meeting the client demonstrates their product to Pikiner. At the Gabion Live Showcase Pikiner demonstrates Gabion to the client.

The Showcase is not available as automatic open booking for any visitor.

[Gabion for Pikiner Clients](https://gabion.dev/for-pikiner-clients)

### Models and data

A separate page explains:

- external LLMs;
- local models;
- quantized models;
- the transfer of context;
- work with code;
- the data requirements;
- third-party costs.

[Models and Data](https://gabion.dev/models-and-data)

### Current availability

Gabion is not yet distributed as a standalone mass-market product.

[Check Availability](https://gabion.dev/availability)

[Show Your Product to Pikiner](https://pikiner.com/contact?intent=product-demo)

Short answers about the Runtime, the modules, the token, the license, and independence are collected in the FAQ.

[Frequently Asked Questions](https://gabion.dev/faq)