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.

• 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

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.

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 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.

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

Distribution limits

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 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."

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

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

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.

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 AI assistant or agent

The AI helps with the technical stack of the project.

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.

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 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.

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 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.

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.

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.

If the client does not renew the access

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.

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.

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 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