---
title: "For Pikiner Clients"
description: "What a Pikiner client receives together with the project, which limits apply in the first year, and why the application keeps working without Gabion."
canonical: "https://gabion.dev/for-pikiner-clients"
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>.

Gabion after a Pikiner migration

# The team gets Gabion. The product does not become dependent on it.

Together with the migrated system, the client receives the project edition of Gabion for the first year. It allows the existing team to continue developing the new project together with the AI in the same production pipeline.

The access applies to the development tool. The operation of the application, the users, the code, and the data do not depend on renewing Gabion.

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

[How Gabion Works](https://gabion.dev/how-it-works)

- Access for the delivered project
- The first year is included in the migration terms
- A closed Runtime and a revocable token
- Independent build and operation of the application

## The migration ends with the handover of the ability to continue development.

Creating a new system on a different stack and handing over the repository is not enough. If the previous team cannot make changes with confidence, the client receives a working product together with a new staffing dependency.

Gabion exists to preserve a different outcome: the team continues to define the features and the business logic, the AI works with Java, Spring, PostgreSQL, and TypeScript, and the production pipeline enforces the architectural rules.

After the handover the team uses Gabion to:

- navigate the structure of the new project;
- work with the extension points provided;
- use the modules available to the project;
- run architectural and technical checks;
- receive structured diagnostics;
- direct an AI assistant or agent through MCP;
- see the state and the results of the work in the browser interface.

The client receives not only a new codebase, but a working method of developing it with their current team.

## The client receives a standalone project and separate access to Gabion.

After the migration the client has two different results:

1. the delivered application project;
2. access to the project edition of Gabion for the first year.

The project belongs to the client and continues to exist after the access ends. Gabion remains a closed Pikiner tool and is used under the terms of a separate license.

### The delivered application project

The client receives a separate project directory, which holds:

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

The exact functional contents are determined by the SOW, but the client's right to the delivered project does not depend on renewing Gabion.

The project has to:

- build with the standard tools of the stack;
- run its tests without the Gabion Runtime;
- produce a deployment artifact without a Gabion token;
- run in production without a connection to Gabion;
- remain available to the client after the license ends;
- allow further development by another team.

### The project edition of Gabion

For the first year the client receives licensed access to Gabion for work on the specific delivered project.

The project edition contains only the features expressly listed in the client license.

They may include:

- the Gabion Runtime for the supported working environments;
- the MCP server;
- the permitted tools for an AI assistant or agent;
- architectural checks;
- project structure checks;
- diagnostics;
- the human interface;
- work with the extension points provided;
- the installation documentation;
- the documentation for working with the delivered project;
- the updates expressly included in the access period;
- help with Gabion to the extent expressly stated.

### Code created using modules

The internal Pikiner production pipeline builds the project using Gabion modules.

Everything that is in the client's project directory after the build is part of the delivered project, including:

- the code created;
- the configuration;
- the migrations;
- the templates;
- the styles;
- the tests;
- the product-specific implementation.

The application does not load these elements from the Pikiner storage while running in production.

The client does not need access to the internal module repository in order to build or run a project that has already been delivered.

### What stays with Pikiner

The client delivery does not include a transfer of rights to:

- the source code of the Gabion Runtime;
- the internal module storage;
- the internal CLI functions for adding, removing, and replacing modules;
- the source anonymized module templates outside the client project;
- the Pikiner production tools;
- the right to distribute or resell Gabion;
- the right to create an unlimited number of new projects;
- future features not included in the license.

This boundary applies to the Pikiner technology, not to the contents of the client's delivered directory.

### Handover documentation

Together with the project, the client has to receive the documentation necessary for independent work in the agreed environment:

- the working environment requirements;
- the instructions for running locally;
- the build instructions;
- the test commands;
- a description of the environment variables without secret values;
- the procedure for producing a deployment artifact;
- a description of the project structure;
- a description of the main extension points;
- a list of the external dependencies;
- a list of the applicable third-party licenses;
- the installation instructions for the project edition of Gabion;
- a description of the client license features and limits;
- the procedure for obtaining help with Gabion;
- the end date of the included period;
- the renewal procedure.

The documentation must not require the client to ask Pikiner for a hidden mandatory command merely to perform a standard build or to run the application.

### Verification of the handover

Before the migration is completed, the parties separately verify:

- the client's access to the repository;
- the full agreed contents of the project;
- a clean build without the Runtime;
- running the tests without a token;
- producing a deployment artifact;
- the operation of the application without Gabion;
- the absence of the internal Pikiner storage from the production dependencies;
- the client's access to the necessary documentation;
- installing and starting the project edition of Gabion;
- the feature boundaries of the client license.

The project is transferred to the client. Gabion is provided to the client under a license. The end of the license does not take the project back.

## The project edition is intended for developing one delivered product.

The Gabion project license is not a full public distribution of the technology and does not provide the client with the internal Pikiner production pipeline.

All the limits are listed before the contract is signed and have to apply identically in the license, the Runtime, the interface, and the documentation.

### One delivered project

The license is granted for the application created as part of a specific Pikiner migration.

It allows work with the agreed directory of the delivered project.

#### By default the license does not include

- creating new independent products;
- using Gabion as an internal project factory for the client;
- servicing third-party projects;
- transferring the license to another project;
- using one token for an unlimited number of repositories.

#### The one-project limit must not prevent

- creating branches;
- using separate development and test environments;
- creating the necessary local copies of the repository;
- running CI;
- building deployment artifacts;
- maintaining the infrastructure configurations of the same product.

If Pikiner offers a different access model in the future, it will be governed by separate terms.

The exact technical identification of the project has to be described in the license and must not accidentally block the ordinary development process.

### The closed Gabion Runtime

The source code of the Gabion Runtime is not transferred to the client.

The client receives a limited right to use the Runtime:

- for the period established;
- for the permitted project;
- by the permitted number of users;
- in the supported working environments;
- with the features included in the client license.

A closed Runtime does not mean a closed client project.

The Runtime is located outside the project directory and is not part of the production artifact.

### No access to the internal module storage

The client does not receive:

- the credentials of the internal storage;
- the ability to browse the whole module catalog;
- the ability to download the source templates;
- access to experimental or internal modules;
- the right to copy modules into other projects;
- the right to distribute modules;
- administrative operations on the storage.

Code that has already entered the directory of the delivered project remains part of the client's project and requires no connection to the storage for the build or for production operation.

### No internal module-management functions

The project edition does not provide the internal Pikiner CLI functions for:

- adding a module from the storage;
- removing an installed module;
- replacing a module;
- updating a module from the internal catalog;
- browsing all the available modules;
- publishing a new module;
- changing the manifest of a shared module;
- creating their own distribution of the storage.

These functions remain part of the Pikiner production process.

The client can change the code of their project with the ordinary tools of the stack. The module-management CLI limit does not block manual development of the delivered application.

### A limited set of features

The client receives only the features stated in the project license matrix.

The matrix has to list:

- the MCP tools;
- the MCP resources;
- the architectural checks;
- the project checks;
- the browser UI;
- the supported AI integrations;
- the available diagnostics;
- the project analysis functions;
- the updates;
- the channel and the scope of help;
- the technical limits.

Demonstrating a feature at a Gabion Live Showcase does not include it in the license automatically. An obligation arises only from signed terms.

### A limited period

#### The first year of access defines

- the start date;
- the end date;
- the permitted users;
- the supported versions;
- the included updates;
- the scope of help;
- the termination conditions;
- the renewal procedure.

#### The phrase "the first year is included" does not mean

- a perpetual license;
- perpetual updates;
- permanent availability of Pikiner;
- unlimited technical support;
- monitoring;
- on-call;
- an SLA;
- automatic inclusion of future features.

### Distribution limits

#### The client does not receive the right to

- resell Gabion;
- provide the Runtime as a service to third parties;
- publish closed components;
- circumvent the license limits;
- extract the internal module storage;
- create a derivative product based on the closed Runtime, unless that right is granted separately.

#### These limits do not apply to the client's right to

- store their project;
- change their project;
- deploy their application;
- give their team access to the code;
- hand development to another contractor;
- operate the production application after Gabion ends.

### The token applies only to Gabion

The project edition can use a revocable token.

The token controls licensed access to the Runtime and its features.

It does not control:

- the client's repository;
- the source code of the application;
- the database;
- the production deployment;
- the user accounts;
- the operation of the backend;
- the operation of the frontend;
- the standard build;
- the client's right to the project.

Revoking the token or letting it expire must not change the project files or send a shutdown command to the production application.

### Changes to the license terms

New terms apply to the next period only after they have been communicated to the client and agreed in the procedure provided.

An update to Gabion must not automatically:

- expand the scope of Pikiner's access;
- add data transfers to external providers;
- change the permitted project;
- enable new paid features;
- change production code;
- install a new module into the project;
- publish a new deployment.

### All the limits are known in advance

Before signing, the client receives:

- the text of the license;
- the feature matrix;
- the system requirements;
- the access period;
- the token terms;
- the project limits;
- the update terms;
- the scope of help;
- the renewal procedure;
- the consequences of not renewing.

The license limits the use of Gabion. It does not limit the ownership and operation of the delivered project.

## The token opens Gabion, not the client's application.

The project edition of Gabion uses a revocable license token.

The token confirms the team's right to use the closed Runtime and the features included in the license. It is not an encryption key for the project, a startup key for the backend, or a permission for users to access the product.

### What the token can define

Depending on the approved implementation, the token may contain or confirm:

- the client;
- the permitted project;
- the validity period;
- the permitted users or seats;
- the available Runtime features;
- the available MCP tools and resources;
- the available human interface;
- the supported edition of Gabion;
- the right to receive the updates provided;
- other limits of the client license.

### What the token can block

If the token is absent, expired, or revoked, Gabion can stop:

- starting the closed Runtime;
- the use of the licensed MCP tools;
- access to the Gabion interface;
- running the checks available only through the Runtime;
- receiving updates to the project edition;
- other features that depend directly on the license.

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

### What the token must not control

The token must not take part in:

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

Production code must not send the Gabion token or check whether it is valid.

### Where the token is kept

The token belongs to the Gabion working environment, not to the source code of the application.

It must not be stored:

- in Git;
- in `gabion.manifest.json`;
- in the source code;
- in the templates;
- in the frontend bundle;
- in the Docker image of the application;
- in the deployment artifact;
- in the project documentation;
- in logs without masking;
- in the production database of the application.

The documentation has to explain:

- where the token is stored;
- how permissions on the file or the store are restricted;
- how to replace it;
- how to revoke it;
- how to remove the token when uninstalling;
- which diagnostic data may contain its identifier.

The specific storage mechanism is published only after the supported operating systems have been verified.

### Why the token can be revoked

The grounds for revocation have to be listed in the license.

They may include:

- the end of the included period;
- termination or non-renewal of the license;
- a client request to revoke a compromised token;
- replacement of the token;
- a breach of the license terms;
- an attempt to use Gabion for a project that is not permitted;
- compromise of credentials;
- termination of the contract in the procedure provided;
- a requirement of law or a binding order from an authorized body.

Revocation must not be used as a technical means of settling a dispute about the production application, or as a means of holding on to the client's project.

### Notice that the period is ending

Before the scheduled end of the first year, the client has to receive information on:

- the end date;
- the features that will become unavailable;
- the renewal options;
- the price of the next period, if it has been determined;
- the actions required;
- how to continue work without Gabion;
- the procedure for exporting project-related material, if such an export is provided for.

The expiry of the token must not become an unexpected event for the production team.

The specific notice period is determined by the license and by the internal Pikiner process.

### Behavior when the license service is unavailable

Before publication it is necessary to determine and verify:

- whether the Runtime requires a permanent connection;
- whether temporary offline operation is allowed;
- whether a grace period exists;
- which features are available without a check;
- what message the user receives;
- which events are logged;
- how access is restored once the connection returns.

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.

### The mandatory negative test

For every supported version of the project delivery it is necessary to verify the following scenario automatically:

1. create or obtain a finished project;
2. build it successfully with valid access;
3. shut down the Runtime;
4. remove the test token, let it expire, or replace it with an invalid one;
5. confirm that Gabion rejects the licensed operation;
6. perform a clean build of the application without Gabion;
7. run the tests of the project;
8. produce a deployment artifact;
9. start the application;
10. walk through the agreed user scenario;
11. confirm that the application does not contact the license service.

The test passes only when an invalid token blocks Gabion and does not block the project.

### Compromise of the token

If the token has been disclosed:

- the old token is revoked;
- a new token is created with the necessary scope;
- the usage logs are checked;
- the token is removed from the unsuitable location;
- if it reached Git, the whole history is checked;
- the cause of the disclosure is eliminated.

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

### The token and telemetry

A license check must not automatically mean transferring the source code, the business logic, or the client's data.

Before publication it is necessary to document:

- which data is sent during the check;
- the mandatory endpoints;
- the project identifiers;
- the event logs;
- the retention periods;
- the possible subprocessors;
- the ways to disable optional telemetry.

An invalid token means: "Gabion is unavailable." It does not mean: "The client's product is unavailable."

## Production keeps running. Standard development remains possible.

The end of the Gabion license affects the closed development tool, not the delivered project.

Three different questions have to be kept apart:

1. whether the production application keeps running;
2. whether the code can be changed without Gabion;
3. which specific Gabion capabilities become unavailable.

### The production application

#### Without valid access to Gabion, the following keep working

- the frontend of the product;
- the backend of the product;
- user registration and authorization;
- the roles and access rules of the application;
- the business logic;
- the database;
- the background processes;
- the agreed integrations;
- the administrative functions;
- the production deployment;
- user access;
- the client's access to the data;
- the client's monitoring, if it is configured separately;
- backups, if they are configured in the client's infrastructure.

#### The production application must not

- check the Gabion token;
- start the Runtime;
- contact the Gabion MCP;
- load modules from the Pikiner storage;
- contact a Pikiner server in order to execute business logic;
- stop working after the license ends.

### Build and deployment

Without Gabion the following have to remain possible:

- obtaining the project from the client's repository;
- installing the standard dependencies;
- building the Java part;
- building the frontend;
- running the tests of the application;
- applying the project migrations in the manner provided;
- producing a deployment artifact;
- building a container image, if it is part of the project;
- running the application locally;
- deploying to the agreed environment;
- the operation of the client's CI/CD.

The documentation has to contain the necessary commands, with no hidden mandatory step through the Runtime.

### Development with standard tools

After the access ends the team can:

- open the project in an ordinary IDE;
- use a code editor;
- create branches;
- change Java;
- change TypeScript;
- change Thymeleaf;
- change CSS;
- add migrations;
- write and run tests;
- change the configuration;
- perform code review;
- use their own CI;
- release new versions;
- bring in another team.

The client is not obliged to keep the previous architectural process after Gabion ends. They take on responsibility for the quality and compatibility of further changes.

### What becomes unavailable

After the license ends or is revoked, the following may become unavailable:

- the Gabion Runtime;
- the licensed MCP tools and resources;
- the Gabion browser UI;
- the Runtime diagnostics;
- the architectural checks that only Gabion runs;
- integration with AI through the closed Gabion tools;
- updates to the project edition;
- help with Gabion;
- other features expressly stated in the license.

The client does not receive the internal module-storage management functions, either while the project license is in force or after it ends, unless a separate right is granted by another agreement.

### What does not disappear from the project

The end of the license does not remove:

- the source code;
- the code created when modules were applied;
- the business logic;
- the migrations;
- the templates;
- the styles;
- the tests;
- the configuration;
- the project documentation;
- the repository history to the extent transferred;
- the client's data;
- the deployment artifacts that belong to the client.

Gabion must not automatically clean up the project files when the token expires.

### The state matrix

The first eight rows belong to the delivered project and do not change if the license is not renewed. Only the Gabion rows change.

| Capability | Gabion in force | Gabion not renewed |
| --- | --- | --- |
| Operation of the production application | Yes | Yes |
| The client's access to the source code | Yes | Yes |
| The client's access to the data | Yes | Yes |
| Standard build | Yes | Yes |
| Running the project tests | Yes | Yes |
| Producing a deployment artifact | Yes | Yes |
| Development with the ordinary tools of the stack | Yes | Yes |
| Work by another team | Yes | Yes |
| Gabion Runtime | Yes, within the license | No |
| Gabion MCP tools | Yes, within the license | No |
| The Gabion interface | Yes, within the license | No |
| Gabion updates | To the extent provided | No |
| Help with Gabion | To the extent provided | No |
| The internal module storage | No | No |
| The internal module-management CLI | No | No |

### Verifying independence before the handover

Before acceptance of the client project it is necessary to run a clean scenario:

1. obtain the repository being handed over;
2. use an environment with no Gabion installed;
3. provide no token;
4. connect to no internal storage;
5. build the backend and the frontend;
6. run the tests;
7. produce a deployment artifact;
8. start the application;
9. verify the agreed user scenarios;
10. confirm there are no network calls to Gabion.

The result of the check has to be kept as part of the handover material or of the internal release checklist.

### What changes for the team

Without Gabion the team loses the architectural constraints and the diagnostics the tool enforced.

This means that further changes require ordinary engineering discipline:

- understanding the stack;
- code review;
- control of dependencies;
- testing;
- verification of migrations;
- control of architectural boundaries;
- independent version management;
- responsibility for the production release.

This is an acceptable path, not an emergency mode. Gabion has to remain a useful choice, not a technical necessity.

Without Gabion the team loses a Pikiner tool, but not the product, the code, or the right to continue development.

## The human defines the change, the AI works with the code, Gabion enforces verifiable boundaries.

Gabion does not replace the client's team and does not become an autonomous owner of the product.

After the handover, three participants with different responsibilities take part in the work:

1. the client's team;
2. the AI assistant or agent;
3. Gabion.

### The client's team

The team retains product and engineering responsibility.

#### The team

- defines the goal of the change;
- describes the user-facing result;
- explains the business rules;
- decides on ambiguous scenarios;
- provides the necessary context;
- determines the permitted access to data;
- chooses the permitted AI model;
- verifies user-facing behavior;
- assesses the impact on production;
- makes the release decision;
- controls the infrastructure and the secrets;
- is responsible for changes after the handover.

#### Gabion cannot decide on its own

- whether users need a feature;
- whether an ambiguous business rule has been understood correctly;
- whether an organizational risk is acceptable;
- whether a decision complies with the contract or the law;
- whether a change with a known limitation can be released.

### The AI assistant or agent

The AI helps with the technical stack of the project.

#### Within the permitted area it can

- study the structure of the project;
- find the files relevant to the task;
- propose a plan for the change;
- change Java code;
- change TypeScript;
- change Thymeleaf;
- change CSS;
- create or update tests;
- prepare the project migrations;
- explain a diff;
- run the permitted tools;
- respond to the Gabion diagnostics;
- correct the violations detected.

#### The AI does not automatically receive

- the right to make product decisions;
- unrestricted access to the machine;
- access to production secrets;
- the right to send data to an external model;
- the right to bypass human confirmation;
- internal access to the Pikiner module storage;
- the right to publish a production release.

The actual permissions depend on the model chosen, the agent environment, MCP, and the project settings.

### Gabion

Gabion organizes the technical boundary of the work.

#### Within the project license it can

- provide the AI with the permitted context;
- restrict the area of the project;
- provide MCP tools and resources;
- check the structure;
- check the architectural contracts;
- check the manifest to the extent available to the project;
- run deterministic checks;
- display diagnostics;
- explain to the human which rule was violated;
- block a licensed operation that violates a mandatory rule;
- help verify the result reproducibly.

The exact set of actions is determined by the feature matrix of the client license.

#### Gabion must not

- make product decisions;
- change production covertly;
- hold the unique business logic in place of the project;
- be required to serve a user request;
- send data to an external LLM outside a permitted mode;
- present an AI explanation as proof of correctness.

### An ordinary change to the project

For a change that fits within the existing structure and extension points, the process can look like this:

1. The team describes the required behavior.
2. The AI studies the permitted context.
3. Gabion displays the rules and extension points relevant to the task.
4. The AI proposes changes.
5. The human reviews the plan or the diff.
6. The AI changes the project files.
7. Gabion runs the checks provided.
8. The project tests confirm the known scenarios.
9. The team verifies the user-facing result.
10. The team makes a separate decision about deployment.

Successful Gabion checks do not automatically authorize a production release.

### Changing the business logic

The unique business logic is changed inside the client's project.

This does not require creating a shared Pikiner module, if the change:

- applies only to the specific product;
- is not a repeatable part of the production pipeline;
- uses the existing contracts;
- does not require a new shared architectural mechanism.

Such logic is not migrated into the internal module storage.

### If a change requires a new module

The project edition does not provide the client with the internal CLI functions for obtaining or publishing modules in the Pikiner storage on their own.

If a change requires a new or updated shared module, several paths are possible:

1. the team implements the change directly in their project with the standard tools of the stack and takes responsibility for its architecture;
2. the change is implemented through an existing permitted extension point;
3. the client separately agrees with Pikiner on work to create or apply a module.

New Pikiner work after the migration is completed requires a separate SOW with a defined result, price, and date.

Having the first year of Gabion does not mean that Pikiner creates any new modules or features free of charge at the client's request.

### What happens to the existing modules

Code that has already entered the delivered project stays in the project and keeps working.

#### The team can

- read the code that belongs to the project;
- change their project;
- test a change;
- deploy a new version;
- stop using Gabion altogether.

#### Through the project license the team cannot

- browse the whole internal Pikiner catalog;
- download the source templates for other projects;
- update a module from the internal storage;
- publish a module of their own in the storage;
- distribute the internal Pikiner modules.

### The role of the CTO or technical lead

Continuing the work does not require hiring a separate Java team in advance, but technical leadership remains necessary.

The CTO or the designated technical lead controls:

- the boundaries of the tasks;
- the AI's access;
- the quality of changes;
- the test strategy;
- the data migrations;
- the dependencies;
- security;
- the production deployment;
- the response to diagnostics;
- exceptions to the architectural rules.

Gabion reduces the number of decisions that have to be made again each time, but it does not remove engineering responsibility.

### Knowledge transfer

In the first year the team has to learn to perform the full change cycle:

1. state the task;
2. determine the scenarios affected;
3. provide the AI with the minimum necessary context;
4. review the proposed plan;
5. obtain and understand the diff;
6. run the checks;
7. verify the behavior;
8. prepare the release;
9. perform or approve the deployment;
10. diagnose an unsuccessful result.

The transfer counts as practical if the team has made real changes, not only watched a presentation.

### Deep technical questions

If a question requires further verification of the design of the Runtime, 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. comes back to the client with a written explanation.

The written format makes it possible to give a precise and reproducible answer without improvised promises during a meeting.

Gabion helps the team work with the new stack. It does not take away the team's right and duty to understand the result.

## The first year is for mastering the delivered project independently.

Access to the project edition of Gabion is included with the migration not as a temporary demonstration of the technology, but as a period of practical work by the team on the new project.

During this period the team has to go through the full development cycle of real changes: from stating the task to a verified release candidate.

### When the first year starts

The start date of the included period has to be stated expressly in the SOW and in the Gabion license.

It must not:

- be set retroactively;
- begin before working access is provided;
- depend on a hidden internal Pikiner event;
- change without written agreement;
- be conflated with the end date of the migration warranty.

Until the contractual model is approved, this page must not name the signing of the contract, the start of development, acceptance, or the production cutover as a specific trigger.

### What the first year includes

#### The client receives

- the right to use the project edition of Gabion for the delivered project;
- access for the permitted users;
- the features listed in the license matrix;
- the installation documentation;
- the documentation for working with the project;
- the Runtime updates provided;
- the check updates provided;
- a channel for questions about using Gabion;
- help to the extent expressly stated in the license;
- notice that the end of the period is approaching;
- a renewal offer, if renewal is available.

#### The first year does not automatically include

- continuous development by Pikiner;
- new product features;
- the creation of any new modules on request;
- changes to the internal storage;
- production monitoring;
- on-call;
- an SLA;
- administration of the client's infrastructure;
- unlimited consulting;
- unlimited training of new employees;
- support for third-party changes to the project;
- restoration of the architecture after arbitrary changes made outside Gabion.

### The initial handover

At the start of the period the team receives:

- an installation package or the installation method provided for the Runtime;
- the license token;
- the system requirements;
- the list of permitted users;
- access to the project;
- the instructions for running locally;
- the build instructions;
- the test commands;
- a description of the main directories;
- a description of the extension points;
- a list of the available Gabion features;
- a list of the limits;
- a channel for questions;
- the end date of the period.

The handover counts as complete only after verifying that an authorized member of the client team can:

- obtain the project;
- run it locally;
- perform a standard build;
- run the tests;
- start Gabion;
- open the permitted project;
- run a check provided;
- see the diagnostics.

### Practical stages of the first year

1. #### 1. Orientation

   The team has to understand:

     - the structure of the application;
     - the boundaries of the frontend and the backend;
     - where the business logic is located;
     - the data schema;
     - the migrations;
     - the integrations;
     - the configuration;
     - the tests;
     - the extension points;
     - the role of Gabion.

   The result of the stage: a team member can find the code of a specific user journey and explain how it is executed.
2. #### 2. The first small change

   The team makes a limited change that does not touch a new shared module.

   It goes through:

     1. stating the task;
     2. finding the files affected;
     3. working with the AI;
     4. reviewing the diff;
     5. running the Gabion checks;
     6. running the tests;
     7. verifying the result manually;
     8. preparing a release candidate.

   The goal of the stage: to confirm that the process works outside a Pikiner demonstration as well.
3. #### 3. A change to the business logic

   The team makes a real change to the unique logic of the product inside the client project.

   It has to confirm that:

     - the unique logic stays in the project;
     - the existing contracts are not violated;
     - a migration was added when the schema changed;
     - the tests describe the expected behavior;
     - the diagnostics are clear;
     - the release decision is made by a human.
4. #### 4. An unsuccessful scenario

   The team encounters a violation that Gabion detects, either deliberately or on a real task.

   A team member has to be able to:

     - read the diagnostics;
     - identify the rule affected;
     - distinguish an AI error from a project constraint;
     - correct the change;
     - run the check again;
     - confirm a successful result.
5. #### 5. An independent release cycle

   Without step-by-step guidance from Pikiner, the team performs:

     - the change;
     - code review;
     - testing;
     - producing a deployment artifact;
     - verification in the agreed non-production environment;
     - preparation of the decision on the production deployment.

   The actual production deployment is performed in accordance with the responsibility fixed in the SOW and in the client's operational process.

### Who has to go through the practical cycle

The recommended minimum group:

- the CTO or technical lead;
- a team member responsible for the product logic;
- a team member who will work with the AI and the code;
- a team member responsible for the release or the infrastructure, if that is a separate role.

One person can combine several roles.

Access to Gabion does not remove the need to appoint an owner of technical decisions on the client side.

### Help with Gabion

Help in the first year applies to the use of Gabion and of the delivered project within the terms of the license.

#### It may include

- questions about installation;
- questions about the token;
- an explanation of the diagnostics;
- clarification of the process provided;
- a report of a reproducible Runtime error;
- questions about a documented feature.

#### It does not automatically include

- the implementation of a new feature;
- code review of any change the client makes;
- fixing third-party code;
- restoring production;
- incident investigation;
- changes to the infrastructure;
- new module development;
- continuous technical maintenance.

Before publication it is necessary to determine:

- the channel;
- the working hours;
- the permitted scope;
- the response time, if one is promised;
- the escalation rules;
- the boundary between a question about Gabion and new billable work.

If no SLA is approved, a specific response time must not be promised.

### Updates in the first year

The license has to determine:

- which Runtime updates are included;
- which security updates are included;
- which compatibility updates are included;
- whether the client receives new checks;
- how a change is communicated;
- whether action by the team is required;
- whether the project changes;
- whether an update can be declined;
- whether the previous version is supported;
- who is responsible for applying the change to the project.

An update to the Runtime must not automatically change the production application.

An update to an internal Pikiner module must not automatically change the delivered project.

### Tracking progress

The first year must not turn into a mandatory program with reporting to Pikiner.

But it is useful for the client to keep an internal checklist:

- Gabion is installed for at least the agreed team members;
- the access rights are verified;
- the documentation has been read;
- a clean build has been performed;
- the first change is complete;
- a failed check has been reproduced;
- the diagnostics are clear;
- an independent release cycle has been completed;
- the fallback process without Gabion is known;
- an owner of the renewal decision has been appointed.

### Notice of the end of the period

Before the period ends the client receives:

- the exact date;
- a list of the features that will stop;
- confirmation that production will keep running;
- instructions for continuing without Gabion;
- the available renewal options;
- the price, if it has been approved;
- the deadline for the decision;
- the procedure for replacing or terminating the token;
- information on the compatibility of the current project with the version offered.

The specific minimum notice period has to be established by the license.

### What has to be known from day one

The client must not discover at the end of the year:

- that the token restricts more features than were described;
- that the build unexpectedly requires the Runtime;
- that the documentation is unavailable without a license;
- that a subscription is needed to keep production running;
- that a standard change is impossible without the internal storage;
- that help was never included, although the marketing created a different impression;
- that the renewal price is determined only after access has been switched off.

The purpose of the first year is not to keep the client inside Gabion, but to give the team a practical way to develop the new project and to decide, with full information, whether renewal is useful.

## Renewal is an informed choice, not a condition for the product to work.

Before the first year ends, the client has to receive enough information to compare two normal scenarios:

1. continue using Gabion;
2. continue development without Gabion.

Declining to renew is not treated as a technical error, a defect in the project, or a waiver of the right to the delivered result.

### The renewal offer

If renewal is available, Pikiner communicates in advance:

- the end date of the current period;
- the edition of Gabion available for renewal;
- the features of the next period;
- the supported versions of the production pipeline;
- the number of permitted users;
- the included updates;
- the scope of help;
- the limits;
- the price;
- the payment period;
- the token rules;
- the deadline for the decision;
- the changes compared with the current terms.

Renewal must not be described by a price alone, without a list of the features and the limits.

The specific minimum notice period has to be established by the license.

### Renewal only by an explicit decision

Renewal must not happen automatically unless the automatic renewal mechanism, the charge date, and the cancellation procedure have been agreed separately and clearly.

The preferred process for the project edition:

1. Pikiner sends the terms of the next period.
2. The client confirms the option chosen.
3. The parties execute the necessary documents.
4. Payment is made on the agreed terms.
5. Access continues without interruption, if the decision is made in time.

The absence of a reply from the client must not by itself create a new commercial obligation, unless the contract expressly establishes another agreed mechanism.

### If the client renews the access

The team continues to use the features listed in the new license.

#### Renewal can preserve

- access to the Runtime;
- the MCP tools and resources;
- the architectural checks;
- the human interface;
- the AI integrations;
- the diagnostics;
- the updates provided;
- help with Gabion to the scope stated.

#### Renewal does not automatically provide

- the internal module storage;
- the Pikiner module-management CLI;
- the right to create new independent projects;
- new product features;
- production support;
- monitoring;
- on-call;
- an SLA;
- unlimited work by the Pikiner team.

### If the client does not renew the access

#### After the period ends

- the Gabion Runtime can stop the licensed operations;
- the Gabion MCP tools become unavailable;
- the Gabion interface becomes unavailable;
- Gabion updates stop;
- help with Gabion stops.

#### At the same time

- the production application keeps running;
- the project stays with the client;
- the source code remains available;
- the data stays under the client's control;
- the standard build remains possible;
- the project tests remain available;
- deployment remains possible;
- another team can continue development;
- the client is not obliged to enter into a new contract with Pikiner.

### Before the access is switched off

Before the scheduled end of the period the client has to be able to:

- obtain a current copy of their project;
- obtain the project documentation;
- keep the standard build instructions;
- keep the list of environment variables without secrets;
- perform a clean build without Gabion;
- confirm access to their own repositories;
- check the owners of the production accounts;
- receive an explanation of the consequences of not renewing;
- remove the token after the access ends.

The material necessary for the standard build and operation of the delivered application must not become unavailable merely because the Gabion license has ended.

### If the decision has not been made yet

If the license period ends and the client has not made a decision, the procedure established by the license applies.

Until such a procedure is approved, the following must not be promised:

- an automatic grace period;
- continued Runtime operation without payment;
- the retention of updates;
- the retention of help;
- automatic renewal.

Whatever the commercial decision, the production application keeps running.

### If the access was interrupted by a technical error

If a valid license is supposed to work but the Runtime rejects the token because of a reproducible Gabion error, this is treated as a problem with the licensed tool.

The team has to have:

- a channel for reporting the error;
- a license identifier that does not require sending the full token;
- clear diagnostics;
- a safe way to replace the token;
- instructions for continuing to work with the code without the Runtime.

A technical error in Gabion does not turn a problem with the tool into a stoppage of the production application.

### Reconnecting later

The client can ask to have access restored after a break.

However, an old version of the project is not automatically considered compatible with a future version of Gabion.

Before reconnecting it may be necessary to check:

- the current stack of the project;
- the changes made after Gabion ended;
- the directory structure;
- the dependencies;
- the migrations;
- the architectural boundaries;
- the compatibility of the manifest;
- the state of the code created by another team;
- the supported version of the Runtime;
- whether the necessary changes can be applied safely.

The check can result in:

- access being restored without changing the project;
- the need to update the project;
- a separate proposal for compatibility or for migrating the pipeline;
- technical impossibility of connecting the current state of the project.

Pikiner must not promise in advance that access will be restored automatically for any future version of the project.

If separate Pikiner work is required, its result, price, and date are agreed before it starts, through a separate SOW.

### No hidden penalty for not renewing

Pikiner must not:

- degrade code that has already been delivered;
- delete project files;
- recall data;
- shut down production;
- block the client's repository;
- obstruct the work of another team;
- revoke rights granted earlier;
- require deployment artifacts to be deleted;
- change the application remotely.

The commercial reason to renew Gabion has to be the usefulness of the tool, not an artificial inability of the project to work without it.

### What the client compares when deciding

When making the decision it is useful to assess:

- whether the team uses the Gabion checks;
- whether the diagnostics help find real errors;
- whether the tool reduces the difficulty of working with the new stack;
- whether the MCP tools are used;
- how often the team changes the project;
- whether access to updates is needed;
- whether the help channel provided is needed;
- whether the team is able to perform a full release cycle without Gabion;
- whether the architecture of the project changed during the first year;
- whether the price matches the value received.

Renewal preserves access to the tool. Not renewing preserves the product and ends only the use of Gabion.

## Access to Gabion does not mean the project is automatically sent to an external LLM.

Gabion is built to work with AI assistants and agents, but it must not impose a single method of data processing.

For every client project, the permitted models, the permitted context, the external providers, and the costs are determined separately.

### Choosing an AI model

Depending on the actual compatibility, Gabion can work:

- with an external cloud model;
- with several permitted providers;
- with a model in the client's account;
- with a model running locally;
- without sending a particular task to an external model;
- with different models for different classes of task.

The technical ability to connect a model does not mean it is automatically permitted for the client's material.

For the project it is necessary to determine:

- which models are supported;
- which models the client permits;
- who creates the provider account;
- who accepts the provider's terms;
- who pays for the usage;
- which limits apply to the data;
- which Gabion features are available with the model chosen;
- whether the model can be replaced without changing the project.

### An external cloud model

Before an external provider is used, the parties determine:

- which material may be sent to it;
- whether source code may be sent;
- whether logs may be sent;
- whether the data schema may be sent;
- whether the contents of the database may be sent;
- whether personal data may be sent;
- whether secrets may be sent;
- where the material is processed;
- how long it is retained;
- whether it is used for training;
- which data-control settings are available;
- which subprocessors are involved;
- which logs are kept.

If a provider does not meet the client's mandatory requirements, its model is not used for the material concerned.

### A local model

A local model can reduce the volume of data sent to an external provider, but it does not automatically eliminate every risk.

It is necessary to verify:

- the actual compatibility with Gabion;
- the computing resources required;
- the supported interaction format;
- the quality of task execution;
- the size of the context window;
- the speed;
- the update requirements;
- the logging;
- access by other users of the machine;
- how the model is stored;
- the network connections of the runtime used.

Running locally does not make a weak model equivalent to a stronger cloud model.

The Gabion architectural checks reduce the impact of some AI errors, but they do not guarantee the same result from every model.

### Quantized models

A quantized model can be used if it is compatible with the scenario chosen and shows sufficient quality on real tasks from the project.

Before it is used, it is necessary to verify:

- its understanding of the project structure;
- its ability to perform multi-file changes;
- its adherence to instructions;
- its work with Java and TypeScript;
- the quality of its migrations;
- its response to diagnostics;
- the stability of its tool calls;
- the frequency of erroneous changes;
- its memory requirements;
- its speed.

Support must not be promised for any local or quantized model merely because it offers a compatible API.

### The minimum necessary context

The AI has to receive only the context necessary for the specific task.

#### The context may include

- the files relevant to the task;
- the permitted contracts;
- the structure of the project;
- the diagnostics;
- the tests;
- a technical description of the scenario;
- anonymized data samples.

#### The following should not be sent unless necessary

- the whole repository;
- the whole database;
- production secrets;
- personal data;
- financial documents;
- internal correspondence;
- credentials;
- files from other projects;
- the internal Pikiner module storage.

MCP and the agent environment have to restrict the area of access in accordance with the task and the project settings.

### The client's source code

The project code is used only for work on that project, within the agreed process.

Pikiner must not:

- migrate unique code into another client project;
- publish the client's code;
- use it in the public Showcase;
- add it to the internal module storage;
- send it to an external provider outside a permitted mode;
- use it to train a shared model without a separate, explicit agreement.

The terms of code processing have to match across the contract, the Privacy Policy, the DPA, and the settings of the providers used.

### The client's data

For development it is preferable to use:

- synthetic data sets;
- anonymized data;
- minimal samples;
- test accounts;
- a separate test environment.

Production data is used only where necessary and in the agreed volume.

Before data is transferred, the following are determined:

- the purpose;
- the contents;
- the storage location;
- the permitted recipients;
- the permitted models;
- the retention period;
- the deletion method;
- the logging requirements;
- whether a DPA is required.

Secrets are not considered permissible AI context.

### Shared Pikiner modules

When a shared module is created from a solution that a client project needed, Pikiner has to separate the reusable technical mechanism from the client's material.

The following must not be migrated into a module:

- the client's data;
- the client's name;
- the name of the product;
- unique business logic;
- confidential calculations;
- secrets;
- internal identifiers;
- client documents;
- fragments of the client's old code;
- test data that makes the client identifiable.

Only an anonymized shared component enters the Pikiner storage.

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

### The cost of models and external services

The price of the migration and of the Gabion license must not automatically include unlimited third-party provider costs.

The following can be separate costs:

- external LLM tokens;
- compute for a local model;
- GPU;
- storage;
- paid APIs;
- external embeddings;
- model hosting;
- third-party observability;
- other licenses.

Before use begins it has to be clear:

- who creates the account;
- who receives the invoice;
- which limits are set;
- whether a budget cap can be set;
- who has the right to change a limit;
- which notifications are available;
- what happens when the budget is exhausted.

Where possible, third-party accounts are registered to the client.

### Cost control

For a supported integration it is useful to display:

- the model chosen;
- the number of requests;
- the measured usage;
- the estimated cost;
- the limit set;
- provider errors;
- switching the model, if that is permitted.

An exact monetary calculation must not be promised if the provider does not supply sufficient data or changes prices independently of Pikiner.

### Gabion Live Showcase recordings

A Gabion Live Showcase uses a prepared Pikiner project, not the client's product.

Without separate written permission, a demonstration must not include:

- the client's screen;
- the client's code;
- the client's data;
- the client's name;
- architecture that makes the client identifiable;
- a recording of the first meeting;
- questions that disclose confidential information.

### What has to be fixed before the work starts

A clear matrix has to exist for the project:

This is a project decision form, not a list of settings Gabion ships with.

| Question | Project decision |
| --- | --- |
| Permitted models | Specify |
| External providers | Specify |
| Whether code may be sent | Yes / no / with restrictions |
| Whether user data is permitted | Yes / no / with restrictions |
| Whether a local model is required | Specify |
| Who owns the accounts | Specify |
| Who pays for the usage | Specify |
| Spending limit | Specify |
| Retention period | Specify |
| Whether a DPA is required | Specify |
| Whether logging is permitted | Specify |
| Deletion procedure | Specify |

This matrix is a project decision, not a universal Gabion setting for all clients.

Gabion manages the technical process. The client determines which models and which data are permitted to take part in it.

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

## Short answers

### [What exactly belongs to the client?](https://gabion.dev/for-pikiner-clients#g5-qa-client-owns)

Everything in the directory of the delivered project belongs to the client on the terms of the contract: the source code, the business logic, the configuration, the migrations, the tests, the templates, the styles, and the project documentation.

### [What remains the property of Pikiner?](https://gabion.dev/for-pikiner-clients#g5-qa-pikiner-owns)

The Gabion Runtime, the internal module storage, the internal module-management CLI, the production tools, and the source anonymized module templates outside the client's project.

### [Where is the client's project located?](https://gabion.dev/for-pikiner-clients#g5-qa-project-location)

In a separate directory created for the specific application. The Gabion Runtime and the internal storage are outside that directory.

### [What is a Gabion module?](https://gabion.dev/for-pikiner-clients#g5-qa-what-is-module)

It is an anonymized vertical unit of implementation. It can include a Java backend, a TypeScript frontend, Thymeleaf, CSS, a page, configuration, and Flyway migrations.

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

### [Who owns the code created from a module?](https://gabion.dev/for-pikiner-clients#g5-qa-module-code-ownership)

Everything in the directory of the delivered project belongs to the client. Pikiner retains the rights to the source anonymized module template, which is outside the client's project.

### [Can a module contain our unique business logic?](https://gabion.dev/for-pikiner-clients#g5-qa-module-business-logic)

A reusable Pikiner module must not contain the unique business logic, the data, the secrets, the name, or the source code of the client's old product. The unique implementation stays in the client's project.

### [Can we add and remove modules from the Pikiner storage ourselves?](https://gabion.dev/for-pikiner-clients#g5-qa-module-management)

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

### [Can the project be changed without the module-management CLI?](https://gabion.dev/for-pikiner-clients#g5-qa-change-without-cli)

Yes. The client can change their code with the standard tools of Java, Spring, PostgreSQL, TypeScript, and the other components of the delivered stack.

### [Can Gabion be used for another product?](https://gabion.dev/for-pikiner-clients#g5-qa-another-product)

Not by default. The project edition is intended for the application delivered as part of a Pikiner migration. Creating a new independent project requires a different access model, if one becomes available.

### [Can the internal Gabion modules be copied into other projects?](https://gabion.dev/for-pikiner-clients#g5-qa-copy-modules)

No, unless that right is expressly granted by a separate license. The client receives their project, but not the internal storage and not the source Pikiner module templates.

### [Does the client receive the source code of the Gabion Runtime?](https://gabion.dev/for-pikiner-clients#g5-qa-runtime-source)

No. The client receives licensed access to the closed Runtime and the source code of their own application.

### [Is the Runtime part of the production application?](https://gabion.dev/for-pikiner-clients#g5-qa-runtime-in-production)

No. The Runtime is used during development and sits outside the production dependency graph of the project.

### [Does the production application need a connection to Gabion?](https://gabion.dev/for-pikiner-clients#g5-qa-production-connection)

No. User requests, the backend, the frontend, the database, and the integrations of the application all work without a connection to Gabion.

### [What does the token control?](https://gabion.dev/for-pikiner-clients#g5-qa-token-controls)

The token controls access to the licensed Gabion features: the Runtime, the MCP tools, the interface, and the other capabilities listed in the license.

### [Can an expired token stop the product?](https://gabion.dev/for-pikiner-clients#g5-qa-expired-token)

No. An invalid token can block Gabion, but not the standard build, the deployment, or the operation of the production application.

### [Can we work with the application code without Gabion?](https://gabion.dev/for-pikiner-clients#g5-qa-work-without-gabion)

Yes. The delivered project has to build, test, deploy, and change with the standard tools of the agreed stack.

### [Can the project be handed to another team?](https://gabion.dev/for-pikiner-clients#g5-qa-another-team)

Yes. Further development requires neither permission from Pikiner nor a valid Gabion license.

### [Do we have to hire Java developers immediately after the migration?](https://gabion.dev/for-pikiner-clients#g5-qa-hiring-java)

Not necessarily. Gabion and the AI help the existing team work with the new stack.

But the client still needs a person responsible for technical decisions, checks, and production releases.

### [Who makes the product decisions?](https://gabion.dev/for-pikiner-clients#g5-qa-product-decisions)

The client's team. The AI proposes and implements changes, Gabion checks the rules that have been expressed, but the meaning of a feature and the release decision are determined by a human.

### [Can the AI release a change to production on its own?](https://gabion.dev/for-pikiner-clients#g5-qa-ai-release)

It must not by default. A successful check does not replace the deployment decision of an authorized person.

### [What if a change requires a new module?](https://gabion.dev/for-pikiner-clients#g5-qa-new-module-needed)

The team can implement a specific change inside their project, use an existing extension point, or agree separately with Pikiner on creating or applying a shared module.

### [Does the creation of new modules come with the first year?](https://gabion.dev/for-pikiner-clients#g5-qa-new-modules-first-year)

No, not automatically. The first year provides access to the project edition of Gabion.

New Pikiner development requires a separate SOW, unless it concerns correcting the obligations of a project already in force.

### [When does the first year start?](https://gabion.dev/for-pikiner-clients#g5-qa-first-year-start)

The exact date is stated in the SOW and the license. The period must not be spent before the client is given working access to the project edition of Gabion.

### [What does the first year include?](https://gabion.dev/for-pikiner-clients#g5-qa-first-year-scope)

Runtime features, MCP, checks, the interface, updates, and help, only to the extent expressly listed in the client license.

### [Is unlimited support included?](https://gabion.dev/for-pikiner-clients#g5-qa-unlimited-support)

No. The first year does not mean monitoring, on-call, an SLA, unlimited consulting, or continuous development by Pikiner.

### [What happens after the first year?](https://gabion.dev/for-pikiner-clients#g5-qa-after-first-year)

The client chooses: renew Gabion or continue development without it. In both cases the production application and the project stay with the client.

### [Does renewal happen automatically?](https://gabion.dev/for-pikiner-clients#g5-qa-automatic-renewal)

Only if a transparent automatic renewal mechanism has been agreed separately. Explicit confirmation of the terms of the next period by the client is preferred.

### [What happens if we do not renew the access?](https://gabion.dev/for-pikiner-clients#g5-qa-no-renewal)

The licensed Gabion features become unavailable. The code, the data, the build, the deployment, and the production application keep working.

### [Can access be restored later?](https://gabion.dev/for-pikiner-clients#g5-qa-late-reconnection)

You can approach Pikiner, but automatic compatibility is not guaranteed. The changes to the project and the compatibility with the current version of Gabion have to be checked first.

### [Can reconnecting require a separate payment?](https://gabion.dev/for-pikiner-clients#g5-qa-reconnection-cost)

Yes, if compatibility requires separate work on the project. The result, the price, and the date of that work are agreed before it starts.

### [Can an external LLM be used?](https://gabion.dev/for-pikiner-clients#g5-qa-external-llm)

Yes, if the provider and the processing mode are permitted for the project. The technical compatibility of a model does not replace agreement on the data.

### [Can a local model be used?](https://gabion.dev/for-pikiner-clients#g5-qa-local-model)

Yes, if it is compatible with Gabion and shows sufficient quality on real tasks from the project. Running locally does not make all models the same.

### [Will the code be sent to an external model automatically?](https://gabion.dev/for-pikiner-clients#g5-qa-code-to-model)

It must not be. The permitted context and the permitted providers are determined for each project.

### [Can Pikiner use our code for a shared module?](https://gabion.dev/for-pikiner-clients#g5-qa-code-in-shared-module)

No. Only an anonymized reusable component can enter the shared storage, without the client's data, secrets, or unique logic.

### [Who pays for the external LLM?](https://gabion.dev/for-pikiner-clients#g5-qa-llm-payer)

That is determined by the project terms. Third-party LLMs, APIs, compute, and licenses are not automatically included in the price of the migration or of Gabion.

### [What happens to the data after the token ends?](https://gabion.dev/for-pikiner-clients#g5-qa-data-after-token)

It stays under the client's control. The Gabion token does not manage the database or the client's access to the production environment.

### [Can independence be verified before the handover?](https://gabion.dev/for-pikiner-clients#g5-qa-independence-test)

Yes. The project has to pass a clean build, the tests, the production of a deployment artifact, and startup without the Runtime, the token, and the internal module storage.

### [Is the first meeting a demonstration of Gabion?](https://gabion.dev/for-pikiner-clients#g5-qa-first-meeting)

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

For a suitable project, a separate Gabion Live Showcase is held, where Pikiner demonstrates the technology.

### [Who runs the Gabion Live Showcase?](https://gabion.dev/for-pikiner-clients#g5-qa-showcase-host)

The demonstration and the technical conversation are run by the Pikiner team.

Deep questions about the engines and the internal processes are recorded and receive a written answer after they have been checked with the author of the Runtime.

### [Does the author of Gabion attend a public meeting?](https://gabion.dev/for-pikiner-clients#g5-qa-gabion-author)

That is not required. The technical demonstration is run by the Pikiner team, and complex internal questions can be addressed in writing after the meeting.

## Choose the path that matches your task.

### If you are considering migrating a working product

The first step is to demonstrate the existing product to the Pikiner team.

At the free meeting the client demonstrates:

- the main user roles;
- the administrative journeys;
- the business logic;
- the data;
- the integrations;
- the known limitations;
- the current stack;
- the deployment model;
- the main reason for the migration.

The first meeting does not require:

- handing over the whole repository;
- providing production access;
- conducting a technical audit;
- preparing full documentation;
- disclosing secrets;
- ordering a paid discovery.

If a technical incompatibility with the production pipeline becomes clear, Pikiner reports it immediately and explains the specific 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.

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

### If you want to understand the technical design of Gabion

The technology page explains:

- the coherent stack;
- the separation of the Runtime and the project;
- the design of the modules;
- `gabion.manifest.json`;
- the architectural contracts;
- MCP;
- the checks;
- the clean production build;
- updates to the production pipeline.

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

### If you are interested in models and data

A separate page explains:

- external and local models;
- the transfer of context;
- work with the code;
- the limits on data;
- third-party costs;
- control of usage.

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

### If the independence of the delivered product matters

The legal and commercial boundaries are described on the Pikiner site:

- ownership of the project;
- rights to the data;
- the Pikiner modules;
- the Gabion license;
- the first year;
- non-renewal;
- handover to another team.

[Contract, IP, and Independence](https://pikiner.com/independence)

### If you need standalone access to Gabion

Gabion is not yet distributed as an open standalone product for any project.

The current and planned access models are described separately.

### If the project is a preliminary fit

For the CTO or the technical team, Pikiner can hold a separate, free Gabion Live Showcase.

At this meeting the Pikiner team demonstrates:

- a separate project directory;
- the Runtime in operation;
- the interaction with the AI;
- a real architectural error;
- the diagnostics;
- the correction;
- the repeated check;
- an independent build of the application.

A Gabion Live Showcase is not the first meeting and is not available as automatic open booking for any visitor.

First the client demonstrates their working product to Pikiner. Once preliminary applicability is confirmed, Pikiner separately offers the technical Showcase.

First the client demonstrates their product to Pikiner. Then Pikiner can separately demonstrate Gabion to a suitable client.

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

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