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 deployment changed. The domain did not have to.
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.
Architecture that can be read, tested and challenged.
Puppeteer is developed through an ongoing research series published on Zenodo. The demos make those architectural claims executable.
- 9Published papers
- ZenodoPublic record
- OngoingResearch series
1 domain5 measured stagings6 clients0 domain edits
Read the record →The Puppeteer Papers Series · Álvaro Rivera · published on Zenodo
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