From the architecture call to long-term evolution
Four delivery models, a six-step engagement path, and the service commitments we are willing to put in writing. Delivery does not end when the software is installed — the boundaries and the rollback plan ship with it.
Four delivery models
Private deployment is the default, not an option; the other three cover different stages and different data-boundary requirements.
The whole system runs inside the customer’s own network boundary, with no external SaaS dependency and full air-gap operation. This is the default delivery form for all four business lines, not an option.
Finance, government, manufacturing — wherever data cannot leave the intranet
- Infrastructure from standard parts: database, Redis, message queue, object storage
- Versioned migrations, idempotent upgrades with rollback, records kept in-database
- Delivered as a single image or Compose, with consistent environments
- Connects to the customer’s existing monitoring, logging and backup systems
Ready out of the box — bind your organisation and start using it. Suited to validating value first and deciding on a delivery form afterwards.
Fast roll-out of private-domain SCRM and online learning
- Self-service sign-up and enterprise authorization binding
- Multi-tenant isolation with data governed at tenant boundaries
- Suite configuration and callbacks provisioned automatically
- No servers to run and no operations overhead
Business data is private, sensitive data stays on the endpoint, and only collaboration and sync pass through the cloud. Delivery form can even be chosen per module within a single business line.
Organisations that need collaboration efficiency and a hard data boundary
- Endpoint data never leaves the device (legdger encrypts everything locally)
- Business systems are private; only the sync path reaches the network, carrying ciphertext
- Model services can be privately deployed or called out under control
- Configured per tenant and per module
For teams with their own engineering capability: we deliver the code and the engineering standard, the customer team carries evolution forward, and we provide architecture support and an upgrade path.
Group customers with an independent engineering team and deep customisation needs
- The full repository and engineering standard (including AGENTS.md constraints)
- Architecture decision records and data model documentation
- Documented migration and upgrade paths
- Architecture review support at key milestones
A six-step delivery path
Every step has a defined deliverable. The goal of a POC is to falsify, not to demo — if the solution does not run on real data, we would rather stop at this stage.
We lay out the current state, constraints and goals. We do not rush to pitch — first we check whether this is the kind of problem we are good at solving.
We map the real structure of the existing system — data model, interface inventory, identity system and integration points — and assess the migration path and its risks.
We provide the architecture layering, data model and migration path, and write the trade-offs down explicitly — including what we cannot do.
We run the critical paths on real data and validate performance and edge conditions. The goal of a POC is to falsify, not to demo.
Rollout in batches — core paths first, peripheral modules after. Every batch has a rollback plan and acceptance criteria.
A stable kernel and backward-compatible interfaces; changes go through versioned migrations with audit and rollback. New requirements enter the roadmap rather than becoming patches.
Service commitments
These are the numbers we will put into a contract. What we cannot do, we do not write down.
7×24 on-call; P1 in 2 hours, P2 next business day
All four business lines, no exceptions
Breaking changes go into a major version, announced one cycle ahead
No data lock-in; standard formats for export and migration
Versioned migrations plus single-image replacement — rollback is swapping back
Compliance and certification material provided with delivery projects
Common questions about working with us
They share the same underlying judgements: who guards the boundary, where data should live, and how AI should connect safely. UIAM is that judgement at the identity layer, Uniclaw at the agent layer, Uniscrm at the customer data layer and Unilearning at the domain boundary layer. Different languages, one engineering standard.
Hand the complexity of identity, agents and private domain to one governable kernel
Whether you are replacing an existing IAM, building an agent platform, or trying to make private-domain operations actually work — start with a 30-minute architecture call. We will first judge whether this is the kind of problem we are good at, and say so plainly if it is not.