Paradigm shift

The history of software systems up to this point has been one of differentiation; most software stands in isolation and tries to distinguish itself from other software. Vivalence changes the paradigm to integration by standardising on a common denominator.

Today’s applications share the wrong layer: they keep private what is actually common for a problemspace — the schemas, ontologies, logic, and services — yet all users get the same surfaces, workflows, and presentation paradigms. Vivalence inverts this with its common denominator — the mode. Modes carry domain and business logic, they implement services, they transport data, and they surface application interfaces. This allows the core parts of any stack to be standardized and shared, while higher-order features and surfaces can be individualized with little effort.

This moment in time offers a unique opportunity to redo our software stack — AI is giving everyone the capabilities to create, design, and populate their own applications. What’s missing is the right substrate and tooling. Introducing: Vivalence.

Disintegration

The last 30 years of software have produced ever more elaborate, powerful, and complex applications — and they all deny us the same three things.

Owning the application

Users have little influence over the surfaces and control-flows of their applications: SaaS ships one and the same product to everyone, and customization ends where the feature flags do. Microsoft Excel has thousands of features, and there is a saying that anyone only uses 5% of them — but everyone uses a different 5%. This is true. No vendor can build an individual application per user, so applications grow complex and intricate instead, expensive to maintain and slow to evolve. Overwhelming, yet suboptimal for any one single user.

Owning the data

Applications hold dominion over their users’ data. There are a dozen popular calendars, inventory systems, and learning platforms, and their schemas are closely related and ought to be interoperable to some degree, since they model the same underlying problemspace — every calendar shares a notion of what an event is, when it happens, and which people attend, and the same goes for any other domain. But interoperability introduces churn risk without upside, so vendors build silos. Users have no ownership, no portability, and no safety regarding their data.

Owning the runtime

Systems run on machines users don’t control, executing code that can’t be inspected, moving data through flows users can neither see nor audit. With AI agents entering the loop this turns acute: opaque cloud agents acting on invisible data. No transparency, no verifiable trust.

Application, data, runtime. Control, portability, transparency. These three failures stem from the same cause: the wrong application layers are shared.

Decomposition

Vivalence decomposes a system into layers and building blocks — the modes. Modes carry domain and business logic, they implement services, they transport data, and they surface application interfaces. The layers are, sorted from most shared to most individual:

Services — databases, authentication, intelligence (LLM inference, embeddings, transcription), or messaging (mail, notifications). Commodities — swap any of them without the layers above noticing.

Domain — the anatomy of any problemspace: the data-objects, their properties and relationships, and the business logic that operates on top of them.

Data — the actual content a system runs on: datasets and assets. These could be private records like email, or shared communal datasets like language-learning corpora.

Surface — what users touch: the interfaces and workflows that present the data, the controls that invoke domain logic, the agent harnesses, context pipelines, and tools.

Any instance of Vivalence is made from the same components: a runtime that hosts daemons, and clients to reach them. A daemon is a self-contained, persistent system — and it is composed of modes. A daemon is the sum of its modes, and each mode brings something to the daemon, be it Data, Surface, Domain, or Service. And the whole system is constructed from a library — the typology — of custom, clean, algebraic types.

Integration

As an example: an individual who has Vivalence installed wants to learn Spanish. The user, or more likely an agent on their behalf, pulls packages containing the various building blocks of a language-learning daemon.

The service modes come first — datastorage, auth, and an LLM adapter, the same ones every other daemon on the machine already uses. The vocabulary-practice domain mode brings the ontology and business logic: what a word or sentence looks like, the memory entities that store retention data, the routines for reviewing an item, a place to pull due or new ones. Data arrives as a corpus mode — language bundles are shared in corpora: Spanish words, sentences, conjugations, audio. That is a system to teach Spanish, and none of it was written for this user.

One person prefers flashcard drills. Another wants a conversational agent that practices with them in dialogue. Nobody has to compromise: the surface is yours to shape, and shaping it is as simple as a prompt — you describe your intent to a coding agent, and the agent builds it as a custom mode. The corpus, the domain logic, the services underneath stay untouched and shared. And if you want to learn Latin with your new setup, all you need to do is clone that daemon and swap the mode carrying the data.

Same services, same domain, different 5%. This is the benefit of everything being a mode.

AI makes it trivially cheap to produce a mode: a surface costs a prompt, a domain is within reach of any community that knows its problemspace, and a service is just an adapter to a standard interface. What AI cannot do is provide the shared substrate that keeps it all coherent at scale. Vivalence is that substrate. It’s the missing half of the AI story.

Three more good-to-knows:

• A mode is just JavaScript, JSON, and Svelte — no magic.
• Modes live in managed packages and can be shared via git servers, USB sticks, AirDrop, or Dropbox. The system is not opinionated about the sourcing of modes — as long as they arrive in the filesystem.
• Architected for single- and multiplayer, localhost and server use, entirely cloudless air-gapped setups, and broadly distributed network topographies.

Unit

Vivalence achieves this composability and integration the same way the printing press worked its wonder: by articulating the common denominator of text and building everything around it. Before movable type, every scribe wrote their own hand and every region spelled its own dialect; the press forced text through a single unit — the letter — and out of that constraint grew shared spellings, shared grammars, whole standardized languages that millions would learn to read.

In a printing press, everything is a letter. In Vivalence, everything is a mode.