Contract, intellectual property, and project handover

Your product stays yours.

A migration should not replace architectural debt with dependence on a new contractor.

The client receives a working system and the product code required to operate and develop it independently. Gabion remains the technology of Pikiner, but the application does not require active access to Gabion in order to build, deploy, and serve its users.

Rights, licenses, the handover contents, and the terms of access are recorded in writing before the work begins.

The contract and the structure of the handover separate three objects: the individual project of the client, the anonymized reusable modules of Pikiner, and the Gabion development environment.

That separation makes it possible to hand the product to the client without leaving the production system dependent on Pikiner, and at the same time not to move the internal production pipeline of the company into a single client project.

The project of the client

The Pikiner team creates a separate project for the client. Gabion initializes it with a command of the form gabion init my-project.

That project sits in its own directory and contains the implementation of the client's specific product.

The project of the client comprises:

• the application source code;
• the unique business logic of the client;
• the user and administrative journeys;
• the roles and access rules;
• the database structure;
• the data migrations of the project;
• the frontend and backend of the specific application;
• the templates, styles, and configuration of the project;
• the implemented integrations;
• the tests and documentation created for the project;
• every other file located in the directory of the handed-over project.

The entire content of the client's project directory belongs to the client on the handover terms fixed by the contract.

The client does not receive a right to run a Pikiner application temporarily. The client receives their own project, which can be built, deployed, studied, and developed independently of any further involvement by Pikiner.

The anonymized modules of Pikiner

A Gabion module is a reusable unit of implementation from which the production pipeline assembles parts of a project.

A module may include:

• a Java backend;
• a TypeScript frontend;
• Thymeleaf templates and sections;
• CSS;
• a page or a complete part of a user journey;
• configuration;
• Flyway migrations;
• checks and the other elements a vertical function requires.

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

Modules interact through Gabion contracts and must not create direct unmanaged dependencies on one another.

If an existing module is not sufficient to implement a client project, Pikiner may create a new one. Such a module is developed outside the client's project directory, as an anonymized reusable component.

A Pikiner module must not contain:

• data of the client;
• secrets and access credentials of the client;
• source code of the client's old product;
• names that make it possible to link the module to a given client;
• unique business logic belonging to the client;
• confidential rules or materials of the client.

The anonymized source template of such a module, and its further development in the module storage, belong to Pikiner.

The code, the configuration, and the specific logic located in the directory of the client's assembled project are part of that project and belong to the client.

Pikiner owns the reusable production template. The client owns their project, assembled with its use.

Gabion Runtime and the module storage

Gabion Runtime and the internal module storage are located outside the client's project directory.

The technology of Pikiner comprises:

• Gabion Runtime;
• the internal module storage;
• the mechanism for installing and updating modules;
• the internal CLI commands for adding, removing, and replacing modules;
• the architectural contracts;
• the deterministic checks;
• the production tools of Pikiner;
• subsequent versions and the general development of Gabion.

These elements remain the intellectual property of Pikiner and are not handed over together with a single client project.

The client is not given direct access to the whole internal module storage, nor to the CLI functions intended for the Pikiner production pipeline.

That restriction applies to the tools for creating and changing a project, not to the right of the client to the application already handed over.

Access to the project edition of Gabion

Access to Gabion means the right to use the tool for the further development of the handed-over project, on the agreed terms.

It does not mean handing the client:

• the source code of Gabion Runtime;
• the internal module storage of Pikiner;
• the right to create an unlimited number of new projects;
• the internal functions for managing the production pipeline.

At the same time, ending or not renewing access to Gabion:

• does not revoke the project code of the client;
• does not change the ownership of the project;
• does not block the build of the application;
• does not switch off the production system;
• does not restrict the access of the client to their data;
• does not prohibit handing further development to another team.

Gabion helps create and develop the project, but does not become the owner of the project and is not a condition of the production application running.

Gabion helps a human and an AI build and change the system: it sets the architectural boundaries, provides agreed components, and verifies critical decisions.

It does not become a mandatory intermediary between the application and its users. A production system does not have to contact Gabion to process ordinary user requests, to check that a subscription is valid, or to obtain access to the data of the client.

After handover, the application:

• builds as a standard project on the agreed stack;
• deploys to the infrastructure defined for the project;
• connects to its own database and external integrations;
• continues to serve users without an active Gabion session;
• does not stop working when access to the development tool ends;
• does not lose code, data, or implemented functionality if access is not renewed.

A Gabion token opens the development tool. It does not switch the application of the client on or off.

Technical Explanation of Application Independence

The result of the migration is handed over as a separate project of the client. The mandatory part of the handover does not depend on whether the team renews access to Gabion or continues development another way.

Additional operational materials, infrastructure, and launch activities are included only when the SOW states them explicitly.

The mandatory part of the handover

The client receives:

• a separate project directory;
• a repository with the application source code;
• an implementation of the agreed user and administrative journeys;
• the unique business logic of the product;
• the frontend and backend of the application;
• the database structure;
• the Flyway migrations belonging to the project;
• the roles and access rules;
• the agreed external integrations;
• the build configuration;
• the automated tests and checks provided by the production pipeline;
• a list of the required environment variables, without secrets in the documentation;
• instructions for running the project locally;
• the runtime environment requirements;
• the deployment configurations required for the agreed deployment method;
• a list of third-party dependencies and applicable licenses;
• project and operational documentation within the agreed scope;
• access to the project edition of Gabion for the first year, on the terms of the client license.

The handed-over result is deployment-ready: the project can be built, verified, and deployed in the described environment without an active connection to Gabion.

What is handed over only if the SOW includes it

Depending on the product, the SOW may separately include:

• creating cloud infrastructure;
• setting up the production environment;
• the actual production deployment;
• configuring DNS and certificates;
• configuring CI/CD in the infrastructure of the client;
• configuring monitoring and alerting;
• preparing and carrying out the migration of production data;
• cleaning and transforming data;
• a trial data migration;
• verifying the completeness and correctness of the migration;
• preparing the cutover;
• an agreed window of restricted operation;
• switching users over;
• preparing and verifying the rollback;
• additional operational instructions;
• training or separate knowledge-transfer sessions beyond the standard project handover.

If an item is not stated in the SOW, it is not considered included merely because the infrastructure of a particular client may require it.

Production accounts and external services

Wherever possible, the following are registered to the client from the outset:

• cloud accounts;
• domains and DNS;
• certificates;
• payment systems;
• mail and communication services;
• data providers;
• external APIs;
• monitoring systems;
• other production services.

Pikiner receives separate limited access, only to the extent the SOW requires.

Before the project is handed over, the parties record:

• which accounts belong to the client;
• which access rights were granted to Pikiner;
• where the production secrets are held;
• who is responsible for rotating them;
• when the temporary access of Pikiner has to be revoked;
• who performs the actual switchover of users.

Secrets must not be stored in the source code, in the documentation, or in the history of the repository.

Rights to the handed-over project

The entire content of the handed-over project directory belongs to the client under the terms of the contract, including:

• the source code;
• the configuration;
• the unique business logic;
• the data and the data structure;
• the code generated or included when the project was assembled from modules;
• the tests;
• the migrations;
• the templates;
• the styles;
• the project documentation.

The presence in the project of code produced with Gabion modules does not give Pikiner the right to control the handed-over application, and does not create a subscription that its operation depends on.

Pikiner retains rights only to Gabion Runtime, the internal module storage, the production tools, and the anonymized source templates, all of which are located outside the client's project directory.

The independence check before handover

Before the project is completed, the version being handed over has to be verified without an active dependency on Gabion.

The check has to confirm that the project:

• is available to the client in the full agreed composition;
• builds without a connection to the internal module storage of Pikiner;
• starts in the described environment;
• performs the agreed scenarios;
• does not require a valid Gabion token for production operation;
• does not contact Gabion in order to serve users;
• does not lose production functionality when access to Gabion ends;
• can be handed to another team for further development.

The client receives a self-contained project, not the right to use an application that remains under the control of Pikiner.

Together with the migrated product, the client team receives access to the project edition of Gabion for the first year.

The project edition is intended for continuing the development of the specific application that was handed over. It works with the client's separate project directory and does not transfer control over Gabion Runtime or the internal module storage of Pikiner.

What the project edition allows

Within the terms of the client license, the team can:

• work with the handed-over project;
• set tasks for an AI assistant or agent;
• change the business logic and the interface of the application;
• use the architectural contracts of Gabion;
• run the checks the framework provides;
• build and test the project;
• continue developing the product after the migration;
• receive the Gabion updates the license provides for.

The specific set of functions, updates, and assistance is fixed in the terms of access.

What stays inside the production pipeline of Pikiner

The project edition does not provide:

• the source code of Gabion Runtime;
• direct access to the internal module storage of Pikiner;
• the internal CLI functions for installing, removing, and replacing modules from that storage;
• the right to distribute, resell, or modify Gabion;
• the right to create an unlimited number of independent projects;
• access to anonymized modules that are not part of the handed-over project;
• perpetual updates and assistance without a separate agreement.

The Pikiner team uses the internal module management functions while the project is in production. The client receives the result of applying them in their own project directory, but not the internal storage itself, and not the production mechanism that manages it.

What revocable access means

Access to the project edition of Gabion may be controlled by a license or by a revocable token.

That mechanism governs only the right to use Gabion as a development tool. It does not govern the application of the client, and it cannot:

• stop the production system;
• block the build of a project already handed over;
• delete or change the code of the client;
• restrict the access of the client to their data;
• revoke ownership of what the project directory contains;
• prevent another team from continuing development without Gabion.

The boundary of ownership

Restricting access to Gabion restricts the use of a Pikiner tool. It does not restrict the client's ownership of the project and does not affect the operation of the production application.

Gabion Terms for Pikiner Clients

The first year of access to the project edition of Gabion is part of the migration result, on the terms of the client license.

Before that period ends, the client decides whether to continue using Gabion. That decision concerns only the tool for further development. It does not affect the project already handed over, the production application, or the data of the client.

1. 1. Renew access to Gabion

   If the client renews access, the team continues to use the Gabion capabilities the license provides for the handed-over project:

   • the architectural contracts;
   • the deterministic checks;
   • interaction with the supported AI assistants and agents;
   • the available project analysis functions;
   • updates to the project edition;
   • the other capabilities explicitly included in the renewal terms.

   Renewal does not transfer rights to Gabion Runtime, the internal module storage, or the production tools of Pikiner.

   The set of functions, the term, the cost, and the conditions of the next period are given to the client before the renewal decision is made.

2. 2. Continue development without Gabion

   If the client does not renew access, they retain:

   • the project directory;
   • the application source code;
   • the business logic;
   • the database and the migrations;
   • the configuration;
   • the tests;
   • the documentation;
   • the production infrastructure and accounts belonging to the client;
   • the right to change and develop the handed-over project independently.

   The team can work with the application as a standard project in Java, Spring, PostgreSQL, and TypeScript.

   Once access ends, the client no longer uses the functions available only through Gabion, but this creates no technical restriction on manual development or on the use of other permitted tools.

3. 3. Hand development to another team

   The client may engage:

   • their own developers;
   • a new CTO;
   • independent specialists;
   • another studio or contractor;
   • an internal AI-assisted development team.

   This requires neither the permission of Pikiner nor an active Gabion subscription.

   The new team receives a standard project and can choose its own development process. It does not receive the internal tools of Pikiner, but that does not restrict its access to the code of the client.

Separate assistance from Pikiner

Ongoing operational support of the production application is not part of the migration and does not begin automatically after handover.

If the client requires new work once the project is complete, the parties can agree a separate SOW, for example for:

• a new feature;
• a separate extension of the product;
• a substantial change to an integration;
• a change of infrastructure;
• a new data migration;
• consultation on a complex change;
• another task defined in advance.

The possibility of such an agreement does not mean that Pikiner promises in advance:

• continuous availability of the team;
• monitoring of the production system;
• on-call;
• technical support for users;
• correction of any future defect;
• a particular response time;
• an SLA without a separate agreement.

Every new piece of work begins only after the result, the price, the date, and the responsibilities of each party have been agreed separately.

What non-renewal does not do

Ending access to Gabion:

• does not revoke code already handed over;
• does not change the ownership of the client;
• does not block the repository;
• does not stop the build of the application;
• does not switch off the production system;
• does not block users;
• does not restrict the access of the client to their data;
• does not delete implemented functionality;
• does not revoke documentation already handed over;
• does not oblige the client to enter into a new contract with Pikiner;
• does not prohibit further development by another team.

The client renews Gabion only if the tool remains useful to their team. The operation of the product and the ownership of the project do not depend on that decision.

The contract is concluded with Pikiner Inc.

A single document should not govern, vaguely and all at once, the relationship between the parties, the result of a specific migration, the verification of the application, and the license for Gabion. The contract structure therefore separates these subjects.

1. 1. The master agreement — MSA

   The Master Services Agreement governs the general relationship between the client and Pikiner.

   It fixes:

   • the legal entities and the authority of each party;
   • the general order of interaction;
   • confidentiality;
   • the invoicing and payment procedure;
   • applicable taxes;
   • the general warranties;
   • the limitations of liability;
   • the procedure for bringing claims;
   • the governing law;
   • dispute resolution;
   • the conditions for terminating the agreement;
   • the general intellectual property rules;
   • which provisions survive termination.

   The MSA must not stand in for the description of a specific project. The functional result, the price, and the date are defined in the SOW.

2. 2. The description of a specific project — SOW

   The Statement of Work fixes the obligations for a specific migration.

   The SOW states:

   • the baseline of the working product;
   • the agreed behavior being migrated;
   • the user and administrative roles;
   • the business rules;
   • the integrations;
   • the composition of the data;
   • the functions, states, and journeys included in the result;
   • the explicitly excluded functions and work;
   • the obligations of Pikiner;
   • the obligations of the client;
   • the decisions, materials, and access rights required;
   • the price of the project;
   • the payment schedule;
   • the delivery date or the agreed calendar;
   • the handover contents;
   • the environment requirements;
   • the boundaries of the deployment-ready result;
   • the migration of production data, if it is included;
   • creating the infrastructure and the production deployment, if they are included;
   • the procedure for changing the SOW;
   • the consequences of a delay in mandatory decisions or access on the side of the client;
   • the warranty period and its boundaries;
   • a reference to the applicable acceptance criteria.

   New features are not added to the SOW automatically during the migration.

   If the client proposes a change to an agreed result, the parties draw up a change order stating the effect on the price, the date, and the acceptance criteria before any additional work begins. The client may decline the change; the original SOW then remains in force.

3. 3. The acceptance criteria and procedure

   The acceptance criteria may be an annex to the SOW or a separate document incorporated into it by reference.

   They describe:

   • the roles to be verified;
   • the user and administrative scenarios;
   • the expected behavior;
   • the agreed visual references;
   • the test data and preconditions;
   • the procedure for providing the release candidate;
   • the start of the acceptance period;
   • the verification period;
   • the format of the findings;
   • the reproducibility requirements for discrepancies;
   • the correction procedure;
   • the re-verification of the affected scenarios;
   • the written confirmation of acceptance;
   • the legal consequences of no response within the set period.

   The standard verification period is 10 working days from written notice of readiness and the provision of working access to the release candidate for the client.

   Findings are submitted as a consolidated list of reproducible discrepancies with the SOW.

   Acceptance is not used to add new features or to change an approved redesign.

   If the new system differs from the agreed behavior or from the visual reference without a redesign, Pikiner corrects that discrepancy within the project.

4. 4. The license for the project edition of Gabion

   The Gabion license governs the use of the tool for further development. It does not determine the ownership of the handed-over project by the client.

   The license fixes:

   • the term of the included access;
   • the project for which access is granted;
   • the permitted users;
   • the available functions;
   • the limitations of the project edition;
   • the procedure for updates;
   • the scope of assistance with Gabion;
   • the rules for use with AI models;
   • the renewal procedure;
   • the conditions for ending access;
   • the rules for using the revocable token;
   • the prohibition on distributing and reselling Gabion;
   • the absence of access to the internal module storage of Pikiner;
   • the absence of a right to create an unlimited number of independent projects;
   • confirmation that the production application stays independent.

   The license has to state explicitly that its expiry or non-renewal:

   • does not revoke the project code of the client;
   • does not change the ownership of the client;
   • does not prohibit operating the application;
   • does not block the build of the handed-over project;
   • does not restrict the access of the client to their data;
   • does not require the deletion of results already handed over.

The intellectual property boundary in the documents

The MSA, the SOW, and the Gabion license have to fix the actual division identically:

An anonymized Pikiner module must not contain the data, the secrets, the source code, or the unique business logic of the client.

The order of precedence

If a marketing page, correspondence, or a presentation diverges from the signed documents, the legal obligations are determined by the contract.

The order of precedence between the MSA, the SOW, the annexes, a change order, and the license has to be established explicitly in the documents themselves.

The MSA governs the relationship between the parties. The SOW fixes the result of the migration. The acceptance criteria define how that result is verified. The Gabion license governs only the use of the development tool.

The contract has to describe in advance what happens if the old product changes, a discrepancy is found, a decision is delayed, the parties stop working together, or Gabion is not renewed.

None of these cases may give Pikiner the right to withhold a project already handed over or to block the production application of the client.

A change in the relationship between the parties may end future work or access to the tool. It must not turn into a technical shutdown of the client's product.

Pikiner receives only the data and the access required to perform the agreed work, only for a defined purpose, and only for the period required.

Access to a project does not give Pikiner the right to use the data, the code, or the confidential materials of the client for other projects.

Who owns the data

The product data belongs to the client, or is under their control, in accordance with the relationship between the client and their users and with the applicable law.

Pikiner acquires no ownership of:

• production data;
• user data;
• client documents;
• the contents of the database;
• files uploaded by users;
• product analytics;
• confidential information;
• the accounts of the client;
• secrets and access keys.

The roles of the parties in processing personal data, the permitted purposes of processing, and the contractual documents required are determined before the relevant access is granted.

If the nature of the project requires a DPA or another data processing document, it is signed before such processing begins.

Which data is used during development

Wherever possible, development and testing use:

• synthetic data;
• anonymized sets;
• minimal samples;
• a separate test environment;
• test accounts;
• examples prepared specifically, without personal data.

Production data is used only when the agreed task cannot be performed, or the migration cannot be verified, without it.

Before production data is provided, the parties determine:

• why it is required;
• which tables, fields, or objects are needed;
• whether the volume can be reduced;
• whether anonymization is required;
• where the data will be held;
• who will have access;
• how long it will be stored;
• how its deletion or return will be confirmed.

Access to production data is not treated as automatically included in every migration project.

Migrating production data

If a data migration is part of the SOW, the parties record in advance:

• the sources;
• the composition and the volume;
• the mapping between the old and the new schema;
• the transformation rules;
• the cleanup;
• the handling of erroneous and incomplete records;
• a trial migration;
• the verification of counts and completeness;
• the verification of critical relationships;
• acceptable downtime;
• the moment writes to the old system stop;
• the cutover procedure;
• the participants responsible;
• the criteria for successful completion;
• the conditions for rollback;
• the rules for retaining temporary copies.

If the migration of production data is not stated in the SOW, it is not part of the standard migration result.

Where the accounts and the infrastructure are held

Wherever possible, production resources are registered directly to the client.

This applies to:

• cloud accounts;
• domains;
• DNS;
• certificates;
• databases;
• file storage;
• payment systems;
• mail services;
• data providers;
• monitoring systems;
• external APIs;
• other production services.

Pikiner receives separate accounts or temporary roles with the minimum rights required.

The main owner password for an account should not be given to Pikiner where the provider allows a separate user or role to be created.

Secrets

Secrets include, in particular:

• passwords;
• API keys;
• tokens;
• private keys;
• encryption keys;
• database credentials;
• signing secrets;
• recovery codes;
• access to cloud infrastructure.

Secrets must not be transmitted:

• through the first contact form;
• in the plain text of a public issue;
• inside the source code;
• in the project documentation;
• in configuration examples;
• in the Git history;
• in a recording of a product demonstration.

An agreed secure channel is used to transmit secrets.

The project documentation describes the names and the purpose of environment variables, but does not contain live production values.

If a secret has been disclosed through an unsuitable channel, it has to be replaced, not merely deleted from the message.

Use of external AI models

Gabion can be used with different AI models, external and local. The technical ability to connect a model does not mean automatic permission to send it the materials of the client.

Before an external model is used, the parties determine:

• which providers are permitted;
• which types of data may be sent;
• whether the project source code may be sent;
• whether logs may be sent;
• whether the data schema may be sent;
• whether user data may be sent;
• whether the provider uses submitted material for training;
• which retention settings are available;
• whether a local model is required;
• which costs belong to third-party services.

The data, the source code, and the confidential materials of the client must not be used to create general Pikiner modules or to work on other projects.

If a reusable module is derived from a project, it is first separated from:

• the data of the client;
• the names of the client and the product;
• the unique business logic;
• the secrets;
• the internal identifiers;
• the confidential rules;
• fragments of the client's old code.

Access for employees and contractors of Pikiner

Access is granted only to the participants who require it to perform the project.

Before the work begins, the parties determine:

• which categories of participant receive access;
• to which systems;
• with which rights;
• for which period;
• whether contractors may take part;
• which confidentiality obligations apply to them;
• which access logs are available;
• who is responsible for revoking rights.

A participant who has stopped working on the project must not retain access to the systems of the client.

Recordings of meetings and demonstrations

The demonstration of the product of the client and the Gabion Live Showcase are different meetings.

Before any meeting is recorded, the parties agree separately:

• whether a recording will be made;
• who will receive it;
• where it will be stored;
• for which purpose it is used;
• when it will be deleted.

The absence of an objection must not be treated automatically as consent to a recording.

While demonstrating the product, the client should not show production secrets or personal data that are not needed to understand the journey.

Revoking access after handover

Before the project is completed, the parties compile a list of the access granted to Pikiner.

It covers:

• repositories;
• cloud roles;
• databases;
• test and production environments;
• CI/CD;
• external APIs;
• monitoring systems;
• document storage;
• communication systems;
• temporary accounts;
• the keys and tokens issued.

Once the agreed work is complete:

• the temporary access of Pikiner is revoked;
• temporary keys and tokens are rotated where necessary;
• accounts created only for the project are deactivated;
• temporary copies of data are returned or deleted by the agreed procedure;
• the client takes control of the production resources required;
• the handover and the revocation of access are recorded in the closing documents.

Access for Pikiner continues after handover only where a separate obligation is in force that genuinely requires it.

What a Gabion token does not do

A Gabion token controls access to the development tool.

It must not:

• give Pikiner access to production data;
• give Pikiner administrative control over the application;
• switch the production system on or off;
• block users;
• revoke the code of the client;
• change ownership;
• prevent the project from building without Gabion.

The access of Pikiner has to be limited and revocable. The access of the client to their own project and data has to be permanent and independent of Gabion.

Models, Data, and Cost Control in Gabion

Frequently Asked Questions

Demonstrate the product and name the independence requirements that are critical for you.

During the first free meeting, you demonstrate your working product to the Pikiner team: the main roles, the journeys, the data, the integrations, and the known limitations.

The repository, production access, and full technical documentation are not required for a first conversation.

Before a proposal is prepared, tell us if any of the following are critical for your company:

• full handover of the application source code;
• a particular IP ownership structure;
• infrastructure hosted only on the accounts of the client;
• specific requirements for production data;
• a prohibition on sending materials to external LLMs;
• the use of a local model;
• a particular jurisdiction or contract structure;
• a separate DPA;
• an NDA signed in advance;
• the ability to continue development without Gabion;
• handover of the project to an internal or external team;
• additional requirements for a clean build and deployment;
• restrictions on third-party dependencies and licenses.

If a mandatory requirement is technically incompatible with the Pikiner production pipeline, we report it as soon as the limit becomes apparent.

If the project is compatible, Pikiner continues gathering the necessary information at no charge, up to a fixed proposal with a defined result, price, and date. A separate paid discovery before the proposal is not required.

The boundaries of ownership and independence are defined before the migration begins, not after the product is handed over.

How the Migration Works