Software that outlives the app it was written for.
nCubo builds distributed systems across mobile clients, services, clusters, data centers and independent participants — and a domain technology of its own that keeps them coherent when the deployment, the client or the topology changes.
Projects end.
Domains continue.
Every implementation should solve something useful now and strengthen the domain asset available to the next one.
- 1
- domain
- 5
- measured stagings
- 6
- clients
- 0
- domain edits
The client is not just a window into the system. It can be part of the system.
Modern software often concentrates computation, state and coordination inside a data center, while powerful devices are reduced to interfaces. We design systems that can use the capacity already present across clients, servers, clusters, data centers and independent peers.
- More participants can mean more capacity — not just more load.
- Capability can live where it makes sense.
- A device can participate in the system, not merely display what happened somewhere else.
The system can live where its participants live.
Different runtimes. One coherent architecture.
The same system can span participant devices, shared services, clusters, multiple data centers and direct peer-to-peer coordination.
Shared organizational state · Context-aware approvals · Privacy-preserving coordination · Event-driven operations
Centralized when appropriate. Peer-to-peer when required. Coherent in either topology.
Once a system can live in many places, a harder question appears.
Who owns identity, state and authority when no single place owns the whole system?
An architecture for systems whose identity and authority must survive distribution.
Puppeteer emerged from our work on systems that must preserve identity, causality and authority across participants, machines and changing topologies.
Instead of assuming that one service, database or runtime is the permanent center of truth, it gives a software unit its own identity, behavior and durable consequences.
A domain asset developed at nCubo
Architecture should survive scrutiny. So we make ours inspectable.
Puppeteer did not stay an internal architectural idea. Its claims became papers, experiments and reproducible tests, so they could be examined by someone who does not work here.
The point is not to publish. It is to state assumptions where they can be disagreed with, make the claims measurable, and let the architecture be challenged.
9papers
A continuing investigation into identity, authority, causality and distributed software units.
The Puppeteer Papers Series · Álvaro Rivera · on Zenodo
One domain. Many stagings. No rewrite.
It tested whether the same domain could be staged through different hosts, transports and client forms without the domain itself being modified. Different hosts, transports and client implementations.
The staging changed. The domain did not.
The argument is executable.
Each demo holds a single thing fixed and varies everything around it, end to end and inspectable. Nothing here is a claim you cannot go and check.
The same invoice, built two ways.
A conventional .NET invoice flow, and the same domain enacted as a Puppeteer Puppet. Same products, same amounts, same invoice — different architectural center.
- 22→5Files in the domain
- 5→0I/O calls inside the flow
- 0Output formats in the domainConventional: web framework dependency
Counted in the repository. An existence proof that the separation is buildable — not a performance or cost evaluation.
Not the invoice. Not the values. Not the business outcome.
What changed was the architectural authority: who was allowed to validate, persist, transport and render the act.
Start a technical conversation.
Whether you are evaluating a capability, planning a distributed system or considering a technical partnership — we would like to understand what you are building.
Start a Conversation