Frequently Asked Questions About Gabion

Gabion is a development environment for human and AI collaboration. It sets a coherent technology stack and an architectural structure, provides ready modules, gives the AI a technical interface through MCP, and checks the critical properties of changes.

The human defines the product logic and makes the decisions. The AI works on the implementation. Gabion enforces the rules that must not be reconstructed in every request to the model.

How Gabion Works

Not in the usual sense. Gabion is not a language model, a chatbot, or an editor with a text generation feature of its own.

It is a tool for working together with an external AI assistant or agent. It provides the model with context and permitted operations, checks the result by ordinary programmatic means, and shows the state of the process to the human.

The critical architectural constraints and checks of Gabion must not depend on another probabilistic answer from a model if they can be expressed deterministically.

The AI takes part in creating and correcting code as an external performer. Gabion organizes the environment around it, but does not pass off its own check as the opinion of a second AI.

No. It changes how the work is distributed.

The AI can perform a significant part of the operations on the stack, and Gabion can take over repeatable architectural decisions and checks. But the human is still responsible for the meaning of the feature, the acceptable behavior, the product trade-off, the assessment of the result, and the release decision.

No. It makes it possible to move part of the architectural decisions already taken out of the CTO's memory and into a verifiable production pipeline.

The CTO still defines the boundaries of the system, the acceptable level of risk, the data rules, the integrations, and changes to the architecture itself. Gabion helps avoid checking the same rule by hand in every new fragment of AI-generated code.

An AI IDE primarily provides the human with an editor, and the model with access to files, the terminal, and commands inside that editor.

Gabion does not require a particular IDE and solves a different class of problem: it sets the permitted architectural paths, provides modules, restricts tool operations, runs checks, and returns structured diagnostics. The interface for the human is displayed in the browser, and the AI interacts with Gabion through MCP.

A prompt or an instructions file tells the model what is desirable. It does not guarantee that the model understood the rule, applied it everywhere, and did not find another path.

Gabion aims to move critical rules to where they can be checked or secured by the design of a module. Instructions remain useful for context, but they are not the only defense of the architecture.

A linter and a static analyzer are useful parts of control, but they usually check individual properties of code that has already been written.

Gabion covers a wider cycle: it gives the AI context and tools, provides permitted components, restricts certain actions, runs different kinds of check, and returns the result in a form usable for correction. Existing linters, the compiler, the tests, and the analyzers can be part of that perimeter rather than be replaced by it.

No. The result remains ordinary application code on a coherent stack. Gabion does not hide the product behind a visual builder and does not require a production runtime of its own to serve users.

The human states the intent: which product behavior has to be created or changed, who it is for, and which conditions matter.

The AI can help clarify a requirement, study the project, and propose an implementation, but ambiguous product logic must not silently turn into a technical assumption by the model.

The code can be produced by an AI assistant or agent under the direction of a developer. The human can also write and change code directly.

Gabion does not require every change to be generated by a model. Its rules and checks have to apply to a change in the same way regardless of who produced it.

If a change violates a verifiable rule, Gabion returns structured diagnostics: what failed the check, where the problem was detected, and which action is expected next.

The AI can use that information for the next attempt. The human sees the state of the process and steps in if the error repeats, requires a change to the requirement, or goes beyond an automatic decision.

That depends on the permissions granted to the AI in the specific working environment. Gabion can control only the operations that pass through its perimeter, and the properties checked before a change is accepted.

If the agent is at the same time given unrestricted access to files, the database, production infrastructure, or bypass commands, Gabion alone does not remove the risk of that access. The tool policy has to match the threat model chosen.

A human, or an approved team process. A successful automatic check means the change satisfied defined criteria, but it does not prove that the feature is needed by the user, that it implements an ambiguous requirement correctly, or that it creates an acceptable business risk.

It must not mask the uncertainty with an automatic choice. The question returns to the human as a decision that requires product or engineering judgment.

The goal of Gabion is to automate the verifiable part of the process and to make the boundary of the human decision visible.

Gabion reduces the volume of repeatable checks, but it does not turn the code into a result that can be released without the team's responsibility.

The depth of manual review depends on the risk of the change. Code for authorization, payments, personal data, schema migrations, and external integrations requires more attention than a local change to a view. Gabion helps record that difference, but it does not remove it.

The Gabion production pipeline uses:

• Java;
• Spring Boot;
• Spring Security;
• JPA;
• PostgreSQL;
• Thymeleaf MPA;
• TypeScript strict;
• esbuild;
• Flyway for module migrations;
• Gradle Kotlin DSL.

The frontend does not use an SPA framework.

The server produces ready HTML through Thymeleaf, and TypeScript adds client behavior on the principle of progressive enhancement.

Types, Zod schemas, and the SDK are generated from Java DTOs through OpenAPI with Hey API.

DevSync and the tools inside framework/ are implemented in TypeScript and run through tsx.

The exact versions of the components are determined by the build files and the version matrix of the release concerned.

Gabion needs a mature, predictable stack that is widely represented in high-quality codebases. That makes it possible to use ready production components, to check stable architectural properties, and to give different models more definite context.

We do not claim that Java, Spring, PostgreSQL, and TypeScript are the only correct choice for every product. It is a deliberate restriction of variability inside the Gabion method.

The current product architecture of Gabion is built around the coherent stack of Java, Spring, PostgreSQL, and TypeScript. The stated guarantees cannot be carried over to another stack automatically.

External services in other languages can be part of the system, if their role and interfaces are agreed, but that does not mean Gabion governs their internal architecture in the same way.

No.

The frontend is a fixed part of the Gabion production pipeline.

It uses:

• Thymeleaf MPA for server rendering;
• TypeScript strict for client behavior;
• esbuild for the build;
• CSS;
• the visual layer of the Starter;
• the frontend parts of the vertical modules;
• automatically generated TypeScript types;
• automatically generated Zod schemas;
• an automatically generated SDK.

The generation pipeline:

1. the backend declares Java DTOs;
2. an OpenAPI description is produced from the Java DTOs;
3. Hey API generates TypeScript types, Zod schemas, and the SDK;
4. the frontend parts of modules use the generated artifacts.

No SPA framework is used.

Replacing the frontend perimeter would break type generation, the SDK pipeline, the structure of the modules, the manifest, server rendering, and the architectural checks of Gabion.

During a migration the client's existing frontend is used as a visual and behavioral baseline. Its agreed screens, states, and journeys are reproduced on the Gabion frontend perimeter.

If keeping a different frontend framework is a mandatory requirement of the new system, the project is technically incompatible with the Pikiner production pipeline.

Gabion maintains a coherent set of technologies and compatible versions, in order to reduce accidental variability between tasks and projects.

That does not mean any dependency is updated automatically without a check. A change to the platform set happens separately from ordinary product development and has to be verified for compatibility with modules and applications.

A module is a complete vertical unit of implementation.

Unlike a single library, class, or frontend component, a module can combine every technical layer needed for one capability of the application:

• the Java backend;
• the Spring configuration;
• TypeScript;
• Thymeleaf templates and sections;
• CSS;
• a page;
• the data structure;
• Flyway migrations;
• tests;
• checks;
• the project configuration.

The specific contents depend on the purpose of the module.

The contents and technical properties of a module are declared in gabion.manifest.json.

The manifest is the single source of module metadata.

It describes:

• pages and navigation elements;
• the access space;
• public and protected API paths;
• sections of aggregator pages;
• the presence of migrations;
• the contracts provided;
• the mandatory contracts;
• the optional contracts;
• the project elements belonging to the module;
• the mandatory checks.

For dependencies, the declarations used are:

• provides;
• requires;
• optional.

The manifest describes the contents of a module and its place in the project. The permitted interaction between modules is described by Java contracts.

The full manifest schema is not considered publicly stable until the policy for versioning it is approved.

The Starter and a module are different layers.

The Starter is the single visual shell of a project.

Exactly one Starter is used in a project.

The Starter contains:

• the main layout body;
• the themes;
• the canonical --gb-* CSS values;
• shared UI fragments;
• the visual foundation of the application.

The Starter:

• does not create a project;
• is not a module;
• does not add business functionality;
• does not replace the standard modules.

A module:

• adds a complete vertical capability;
• can include a backend, a frontend, templates, styles, a page, and migrations;
• declares its contents through gabion.manifest.json;
• provides and uses Java contracts;
• does not depend directly on other modules.

A project is created by the command gabion init my-project.

When a project is created, Gabion applies one Starter and the starting set of standard modules provided for.

gabion init creates the project. The Starter sets its visual shell. Modules add functional capabilities.

Modules do not depend directly on each other's internal implementation.

A Gabion contract is a Java interface in the stable layer dev.gabion.contracts.

A module can provide an implementation of a contract as a Spring bean returning the type of that contract.

Another module uses the Java contract, but does not import the internal classes of its provider.

The manifest declares:

• a contract provided, through provides;
• a mandatory contract, through requires;
• an optional contract, through optional.

A module must not:

• import the internal code of another module;
• depend directly on the implementation of another module;
• change another module's files arbitrarily;
• access the hidden data structure of another module;
• bypass a Java contract with a direct call;
• create an undeclared dependency on the order of installation.

A module knows the Java contract of the capability it needs, but not the internal design of the module that implements that contract.

Because a user capability rarely exists in only one technical layer.

For example, a complete feature can require, at the same time:

• a table and a migration;
• server-side business logic;
• an access rule;
• a user-facing page;
• frontend behavior;
• styles;
• tests.

A vertical unit makes it possible to check the feature as a whole, rather than assembling it from unconnected fragments in every new project.

The source anonymized templates are in the internal Pikiner storage.

The Gabion Runtime and the storage are outside the directory of the client's project.

After a module is applied, the files needed for the specific application are in the directory of the client's project.

No.

The storage takes part in creating and changing the project, but not in handling production requests.

The delivered application has to:

• build without access to the storage;
• start without the Runtime;
• not load a module while it runs;
• not check a Gabion license.

No. The project edition of Gabion does not provide direct access to the whole internal Pikiner catalog.

The client receives their own project, not the storage of production templates.

Not through the internal Pikiner module-management CLI.

The functions for adding, removing, replacing, updating, and publishing modules remain part of the production pipeline.

The client keeps the right to change the code of their own project in the ordinary way.

Two objects have to be kept apart:

1. the source anonymized template in the internal storage belongs to Pikiner;
2. everything in the directory of the delivered client project belongs to the client on the terms of the contract.

A shared template must not contain the client's data or unique business logic.

Yes, if an existing shared component is not enough for the agreed implementation.

The new module is created outside the client's directory as an anonymized reusable template.

The unique business logic stays in the client's project.

If the module is necessary to fulfil an already agreed migration SOW, creating it is internal Pikiner work and is not billed as a separate line.

After the migration is completed, new Pikiner work requires a separate SOW.

A module is particularly useful if the task:

• repeats across projects;
• affects several layers;
• has critical requirements;
• is often implemented incompletely by an AI;
• requires coordinated migrations;
• has to preserve architectural boundaries;
• allows a deterministic check.

Possible classes:

• authentication;
• roles and permissions;
• audit;
• files;
• notifications;
• background operations;
• integration adapters;
• configuration;
• observability;
• administrative functions.

This list does not mean that every such module has already been implemented.

On a public page, a module may be called available only if it:

• exists;
• has a manifest;
• has a defined contract;
• passes positive and negative tests;
• is compatible with the supported pipeline;
• is used in a real project or a prepared Showcase.

Experimental and planned modules have to carry a separate status and must not be described as ready capabilities.

Yes, if it is a considered change to the architecture rather than a local bypass to get the current task through.

Changing a rule may require a separate decision by the CTO, an update to the configuration, the module, or the version of the production pipeline. Not every rule should be available to an agent with the same authority as an ordinary change to a feature.

Only specific properties for which the following are defined:

• the scope;
• the mechanism that provides or checks it;
• the point at which the check runs;
• the criterion of a successful result;
• the threat model and the known ways around it;
• the version of Gabion and the project configuration.

Gabion does not give an abstract guarantee of the absence of errors, vulnerabilities, or downtime across the whole system.

Yes. Product logic, integrations, and some specialized components always depend on the specific system.

Gabion standardizes the repeatable foundation and the critical paths. If the uniqueness of a project requires abandoning too much of that foundation, Gabion may turn out to be the wrong tool for that product.

Gabion is designed independently of any one model provider and can be used with different LLMs, if they support the necessary form of tool interaction and are able to perform the specific task.

Actual compatibility has to be confirmed for the specific model, version, client, and configuration. The term "model-agnostic" means the absence of architectural belonging to one provider, not an identical result from any model.

Yes, if the local model and its environment support the required interaction and give an acceptable result for the tasks chosen.

Running locally makes it possible to change the data boundary and to control the cost of inference better, but it requires computing infrastructure of your own, configuration, and measurement of quality.

Yes, if its quality is sufficient for the specific class of task.

Deterministic checks help detect some of the errors and return them to the model for correction. But they do not make a quantized model and a full one the same: the number of attempts, the time, the ability to hold context, and the need for human involvement can all differ.

The architecture of Gabion allows a model to be chosen per task, if the specific integration supports it.

For example, a cheaper model can perform limited repeatable work, and a stronger one can work through an ambiguous change. That mode makes sense only when the full cost of an accepted result is measured, including repeated attempts and manual review.

It reduces the dependence of some critical properties on the quality of a single attempt by the model: it restricts the path, provides a ready component, or rejects a verifiable violation.

But Gabion does not add knowledge to the model, or the ability to reason, or an understanding of the product. If the model cannot perform the task after clear diagnostics, the work has to go to a more suitable model or to a human.

The recommendation depends on the type of task, the data requirements, the infrastructure available, the speed, and the budget. There is no single universal answer.

For a practical choice, models have to be compared on the tasks of the specific project, counting not the price of one request but the cost of an accepted change.

No. Gabion is intended to work with models that are already available and does not require fine-tuning.

Specialized training can be used by a separate team, if it has a task and data of its own, but it is not a condition of using the technology.

Models and Data

The model receives only the context selected and passed to it through the AI client and tools in use. That can include the requirement, the files relevant to the task, the module contracts, the diagnostics, and the results of permitted operations.

The actual data boundary is determined by the whole configuration: the AI client, the model, the MCP connections, the external tools, the logs, and the project policy.

Gabion by itself must not automatically mean the transfer of the whole repository to one provider. But if the team has connected a cloud LLM, the selected context is transferred through the corresponding integration.

Before working on a confidential project it is necessary to determine who assembles the context, where it is sent, which retention terms apply, and which categories of data are prohibited from transfer.

No, not by itself. Even with a local LLM, external connections can be opened by the AI client, the package manager, telemetry, crash reporting, the project's own external APIs, or other tools.

A fully local mode requires auditing the whole perimeter, not only the address of the model.

That depends on the current implementation, the logging settings, and the connected AI client. Before a permanent answer is published, the list of data, the storage locations, the deletion periods, and the settings for disabling logs have to be approved.

For a client project these terms have to match the contract and the data processing policy.

Secrets must not be included in the ordinary context of the model or kept in the source code. A project needs a separate storage mechanism, restricted credentials, and masking of sensitive values in diagnostics and logs.

Gabion can take part in checking the rules for handling secrets, but it does not replace a cloud secret manager, key rotation, and the access policy of the organization.

Only if the organization itself grants it such a tool or credentials. By default the development workflow must not require unrestricted production access for the model.

Any operation on production has to have separate minimal privileges, an audit trail, and human confirmation in proportion to the risk.

The token confirms the right to use the closed Gabion features.

Depending on the approved implementation, it may define:

• the client;
• the permitted project;
• the validity period;
• the permitted users or devices;
• the available Runtime features;
• the available MCP tools and resources;
• the edition of Gabion;
• the right to receive the updates provided.

The exact set of claims has to be described in the technical documentation without publishing details that make circumventing the license easier.

If the token is absent, expired, or revoked, the following may become unavailable:

• the Gabion Runtime;
• the licensed MCP tools;
• the Gabion browser UI;
• the Runtime diagnostics;
• updates;
• help with Gabion;
• other features listed in the license.

The message has to state directly that Gabion is unavailable, not the client's project.

The token must not take part in:

• starting the production backend;
• loading the frontend;
• authenticating the users of the product;
• executing business logic;
• queries to the database;
• the operation of the application's integrations;
• the standard build;
• running the tests of the project;
• producing a deployment artifact;
• the client's access to the code;
• the client's access to the data;
• the operation of the client's CI/CD.

The production application must not check the validity of the Gabion token.

The token belongs to the Gabion working environment and is outside the source code of the application.

It must not be stored:

• in Git;
• in gabion.manifest.json;
• in Java or TypeScript;
• in the frontend bundle;
• in the Docker image of the application;
• in the deployment artifact;
• in the documentation;
• in logs without masking;
• in the production database of the product.

The specific safe method of storage has to be documented for every supported operating system.

The grounds for revocation are determined by the license.

They may include:

• the end of the access period;
• non-renewal;
• a client request after a compromise;
• replacement of the token;
• use for a project that is not permitted;
• a breach of the license terms;
• termination of the contract in the procedure provided;
• a mandatory requirement of law.

Revoking the token must not be used as a means of shutting down the production application or holding on to the client's project.

If the token has been disclosed:

1. the old token is revoked;
2. a new token is created with the necessary scope;
3. the available usage logs are checked;
4. the token is removed from the unsuitable location;
5. if it reached Git, the history is checked;
6. the cause of the disclosure is eliminated.

Replacing the token does not require a change to the source code of the application or a production deployment.

That depends on the actual implementation of the licensing.

Before publication it is necessary to determine and verify:

• whether a permanent connection is required;
• whether an offline mode exists;
• whether a grace period exists;
• which features are available without a check;
• what happens on a temporary network error;
• which events are logged;
• how access is restored.

An offline mode or a grace period must not be promised before it is implemented and tested.

Whichever model is chosen, the unavailability of the license service must not affect the production application.

For every version delivered, a negative test is performed:

1. Gabion starts with a valid test token.
2. The project is checked successfully.
3. The Runtime is stopped.
4. The token is made invalid.
5. Gabion rejects the licensed operation.
6. The project builds without the Runtime.
7. The tests of the application run.
8. A deployment artifact is produced.
9. The application starts.
10. A user scenario works.
11. The application makes no calls to the license service.

The correct result: Gabion is unavailable, and the client's product keeps working.

It must not.

A license check must not automatically send:

• the source code;
• the business logic;
• user data;
• the contents of the database;
• prompts;
• model responses;
• secrets;
• client documents.

Before publication it is necessary to document the actual network request:

• the endpoint;
• the identifiers transmitted;
• the logs;
• the retention period;
• the subprocessors;
• the ways to disable optional telemetry.

Gabion is installed in the working environment where the AI and the developer interact with the project. The stated target support includes Linux x64 and arm64, macOS, native Windows, and WSL2.

Before a public launch the list has to be confirmed by a matrix of tested operating system versions and architectures.

Gabion is designed to install without root or sudo. That reduces the scope of system privileges and makes it easier to use in a managed working environment.

Individual project dependencies, containerization, or corporate policies may impose their own requirements, which are not part of the Gabion installer.

No. Gabion must not depend on one IDE.

The AI interacts with it through a supported MCP client, and information for the human is displayed in the browser. The team chooses the code editor separately.

A technical interface convenient for the AI and an interface convenient for a human solve different problems.

Through MCP the agent receives operations, contracts, and diagnostics. In the browser the human sees the state of the project, the checks, the warnings, and the points where their decision is required, without reading the internal dialogue of the model.

That depends on the specific topology: where the project is, where the MCP client runs, which ports and file operations are permitted, and how the user interface is opened.

Support for Docker, remote development environments, and CI has to be described as separate verified configurations rather than assumed automatically.

Some of the deterministic checks may be useful in an automated pipeline, but the exact run mode, the licensing, and the behavior without an interactive user have to be confirmed for the version concerned.

CI does not replace the checks in the agent's own cycle: a late failure in a pipeline is more expensive feedback than detecting the violation while the change is being made.

Everything in the separate directory of the delivered project belongs to the client on the terms of the contract.

That includes:

• the source code of the application;
• the unique business logic;
• the frontend and the backend;
• the configuration;
• the data structure;
• the migrations;
• the tests;
• the templates;
• the styles;
• the deployment configurations;
• the project documentation.

The Gabion Runtime and the internal module storage are outside that directory.

Two objects have to be kept apart.

The source Pikiner module template

It:

• is created outside the client's directory;
• is kept in the internal Pikiner storage;
• is an anonymized reusable template;
• belongs to Pikiner;
• can be used when creating other projects.

The code in the client's project

After a module is applied, the code, configuration, migrations, templates, TypeScript, CSS, and tests located in the directory of the delivered project belong to the client.

The production application does not load that code from the internal Pikiner storage and does not check a Gabion license for it.

The source template outside the project and the code inside the client's project are different objects with different boundaries of ownership.

No. A reusable Pikiner module must not contain:

• the client's unique business logic;
• data;
• secrets;
• the source code of the old product;
• the client's name;
• confidential rules;
• identifiers that make the client identifiable.

The unique implementation stays only in the client's project.

No. The Runtime remains a closed Pikiner technology.

The client receives:

• the source code of their own project;
• the project documentation;
• licensed access to the project edition of Gabion for the period established.

No. The Runtime, the internal storage, and the Gabion production tools are outside the directory of the client's project.

The Runtime can work with a permitted project during development, but it does not become part of the application.

No. The Runtime belongs to the development environment.

The production application must not:

• start the Gabion Runtime;
• contact the Gabion MCP;
• load modules from the Pikiner storage;
• check the license token;
• contact Pikiner in order to execute the user's business logic.

No. The delivered project has to build, deploy, and serve users without a valid Gabion license.

External services of the product itself can remain its production dependencies, if they are expressly part of the application architecture. They have to be listed separately and not hidden under the name of Gabion.

No. The token controls access to Gabion features, not the operation of the client's application.

A revoked or expired token can make the following unavailable:

• the Runtime;
• the Gabion MCP tools;
• the Gabion interface;
• updates;
• the help provided for by the license.

It must not block:

• the backend;
• the frontend;
• the database;
• the users;
• the standard build;
• the deployment;
• the client's access to code and data.

Before the handover the project has to pass a clean scenario without Gabion:

1. the project is obtained in a clean environment;
2. the Runtime is not installed;
3. no token is provided;
4. there is no connection to the internal storage;
5. the backend and the frontend build;
6. the tests run;
7. a deployment artifact is produced;
8. the application starts;
9. the agreed scenarios work;
10. there are no calls to Gabion.

Yes. The client can work with the project as with a standard application on Java, Spring, PostgreSQL, and TypeScript.

Without Gabion the team is responsible on its own for:

• the architectural boundaries;
• the choice of dependencies;
• the checks;
• the migrations;
• code review;
• testing;
• production releases.

That is a change to the development process, not a lock on the code.

Yes. The client can bring in their own developers, a new CTO, or another contractor.

Operating and changing the delivered project requires neither permission from Pikiner nor a valid Gabion license.

No. Another team receives the client's project, not the internal storage or the Pikiner module-management CLI.

It can read and change the code of the client's project with the standard tools of the stack.

Yes. Removing the Runtime must not delete or change the client's project.

Before removal it is necessary to keep:

• the project;
• the documentation;
• the build instructions;
• the necessary local settings without secrets;
• the data belonging to the client's application.

The full procedure for removing the Runtime, the token, the cache, and the configuration has to be described for the supported environment.

A production application already delivered keeps working.

The client keeps:

• the project;
• the source code;
• the data;
• the documentation;
• the standard build;
• the right to continue development with another team.

What can stop is only future updates, Runtime features, and help with Gabion, in accordance with the license.

Not necessarily. The client receives the source code of their own project, but can keep it closed.

The Gabion Runtime also remains a closed Pikiner product. The source code being available to the client and a public open-source license are different things.

The client receives two different results:

1. a standalone application project;
2. licensed access to the project edition of Gabion for the first year.

The project stays with the client after the license ends. Gabion remains a closed Pikiner technology.

The exact set of features of the project edition is determined by the license.

It may include only the features expressly listed:

• the Gabion Runtime;
• MCP tools and resources;
• architectural checks;
• diagnostics;
• the browser UI;
• the supported AI integrations;
• documentation;
• the updates provided;
• help with Gabion to the scope established.

The project edition is granted for continuing the development of the application created as part of a specific Pikiner migration.

It is not a license to use Gabion as an internal factory for new products or third-party projects.

The one-project limit must not prevent ordinary work on the same application:

• creating branches;
• using development and staging;
• running CI;
• creating local copies;
• maintaining a backup repository;
• building deployment artifacts.

No, unless the license expressly provides for it.

The gabion init command for a new independent project may be unavailable in the client edition.

That limit does not affect the existing delivered project.

No. The internal storage remains part of the Pikiner production pipeline.

The client does not receive:

• the ability to browse the whole catalog;
• the storage credentials;
• the source templates of all the modules;
• experimental modules;
• the right to download modules for other projects;
• the right to distribute them.

No. The internal CLI functions for adding, removing, replacing, and updating modules are not part of the project edition.

The client can change the code of their own project with the standard tools of the stack.

The code, configuration, migrations, templates, and other elements located in the directory of the delivered project stay in the client's project.

The application does not load them from the Pikiner storage while it runs.

There are three options:

1. implement the specific change directly in the client's project;
2. use an existing extension point;
3. agree separately with Pikiner on creating or applying a shared module.

New Pikiner work requires a separate SOW with a defined result, price, and date.

The first year of Gabion does not mean the free creation of any new modules.

The exact date has to be stated in the SOW and the license.

The period must not start before the client is given working access to the Runtime, the token, the documentation, and the project.

Only the features, updates, and help expressly listed in the client license.

The first year is intended for practical work by the team on the delivered project, including:

• installing Gabion;
• studying the structure;
• making a real change;
• working with the diagnostics;
• verifying the result independently;
• going through a release cycle.

Only the help expressly described in the license is included.

Before publication it is necessary to determine:

• the channel;
• the hours;
• the categories of question;
• the scope;
• the response time, if one is promised;
• the escalation procedure.

The phrase "the first year is included" does not by itself mean unlimited support.

No, not automatically.

The first year of Gabion does not include:

• monitoring;
• on-call;
• an SLA;
• incident response;
• user support;
• administration of the infrastructure;
• continuous development by Pikiner.

Such work is possible only under a separate SOW, without any availability of the team promised in advance.

That has to be determined by the license.

The following have to be listed separately:

• Runtime updates;
• security fixes;
• compatibility updates;
• new checks;
• mandatory updates;
• the previous versions supported;
• the effect of an update on the project.

An update to the Runtime must not automatically change the client's project or production.

The client chooses to:

• renew access to Gabion;
• continue development without Gabion;
• hand the project to another team.

In every case the production application, the code, and the data stay with the client.

Only if the automatic renewal mechanism, the charge date, and the cancellation procedure have been agreed separately and clearly.

The preferred option for the project edition is explicit acceptance by the client of the terms of the next period.

Pikiner communicates in advance:

• the end date;
• the features of the next period;
• the supported version;
• the number of users;
• the updates;
• the scope of help;
• the limits;
• the price;
• the payment period;
• the deadline for the decision.

The licensed Gabion features become unavailable.

The following keep working:

• the production application;
• the standard build;
• the tests of the project;
• the deployment;
• access to the code;
• access to the data;
• development with the ordinary tools of the stack.

The client can approach Pikiner, but automatic compatibility with a future version of Gabion is not guaranteed.

Before restoration it may be necessary to check:

• the current stack;
• the dependencies;
• the structure;
• the migrations;
• the changes made by another team;
• the architectural boundaries;
• the manifest;
• the supported version of the Runtime.

Yes, if the project has to be brought separately into line with the supported production pipeline.

Such work starts only after a separate SOW with a defined result, price, and date has been agreed.

Gabion can stop the licensed operations, but the production application has to keep working.

For a valid license the client needs a channel for reporting a technical error with the token and a safe way to replace it.

Yes. A clean build without the Runtime and the token has to be verified before the project is handed over.

It is also useful for the team to repeat that scenario before deciding about renewal.

It is a separate free technical meeting for a suitable project.

At it the Pikiner team demonstrates:

• the structure of the project;
• the Runtime;
• the interaction with the AI;
• a real error;
• the diagnostics;
• the correction;
• the repeated check;
• an independent build.

No.

At the first meeting the client demonstrates their working product to Pikiner.

A Gabion Live Showcase is held separately, after preliminary confirmation that the project is applicable. At it Pikiner demonstrates Gabion to the client.

Gabion for Pikiner Clients

Not as a publicly available standalone product. Gabion is currently provided to clients together with the Pikiner migration service.

A separate installation package may exist technically, but that does not mean an open right to download and use it.

Not yet. Standalone plans and a public subscription have not been launched.

The intention is a staged opening: first for individual web studios, then for companies, and later for individual developers. This is a direction of development, not a promised calendar.

Gabion affects the real development process, the rights of the tools, and the architecture of the systems created. Before mass access, the installation, the compatibility of models, the updates, the diagnostics, the support, and the safe boundaries of the product have to be confirmed in different environments.

Limited access makes it possible to develop the technology on real projects without promising universality ahead of actual readiness.

Gabion exists and is being developed as a working Pikiner technology. What is in the future is the standalone mass distribution model, not the product itself.

Public demonstrations and specific technical statements have to show only the features available in the current verified build.

Yes. On the availability page you can describe the company, the usage scenario, the stack, the AI tools, and the data requirements.

This is not a license reservation and not a promise of an access date. The information is used to identify suitable early scenarios.

No. Public plans will be defined for each access model after the contents of the product, the support, and the economics of operation have been verified.

The cost of a Pikiner project migration should not be carried over to a future Gabion subscription, or the reverse.

No. Gabion is developed as a closed Pikiner technology. Clients and future users are granted a right of use on the terms of a license, not the source code of the runtime and the shared module repository.

Yes, through the interest form, if the proposal concerns developing or verifying Gabion. Submitting the form does not create an obligation to start a pilot, to grant access, or to accept an investment proposal.

Gabion Availability

No. It can prevent or detect certain classes of violation in a certain configuration.

Errors can remain in the product logic, an incomplete specification, third-party systems, uncovered paths, the infrastructure configuration, and properties for which no check exists.

Not in an absolute sense. Security is a property of the whole system and process: the code, the dependencies, the infrastructure, the access rights, the data, the operation, and the response to new vulnerabilities.

Gabion can make some critical rules mandatory and verifiable, but each such guarantee has to be described separately, together with its scope and its threat model.

Not without measurements of the specific product. A coherent architecture can remove the known limitations of a prototype foundation, but the actual performance depends on the load, the queries, the data model, the integrations, and the infrastructure.

Load targets and criteria have to be verified separately.

No. Models differ in the quality of their reasoning, their ability to work with tools, the size of their context, their speed, and their cost.

Gabion makes the environment and part of the criteria the same, so that results can be compared and errors can be returned for correction. That does not remove the differences between models.

Technical incompatibility does not arise from the size of the project, the current stack, or the absence of a ready internal module.

A project may turn out to be incompatible if a mandatory requirement of the new system cannot be implemented inside the Gabion production pipeline.

For example:

• a mandatory main stack has to stay outside the supported perimeter;
• a contract or an external system prohibits the use of a necessary technology;
• a mandatory architectural boundary is incompatible with the Gabion contracts;
• a requirement for the runtime environment cannot be met in the target architecture;
• a mandatory property of the data or an integration is outside the supported method;
• the organization requires Gabion itself to be open source;
• a publicly available standalone product without project and license restrictions is needed today.

Unique business logic or the absence of a ready module is not in itself an incompatibility.

If the necessary component can be implemented inside the architectural rules of Gabion, Pikiner can create a new anonymized reusable template for it.

Yes. For every significant property it is worth asking:

1. which mechanism provides it;
2. in which version it is available;
3. how it is verified;
4. where its boundary of effect runs;
5. what happens if Gabion fails;
6. whether the application stays operational without it.

We intend to publish technical material and verifiable demonstrations as features become ready.

Gabion is developed by Pikiner as its own technology for production development with AI.

It came out of a practical problem: to reduce the number of critical decisions the AI implements again every time, and to move the verifiable properties of a system out of the model's explanations and into architectural contracts, modules, and deterministic checks.

Pikiner and Gabion answer different questions.

pikiner.com explains the service of migrating a working product to a new technical foundation.

gabion.dev explains the technology with which Pikiner builds the new system, and with which the client's team can continue development after the handover.

These are related but different objects:

• Pikiner is the company and the migration service;
• Gabion is the production technology and the development tool.

Technologically Gabion exists as a separate Pikiner tool.

Commercially it is not yet distributed as a publicly available standalone product for any user or project.

Current practical access is provided to Pikiner migration clients as part of a project license.

Future standalone availability is considered separately and must not be implied by the current terms for Pikiner clients.

No. The technical pages are available to any reader.

But public documentation does not automatically provide:

• the Runtime;
• a token;
• the internal module storage;
• a project license;
• the right to create a new project;
• access to a Live Showcase.

Use the form on the Pikiner site.

The first step is a free meeting at which the client demonstrates their working product to the Pikiner team:

• the user roles;
• the main journeys;
• the administrative functions;
• the business logic;
• the important states;
• the data at the level necessary to understand the product;
• the main integrations;
• the known limitations;
• the reason for the migration.

If the current stack, the structure of the system, and the deployment model are known, it is useful to describe them briefly. Preparing that material specially for the first meeting is not required.

The first meeting does not require:

• handing over the repository;
• providing the source code;
• opening production access;
• handing over production data;
• preparing a full technical audit;
• compiling full documentation.

The phrase "product demonstration" is better avoided without naming the side.

At the first meeting the client demonstrates their product to the Pikiner team.

It is an introduction to the client's working system, not a presentation of Gabion.

In the interface, in emails, and in invitations the meeting has to be called a Client Product Demonstration.

Pikiner first checks the technical compatibility of the product's mandatory properties with the production pipeline.

If an incompatibility becomes clear, Pikiner reports it immediately and explains the specific technical boundary.

If the product is compatible, Pikiner continues gathering the necessary information free of charge, up to a fixed proposal with a defined scope, price, and date.

No separate paid discovery is sold before the proposal.

A Gabion Live Showcase is a separate free technical meeting for a suitable project.

At it the Pikiner team demonstrates to the client:

• the structure of a real project;
• the Gabion Runtime;
• the interaction with the AI;
• the architectural constraints;
• a real error;
• the diagnostics;
• the correction;
• the repeated check;
• an independent build of the application.

It is not the first meeting and not a study of the client's product.

After preliminary confirmation that the project is suitable for further discussion of a migration.

A Showcase must not have open automatic booking for any visitor.

Pikiner offers this meeting separately to the CTO or the technical team of a suitable client.

If the question requires verification of the Runtime, the internal engines, the manifest, the architectural contracts, or the module lifecycle:

1. the team records the question;
2. clarifies the technical context if necessary;
3. verifies the answer against the actual implementation;
4. sends the client a written technical explanation.

That procedure makes it possible to separate the confirmed behavior of the current implementation from an assumption or a future direction of development.

The public site does not describe the internal allocation of the specialists who prepare the answer.

For now such a video must not be promised as available material unless it has been made and verified.

A future video could show:

• a real error;
• the diagnostics;
• the correction;
• the repeated check;
• a clean build.

It would still have to remain a technical explanation of the role of Gabion in the Pikiner service, rather than create a premature impression that a standalone product is openly for sale.

For a question about Gabion that is not tied to a specific migration, use the form on the availability page.

You can select the corresponding type of interest:

• a technical question;
• future standalone access;
• a web studio;
• a company;
• an individual developer;
• a pilot;
• a partnership.

The form can be used to state an interest, but it does not create an automatic right to a Showcase and does not book a meeting.

For a migration client, the decision about a Showcase is made after seeing their working product.