Clicksov

EXIT PACKAGE

Exit package

Every Clicksov workflow comes with a way out. It is written into the contract, kept current with every release and tested once a year. This page says exactly what that means.

What you get on leaving

On termination, for each workflow, you receive:

The workflow repository

One versioned repository containing the specification and prompts, the domain model and your customer-specific mapping, the model manifest, the evaluation set (golden examples and thresholds), the deployment (Helm charts and an infrastructure module per certified partner), the policy (data residency, retention, guardrails, AI Act documentation) and the day-2 runbook. The repository is signed and ships with a software bill of materials (SBOM).

Container images

The images the workflow runs on, so a new team can deploy the same version you were running.

Model references, including any fine-tunes on your data

The manifest names every model behind every role. If a model was adapted with your data, the adapted weights are yours.

A data export

of the workflow's own data in open formats.

With these four items, your own team or another vendor can run the workflow on any Kubernetes environment that passes the reference test. An exit is a handover, not a rebuild.

How it is kept current

The exit package is not assembled when you give notice. It is the repository itself, and it moves with every release. Each release updates the spec, the manifest, the evaluation results and the runbook. The signed repository and the images at that version are what you would receive on that day.

This is possible because the workflow is built on open interfaces: Kubernetes, OCI images, Helm, GitOps, an OpenAI-compatible API behind an AI gateway, MCP connectors to your domain model, decision rules as configuration, OpenTelemetry tracing and OIDC single sign-on. The core is fixed; the adapters to a specific partner are thin.

How it is tested

Two tests, both routine.

  • Portability test, every release. Each release is deployed to at least two cloud partners and one on-premise reference and must pass the same evaluation set on each. Every model swap starts with the evaluation set. Partners enter the catalogue only after passing the reference test.
  • Switch drill, once a year per customer. The workflow is moved to another certified partner or to the on-premise reference and the evaluation set is run again. The result is recorded and shared with you. Under DORA, financial entities must have exit strategies for ICT services supporting critical or important functions that are documented, tested where appropriate and reviewed periodically. The switch drill record is your evidence.

What it costs

The exit package, the portability test and the yearly switch drill are included in the run fee. There is no separate charge to receive the package.

Infrastructure is passed through at cost. Under the EU Data Act, whose switching rules have applied since 12 September 2025, providers of data processing services may charge no switching fees for a one-off switch from 12 January 2027; until then, fees are limited to direct costs. Clicksov's partner contracts and its own terms follow this: a one-off switch to another partner or to on-premise carries no egress fee from Clicksov.

Frequently asked questions

Can we take the workflow to a vendor who is not a Clicksov partner?
Yes. The repository targets standard Kubernetes with Helm and GitOps. Any environment that passes the reference test can run it. Clicksov can run the reference test against a new environment on request.
What about the model? Is it ours?
Open-weight models are referenced by the manifest and are available under their own licences. Any fine-tune produced on your data is yours and is included in the package. Models behind a third-party API are referenced, not shipped; the evaluation set lets you test a replacement.
How long does an exit take?
Indicatively, a switch drill moves a workflow and re-runs the evaluation set within days, because it is rehearsed yearly. A full exit to a new operator adds the time that operator needs to take over day-2; the runbook is written for that handover.
Does the package meet DORA's exit requirements on its own?
It gives you the technical artefacts and a tested transition. Your exit strategy under DORA Article 28 also needs your own assessment of criticality, your choice of alternative and your internal plan. Clicksov provides the inputs; the strategy stays yours.

Want the exit package reviewed by your risk or procurement team before you start? Book a conversation.

Sources

Which process do you want to take live?

Book a call