Gabion narrows the space of technical decisions where an error is expensive.

Gabion separates the development environment from the final application.

The Runtime, the internal module storage, and the management tools are located in the Gabion perimeter. The source code, the configuration, the business logic, and the data of the specific product are located in a separate project directory.

Once built, the application is deployed and runs without an active connection to Gabion.

Two technical perimeters

The left perimeter helps to create and change the right one. The right one must not call the left one in order to serve users.

The Gabion perimeter

The Gabion perimeter holds the tools that govern the development process:

• the closed Runtime;
• the MCP server;
• the context for the AI;
• the permitted operations on the project;
• the architectural checks;
• the internal module storage;
• validation of gabion.manifest.json;
• the installation and updating of modules;
• the diagnostics;
• the human interface;
• the licensed features.

The Gabion perimeter can read and change the permitted project during development.

It must not become a service through which the production requests of the application pass.

The project directory

A command of the form gabion init my-project creates a separate application directory.

It holds the materials of the specific product:

• the source code;
• the business logic;
• the frontend;
• the backend;
• the templates;
• the styles;
• the data structure;
• the migrations;
• the tests;
• the configuration;
• the documentation;
• the deployment files.

This directory is an independent standard project on the coherent stack.

It does not contain Gabion Runtime and is not an internal catalog of the module storage.

How Gabion changes the project

During development the sequence is as follows:

1. The human states the task.

2. The AI receives the permitted project context through Gabion.

3. Gabion determines the available actions and the architectural boundaries.

4. Where necessary, the internal production process selects a compatible module.

5. The manifest describes the contents and the requirements of the module.

6. Gabion applies the changes to the separate project directory.

7. The deterministic checks verify the structure, the contracts, the data, and the configuration.

8. The human receives the result and the diagnostics.

9. The project is built by the standard means of its stack.

Gabion does not replace the source code of the application with a hidden script inside the Runtime. The result of an action always has to remain a verifiable change to the project.

How the production application works

After deployment a user request passes only through the components of the application and its infrastructure.

Gabion can change the code of the application. It does not process a user request on behalf of the application.

Three states of a project

1. 1. Creation

   Gabion initiates a new project and applies the Starter and the standard set of provided modules.

2. 2. Development

   The human and the AI change the project within the architectural contracts and checks. The internal Pikiner production process can add, remove, or update modules.

3. 3. Operation

   The built application is deployed to production and runs independently of Gabion.

The end of access to Gabion affects future work through the tool, but does not change an application that has already been built.

The boundary of access

Separating the directories is not sufficient on its own. Gabion also has to limit the scope of its actions.

The Runtime has to know:

• which project is permitted;
• which directories may be read;
• which files may be changed;
• which tools are available;
• which operations require confirmation;
• which checks are mandatory;
• where the scope of the project ends.

This makes it possible not to give the AI or a module unlimited access to the whole machine merely because they are permitted to work on one application.

Specific guarantees of isolation can be published only after the actual implementation has been verified for a supported environment.

The independent build

An architectural boundary counts as confirmed only when the project passes a clean check without Gabion.

Such a check has to include:

1. obtaining the delivered project in a clean environment;

2. installing the standard application dependencies;

3. building without Gabion Runtime;

4. running the tests;

5. creating a deployment artifact;

6. starting the application;

7. verifying the agreed scenarios;

8. confirming the absence of any calls to Gabion and to the internal module storage.

The check has to be run regularly, not only by hand before the first client project.

How the two perimeters are connected

Gabion takes part in creating and changing the project. The production application runs independently.

When the AI selects technologies for every task on its own, the project is gradually assembled from decisions with different assumptions, lifecycles, and methods of integration.

Gabion reduces that variability. The technologies, the architectural roles, the compatible versions, and the permitted forms of interaction are determined in advance and develop as a single production pipeline.

The main stack

Generated frontend contracts

The Gabion frontend pipeline is connected to the backend through automatic generation.

The pipeline:

1. the backend declares a Java DTO;

2. an OpenAPI description is produced from the Java DTO;

3. Hey API generates TypeScript types, Zod schemas, and an SDK;

4. the frontend parts of modules use the generated artifacts;

5. checks detect a mismatch between backend and frontend before a change is accepted.

Types, Zod schemas, and the SDK are not maintained by hand in parallel with the Java DTO. They are generated from a single backend source through OpenAPI.

The frontend is a fixed part of Gabion

The frontend in Gabion is not a replaceable layer.

It includes:

• Thymeleaf MPA;
• TypeScript strict;
• esbuild;
• CSS;
• the visual layer of the Starter;
• the frontend parts of vertical modules;
• the generated TypeScript types;
• the generated Zod schemas;
• the generated SDK;
• the architectural checks.

Another frontend framework inside a Gabion project is not supported.

Replacing the frontend pipeline would break:

• type generation;
• the SDK pipeline;
• the structure of modules;
• the manifest;
• the rules of server-side rendering;
• the architectural checks;
• the Progressive Enhancement Application.

What happens to the frontend of an existing product

The existing frontend of the client is not migrated as the technical foundation of the new system.

It is used as:

• a visual baseline;
• a source of user journeys;
• a source of interface states;
• a source of responsive behavior;
• an executable specification.

The agreed screens and behavior are implemented again on the Gabion frontend pipeline.

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

DevSync and the framework tools

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

They belong to the local Gabion production pipeline, not to the production application of the client.

Why the stack is fixed

The purpose is not to declare the chosen technologies universally best.

A fixed stack allows Gabion to generate coherent types and an SDK, to create reusable vertical modules, to verify contracts, and to give the AI predetermined ways to implement a change.

What independence from version chaos means

Gabion does not abolish versions and updates. It manages a compatible set of versions, an upgrade path, and the checks of the production pipeline.

The exact versions are determined by the build files and by a separate version matrix. The project must not assemble an arbitrary combination of dependencies for every change on its own.

In Gabion a module is not a single Java class, a frontend component, or a general-purpose library.

A module represents a complete vertical part of the application. It combines the elements of different technical layers needed to implement a particular capability of the product within the agreed architecture.

What one module can contain

Depending on the task, a module can contain:

• a Java backend;
• Spring configuration;
• an API or server-side actions;
• TypeScript code;
• Thymeleaf templates and sections;
• CSS;
• a separate page;
• interface elements;
• a data structure;
• Flyway migrations;
• checks;
• tests;
• project configuration;
• diagnostics for the human and the AI.

This makes it possible to treat a feature not as a set of unrelated files, but as one deliverable unit with defined boundaries.

A specific public example has to use only an implemented and verified module.

The module manifest

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

The manifest is the single source of module metadata.

On the basis of the manifest, Gabion determines:

• the pages and the navigation;
• the access scope of a page;
• the public and protected API paths;
• the sections for aggregator pages;
• the presence of migrations;
• the contracts provided;
• the mandatory contracts;
• the optional contracts;
• the elements of the project that belong to the module;
• the checks the module requires.

Dependencies use the declarations:

• provides;
• requires;
• optional.

Gabion derives the behavior of a module from the manifest, rather than from separate imperative installation code.

The page does not publish the full internal manifest schema until the policy for versioning it is approved.

The manifest describes the contents of a module and its place in the project. The Java contract describes the permitted interaction with other modules.

Contracts instead of direct dependencies

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

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

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

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

The manifest declares:

• which contract the module provides, through provides;
• which contract it requires, through requires;
• which contract it can use where one is present, through optional.

A module must not:

• import the internal implementation of another module;
• depend directly on the classes of another module;
• make arbitrary changes to files belonging to others;
• access the hidden data structure of another module;
• create an undeclared dependency on installation order;
• bypass a contract with a direct call;
• bypass the architectural checks of Gabion.

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

A module and the business logic of the client

A shared module solves a repeatable technical or product task, but does not hold material unique to a particular client.

A reusable module must not contain:

• client data;
• secrets;
• the source code of the old product;
• the name of the client or of its users;
• unique business rules;
• confidential calculations;
• specific identifiers;
• internal documents of the client.

Unique logic stays in the separate project of the client and uses the permitted module contracts.

If a new repeatable component is required during a migration, Pikiner creates an anonymized module outside the client project directory. The implementation specific to the product stays inside the project.

A module and the Starter

The Starter and a module are different layers.

The Starter is the single visual shell of the project.

Exactly one Starter is used in a project.

The project is created by the gabion init command, not by the Starter.

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

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

Creating a project

A new project is initiated by a command of the form gabion init my-project.

Gabion creates a separate project directory and installs the provided starting set of standard modules.

This directory holds:

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

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

This separation is not merely an organizational convention. It sets the technical boundary between the Pikiner tool and the result that belongs to the client.

Module management

The internal Gabion production CLI makes it possible to:

• add a module from the storage;
• remove a module;
• replace a compatible implementation;
• update a module;
• validate the manifest;
• verify architectural compatibility;
• apply the changes that belong to the module;
• run the necessary checks.

These operations are carried out through a controlled production process, not by copying files arbitrarily.

Direct access to the internal module storage, and the functions that manage it, are not part of the project edition of Gabion for Pikiner clients.

The client receives the assembled project and the means to develop it further that the license provides for, but not the internal production catalog of Pikiner.

What happens when no module exists

The absence of a ready-made module does not mean Gabion should let the AI create an arbitrary architecture freely.

Pikiner first determines:

• whether the task is repeatable;
• whether it should become a shared module;
• which contract it requires;
• which layers belong to the vertical implementation;
• which properties have to be verified;
• how to exclude the data and the unique logic of the client.

If a new module is necessary to deliver a client project that has already been agreed, creating it is internal Pikiner work.

The client pays for the agreed result of the project, not for the number of modules created or for the growth of the internal Gabion storage.

Which tasks become modules

The case for creating a module is stronger if the task:

• recurs across projects;
• affects several technical layers;
• has significant security requirements;
• is often implemented by the AI incompletely or inconsistently;
• requires coordinated migrations;
• has to preserve uniform architectural properties;
• needs a deterministic check;
• has a clear contract with the rest of the system.

Potential classes of module:

• identity and authentication;
• roles and access rights;
• the audit of actions;
• work with files;
• notifications;
• background operations;
• integration adapters;
• configuration;
• observability;
• administrative functions.

This list describes possible classes of task; it does not promise that every module exists in the current version of Gabion.

A module may be called implemented on a public page only if it:

• exists in the storage;
• passes the checks provided for it;
• is compatible with a supported pipeline;
• has a defined contract;
• is used in a real project or a prepared showcase.

The result of installing a module

Once a module has been applied, the files and changes the application needs are in the project directory.

The production application:

• does not load the module from Pikiner storage while running;
• does not call Gabion in order to serve a user request;
• does not verify a Gabion license;
• does not require a valid token;
• does not depend on the availability of the Runtime;
• is built as a standard project on the coherent stack.

The module storage takes part in creating the project. It takes no part in the operation of the production application.

An LLM can argue convincingly for a decision that breaks an implicit rule of the system. Gabion therefore separates verifiable properties from the probabilistic reasoning of the model.

Depending on the rule, control can be exercised at different levels:

The result of a check has to contain

• the rule that was broken;
• the location of the violation;
• the expected property;
• the actual state;
• the severity level;
• enough information for the AI to make another attempt;
• an explanation a human can follow.

A red status has to mean a specific property that was broken, not an abstract expression of disapproval from the tool.

Gabion provides an MCP server of its own for interaction with compatible AI assistants and agents.

Through MCP the model can receive the context relevant to the task and call the permitted actions, without requiring the whole architecture of the project to fit into the prompt every time.

The specific catalog of MCP tools and resources is published only for the version of the product that is available, and it may differ between the client mode and future public modes.

An explanation from the AI is a useful source, but not the only way to understand the state of the project. Gabion presents information for the human in the browser: in an overlay or a separate window.

The interface can display:

• the current project and task;
• the state of the environment;
• the operation being performed;
• the results of the checks;
• blocking errors and warnings;
• decisions that require a human;
• information about the model or connection in use, where it is available;
• a way through to the detailed diagnostics.

Show first what happened and whether an action is required. Disclose the technical detail on request, without hiding it from the developer.

Gabion does not require a specific IDE. A team can use its usual editor or agent environment, for as long as the required way of interacting with MCP and the project is supported.

Gabion is intended for installation into the user environment without requiring root or sudo rights.

Supported platforms

The installation process has to state explicitly

1. the system requirements;

2. where the runtime is installed;

3. how to update it;

4. how to remove it;

5. where the user configuration is located;

6. the network connections, where they are required;

7. the start of the MCP server;

8. the opening of the browser interface;

9. the health check of the environment.

The absence of a root requirement does not mean a hidden installation. The user has to see what was installed, where the data is located, and how to remove the environment completely.

Gabion Runtime remains closed Pikiner technology.

It governs the development tools, the architectural checks, access to the internal module storage, and the permitted operations on the project.

The result of the work of Gabion is nevertheless a separate project on a standard stack, not an application executed inside a closed Pikiner platform.

What stays closed

The closed Gabion perimeter covers:

• the source code of the Runtime;
• the internal module storage;
• the internal CLI functions;
• the mechanisms for installing, removing, and updating modules;
• the internal tools of the production pipeline;
• the licensed MCP interface;
• the Gabion human interface;
• the update mechanisms of Gabion;
• the control of access to the features of the tool;
• the further development of the technology.

Access to these capabilities is determined by the Gabion license.

The project edition for a Pikiner client does not provide direct access to the whole module storage or to the internal operations that manage it.

What the client receives in the project

The separate project directory contains the material of the specific application that is available to the client:

• the Java code;
• the Spring configuration;
• the TypeScript code;
• the Thymeleaf templates and sections;
• the CSS and assets;
• the business logic;
• the database structure;
• the Flyway migrations;
• the integrations;
• the tests;
• the build configuration;
• the deployment configuration;
• the project documentation.

Code created by applying modules does not stay hidden inside the Runtime if it is needed to build and run the delivered application.

The client does not need access to the original module template in the internal Pikiner storage in order to build a project already delivered.

"Available to the client" does not mean open source

The independence of the project does not mean that Pikiner is obliged to publish the application or Gabion under an open license.

Four things are distinguished here:

• the client's access to the source code of their own project;
• the client's right to own and change that project;
• the public distribution of source code;
• the licensing of the closed Gabion technology.

The client's project can remain a closed product of the client. Gabion Runtime remains a closed product of Pikiner.

What depends on access to Gabion

Valid access may be required for:

• using Gabion Runtime;
• calling the licensed MCP tools;
• working through the Gabion interface;
• the architectural diagnostics of Gabion;
• updates to the project edition;
• the permitted features for interacting with the AI;
• the features listed explicitly in the client license.

Internal module management remains a function of the Pikiner production pipeline and must not be presented as a standard capability of the client license.

What does not depend on access to Gabion

Valid access is not required for:

• the client reading the source code of the project;
• storing the project in the client's repository;
• the standard build;
• running the automated tests of the project;
• creating a deployment artifact;
• deploying to an agreed environment;
• the operation of the production application;
• the handling of user requests;
• the client's access to data;
• the operation of the external integrations of the application;
• manual changes to the project by another team.

What the license token does

The token confirms the right to use the licensed features of Gabion.

The token licenses the development tool. It does not license the client's right to run their own application.

What happens when access ends

Verifiable independence

Independence must not remain only a contractual promise.

For a supported type of project the following have to be checked automatically:

• the absence of the Runtime from the production dependencies;
• the absence of any call from the application to the Gabion license service;
• the absence of module loading while production runs;
• the absence of a build dependency on the internal storage;
• that a clean build is possible;
• that the tests can be run;
• that a deployment artifact can be created;
• that the project can be deployed by following the documentation.

If a specific third-party component requires a separate license or an external service, it has to be named as an external dependency of the application rather than hidden under the general name of Gabion.

The boundary of support

The closed Runtime can receive updates and support in accordance with the license.

The delivered project has a lifecycle of its own.

An update to Gabion must not change the production application of the client automatically, without an explicit action on the project, a check of the result, and an agreed update process.

Gabion can stop helping to change the project. That must not stop a product that has already been created from working.

Terms for Pikiner Clients

Stability of the production pipeline does not mean that versions stand still.

Java, Spring, PostgreSQL, TypeScript, the libraries, external APIs, and security requirements continue to change. Gabion has to manage those changes, but not apply them to every client project as one indivisible operation.

Four different types of update

1. 1. An update to Gabion Runtime

   An update to the Runtime can change:

   • the MCP tools;
   • the human interface;
   • the diagnostics;
   • internal module management;
   • the architectural checks;
   • the supported operations;
   • the licensing mechanism;
   • compatibility with environments;
   • the internal implementation of the production pipeline.

   An update to the Runtime must not automatically change the source code or the production environment of the client application.

   If a new version of the Runtime has to change the project, that is carried out as a separate operation on the project, with a check beforehand.

2. 2. An update to the manifest format

   A change to gabion.manifest.json belongs to the contract between a module and Gabion.

   A new version of the format may be needed in order to describe:

   • new types of module element;
   • additional checks;
   • new integration points;
   • compatibility rules;
   • the order of migration;
   • new constraints;
   • update metadata.

   A change to the manifest schema must not silently change the meaning of a module that already exists.

   For a new version of the format it is necessary to determine:

   • which versions of the Runtime understand it;
   • whether the previous format is still supported;
   • whether a manifest migration is required;
   • whether it runs automatically or by hand;
   • whether the result can be checked before it is applied;
   • what happens in the case of an incompatibility.

   A public stable schema cannot be promised until the policy for versioning the manifest is approved.

3. 3. An update to a module in the internal storage

   A new version of an anonymized module can contain:

   • a fix;
   • a new check;
   • a dependency update;
   • a change to a contract;
   • a new migration;
   • an improvement to the frontend or the backend;
   • a change to the supported production pipeline.

   Updating the source module in Pikiner storage does not automatically change the projects to which a previous version was applied.

   Before applying an update to a specific project it is necessary to determine:

   • the current version or state of the implementation;
   • contract compatibility;
   • the code changes required;
   • the order of migrations;
   • the impact on the data;
   • the impact on the interface;
   • the impact on external integrations;
   • the new checks;
   • whether a rollback is possible;
   • how the result will be accepted.

   A module must not update itself silently inside the production application.

4. 4. An update to the client project

   Changing the client project is separate work on the source code of the application.

   It can use a new version of the Runtime or of a module, but the result has to be applied explicitly to the project directory.

   The process of updating a project includes:

   1. determining the reason for the update;
   2. verifying compatibility;
   3. creating a restore point or a separate branch;
   4. applying the changes;
   5. running the migrations in a test environment;
   6. running the architectural checks;
   7. running the tests of the project;
   8. verifying the scenarios affected;
   9. reviewing the configuration changes;
   10. creating a new deployment artifact;
   11. a separate decision on production deployment.

   An update to a project must not reach production merely because Pikiner published a new version of Gabion or of a module.

The update independence matrix

Compatibility

For every update to the production pipeline it is necessary to determine:

• the supported versions of Java;
• the supported versions of Spring;
• the supported versions of PostgreSQL;
• the supported versions of TypeScript, esbuild, Thymeleaf, the OpenAPI pipeline, and Hey API;
• the compatible versions of the Runtime;
• the compatible versions of the manifest;
• the modules affected;
• the mandatory migrations;
• the checks that changed;
• the known limitations;
• the upgrade path;
• the path back, where one exists.

The word "compatible" must not be used merely because the project compiles.

Compatibility can cover:

• the build;
• the tests;
• the data structure;
• the contracts;
• the user scenarios;
• the configuration;
• the external integrations;
• deployment;
• the supported production environment.

Mandatory and optional updates

An update can be:

• recommended;
• necessary for a new feature;
• necessary for compatibility;
• related to security;
• mandatory in order to continue support for a specific pipeline.

The reason an update is mandatory has to be stated directly.

If an update is necessary because of a vulnerability or the end of support for an external dependency, Gabion has to report:

• the versions affected;
• the level of impact;
• the actions required;
• the possible temporary measures;
• the known risks of not updating.

Until a real policy is approved, Pikiner must not publish specific repair or support deadlines as a guaranteed SLA.

Updates in the project edition of Gabion

The client license has to determine separately:

• whether the client receives Runtime updates;
• which updates are included in the first year;
• whether the client receives new checks;
• which changes may be applied to their project;
• who initiates the application;
• whether a separate SOW is required;
• whether help with the update is included;
• what happens after the period of access ends.

The client's access to a Gabion update does not mean an automatic right to every new internal Pikiner module.

An update to the closed Runtime does not change the client's rights to a project delivered earlier.

Rollback

Whether a rollback is possible depends on the type of change.

A rollback of the Runtime is not the same as a rollback of the project. A rollback of code does not always roll back a data migration. A rollback of a deployment does not always restore the state of an external integration.

Before applying a change it is necessary to determine:

• exactly what can be reverted;
• which restore point is used;
• whether the old version is compatible with the changed data;
• whether the database has to be restored;
• which external actions are irreversible;
• who takes the decision to roll back.

Rollback must not be promised as a universal button for any update.

The history of changes

For supported versions a clear history has to be kept:

• the version;
• the date;
• the type of change;
• the pipeline affected;
• compatibility;
• the actions required;
• the checks that changed;
• the known limitations;
• the consequences of not applying it.

Internal implementation detail can stay closed, but the client has to understand whether an update affects their project and whether an action from the team is required.

A new version of Gabion can propose a change to the project. Only a verified change to the project can become a new production release.

The AI can explain why the solution it produced looks correct. That explanation is useful, but it does not confirm a property of the system.

Gabion separates the reasoning of the model from a deterministic check. If a critical rule can be expressed through structure, a contract, a schema, configuration, a test, or an observable result, it has to be verified by the tool.

Levels of checks

Gabion can use checks at several levels.

1. 1. Production pipeline checks

   They verify that the project matches the supported technical foundation.

   They can cover:

   • the Java version;
   • the Spring version;
   • the PostgreSQL version;
   • the TypeScript version;
   • the permitted dependencies;
   • the mandatory project structure;
   • the build rules;
   • the presence of the required configurations;
   • the absence of prohibited production dependencies.

2. 2. Project structure checks

   They verify the placement and the boundaries of elements.

   For example:

   • the mandatory directories exist;
   • a file is in a permitted layer;
   • business logic is not placed in a template;
   • the frontend does not call the internal implementation of the backend;
   • a module does not change files outside its declared scope;
   • the Runtime has not reached the production dependencies;
   • the project does not call the internal module storage during the build.

3. 3. Manifest checks

   They verify the description of a module in gabion.manifest.json.

   They can confirm:

   • the correctness of the manifest structure;
   • the presence of the mandatory fields;
   • a supported version of the format;
   • the declared contents of the module;
   • the permitted integration points;
   • the migrations;
   • the mandatory checks;
   • compatibility with the current pipeline;
   • the absence of undeclared operations.

   The specific set of checks depends on the approved manifest schema.

4. 4. Contract checks

   They verify the interaction of parts of the system across the permitted boundaries.

   For example:

   • an implementation matches the interface it declares;
   • an event has the expected structure;
   • a direct import of another module's internal implementation is prohibited;
   • a mandatory extension point exists;
   • a module uses a permitted service;
   • a change to a contract is detected before the build or the release.

5. 5. Data and migration checks

   They can control:

   • the presence of a migration for a schema change;
   • the order of migrations;
   • the permitted types;
   • the mandatory constraints;
   • the indexes a confirmed rule requires;
   • the consistency of the model and the schema;
   • the repeatability of applying migrations in a supported scenario;
   • the absence of known prohibited operations.

   A check that a migration exists does not prove that production data will be migrated without loss. That requires separate scenarios, test migrations, and reconciliation.

6. 6. Configuration checks

   They can verify:

   • the presence of a mandatory environment variable;
   • the absence of a live secret in the repository;
   • a permitted value for a parameter;
   • the separation of development and production;
   • the presence of a mandatory setting;
   • the absence of an unsafe default value;
   • the consistency of several configuration files.

   Gabion must not display the values of production secrets in its diagnostics.

7. 7. Behavior checks

   If a result can be reproduced automatically, a check can cover:

   • a user scenario;
   • an API contract;
   • an access rule;
   • a state transition;
   • the handling of an error;
   • an integration scenario;
   • a background task;
   • an expected side effect;
   • an invariant of the business logic.

   A behavior check confirms only the scenario described and does not prove the correctness of every possible state of the system.

8. 8. Independence checks

   The project being delivered has to be checked separately for the absence of a mandatory dependency on Gabion.

   A check can confirm:

   • a clean build without the Runtime;
   • the tests running without a Gabion token;
   • the creation of a deployment artifact;
   • the application starting without a connection to Gabion;
   • the absence of the Runtime from the production dependency graph;
   • the absence of module loading from the internal storage;
   • the absence of a license check in a user request.

The result of a check

A check has to return not only an error status but a result a reader can follow:

• what was checked;
• which file, module, or contract the rule applies to;
• what condition was expected;
• what was found;
• why the change was blocked or flagged;
• what action is required;
• whether an automatic correction is possible;
• whether a check by a human is needed.

The diagnostics must not hide the problem behind a general message along the lines of "something went wrong".

Three statuses for public capabilities

Every check mentioned on the Gabion site has to carry one of these statuses.

Evidence requirements

Before the status of implemented is assigned, the following have to exist:

• an executable test or check command;
• known input data;
• the expected positive result;
• the expected negative result;
• a reproducible example of a violation;
• diagnostics a reader can follow;
• a confirmed supported version of the pipeline.

A Showcase may use such a check only after both scenarios have been confirmed: the correct state and a real error.

A single mock is acceptable only where it is explicitly labeled as a mock. The other errors and reactions demonstrated have to occur in a real project and a real Runtime.

What remains a decision for a human

Not everything that matters can be expressed as a deterministic rule.

A human decision is required for:

• the correctness of the product strategy;
• the value of a new feature;
• the meaning of an ambiguous business rule;
• the choice of an acceptable risk;
• the trade-off between convenience and control;
• legal interpretation;
• ethical acceptability;
• the assessment of the user experience;
• the decision to release to production with a known limitation;
• the choice between several correct architectural options, where the contract permits them all.

Gabion has to make such decisions visible, without presenting them as automatically proven.

What a successful check does not prove

A green result from one check does not automatically mean:

• the absence of every vulnerability;
• conformance to any security standard;
• the absence of errors in the business logic;
• readiness for any load;
• legal conformance in every jurisdiction;
• the correctness of unknown user scenarios;
• that production deployment is safe without operational preparation.

Every public promise has to name a specific verifiable property rather than reaching a general conclusion that "the system is secure" or "the architecture is correct".

Gabion confirms specific properties of a project. It does not replace the engineering, product, and legal decision with a universal green indicator.

Current availability

Gabion is not yet distributed as a standalone mass-market product. The availability page explains to whom the technology is provided at present, and in what form.

At the introductory meeting the client demonstrates their product to Pikiner. At a separate Gabion Live Showcase Pikiner demonstrates its technology to the client.