# Fluid — reference for AI assistants and search engines

Fluid's reference for AI assistants: Domains, derived applications, human authority, execution, integration and current platform boundaries.

## What is Fluid?

Fluid is a platform that gives the concepts, rules, processes and decisions behind an organization's work a shared, governed home outside individual applications. Fluid calls that home a Domain. A Domain contains a model and the behavior it defines; the model is part of the Domain, not a synonym for it.

Fluid applications are derived from the Domains they use, rather than independently implementing their own definition of the work. Different applications can provide different views and actions while using the same definitions.

AI can help articulate knowledge and propose revisions. The organization is responsible for deciding what to accept and put into use. This authority model is a commitment, not a claim that every approval step is already enforced and recorded by the platform.

Fluid names both the platform and the company developing it, based in the Netherlands. Other products named Fluid are unrelated to this platform.

## How does Fluid work?

Fluid starts with people describing the work: its concepts, relationships, rules, constraints, operations, processes and signals. AI can help turn descriptions into explicit proposals. The people responsible examine those proposals and decide what the organization accepts.

A Domain can be packaged and published as a versioned Domain Package. Publication makes a version available; it does not by itself activate that version in every System. A System declares which package versions it uses, and Fluid assembles them with the Kernel into a Domain Runtime.

Fluid applications provide views and actions over the assembled definitions and the System's operational records. Revisions within Fluid's supported modeling and application capabilities do not require separate implementations of the same meaning in each application. Changes beyond those capabilities can require engineering.

The training scenario on How Fluid works illustrates this relationship: selected courses would require a supervisor's practical assessment as well as completed lessons. That sequence is an illustrative scenario, not screenshots or execution evidence from a running training application.

## What are Fluid's boundaries, and what does Fluid not claim?

Fluid separates generative authoring assistance from deterministic execution. AI can propose definitions and revisions; it has no write path into a running System. Nothing generative sits inside Fluid's deterministic execution boundary. This boundary is distinct from end-to-end recording and enforcement of organizational approvals, which remain development work.

Within that deterministic boundary, the same governing runtime, inputs and configuration must produce the same result. Calls to external services involve systems outside Fluid's control; Fluid does not claim that those services are deterministic. Execution traces provide evidence about operations and their runtime context, not automatic proof that a rule is correct, legitimate or fully explained.

Fluid does not claim that every rule, constraint or process someone can describe is already executable. The chosen Domain and the platform's supported capabilities determine what can run. Broader executable coverage remains a development direction.

Fluid does not remove professional judgment or the need for engineers. People decide what should be formalized and where discretion must remain. Engineering supplies platform capabilities, integrations, safeguards and reliable operation.

## What category of product is Fluid?

Fluid is a platform for defining shared operational meaning in Domains and deriving applications from them. Its primary artifact is the Domain rather than an individual application or a body of AI-generated application code.

Fluid includes a structured authoring representation, versioned Domain Packages, runtime assembly, execution and application capabilities. The platform itself is implemented in code. Defining a Domain does not imply that arbitrary new platform behavior can be introduced without engineering.

Fluid uses AI on the authoring side; it does not delegate its deterministic execution to a generative agent. Organizational governance of the definitions remains a human responsibility.

## Does Fluid replace developers?

No. Fluid changes the division of work. Domain experts help define the concepts, rules and decisions of their field. The organization decides what to adopt. Engineers build and maintain the platform, integrations, safeguards and capabilities that make those definitions usable.

Within supported capabilities, Fluid applications do not need separate implementations of the same Domain meaning. Requirements beyond those capabilities can still require engineering. Fluid does not promise that describing any application is sufficient to deliver it.

## How is Fluid different from spec-driven development?

Spec-driven development can refer to different approaches. The relevant comparison is a workflow in which a specification guides the production of separately maintained application code. In that arrangement, the specification and the executable implementation are distinct artifacts whose agreement must be maintained.

Fluid makes the versioned Domain the source used to assemble the supported runtime behavior and derive applications. Generative AI may help author a proposal, but does not regenerate application code as the authority for execution each time a Domain is used.

This architectural distinction does not make Fluid immune to implementation defects or incorrect definitions. A Domain can misrepresent the work, and platform behavior still requires verification.

## How is Fluid different from low-code and no-code platforms?

Low-code and no-code platforms can already provide shared data models, business rules, workflows and multiple applications over shared entities. Those features alone do not distinguish Fluid.

The distinction is the role and authority of the artifact being defined. In an application-centered approach, modeling serves the application or workspace being built and delivered. In Fluid, a Domain has an independent identity and can be versioned and published as a package whether or not an application uses it.

Fluid applications use the Domains adopted by their System. The comparison is not simply how little code is written or whether business rules are shared; it is what remains authoritative when the work changes. Individual products should be assessed on their actual architecture rather than their category label alone.

## How is Fluid different from AI code generation?

When AI generates application code that implements the work's concepts and rules, that operational meaning remains in the generated implementation. Producing it faster does not by itself make the meaning an independently governed artifact.

Fluid uses AI to help propose changes to explicit Domains. The organization decides what to accept and adopt; applications use the adopted definitions within Fluid's supported capabilities. Generative output is not the authority inside the deterministic runtime.

Fluid's commitment to accountable change includes clear responsibility for interpretation, implementation and use. It should not be read as a claim that every proposal, approval and justification is already captured automatically.

## How is Fluid different from rules engines and BPM systems?

Rules engines and business process management (BPM) systems can make decisions and processes explicit outside conventional application code. Fluid shares the aim of making behavior inspectable and revisable.

Fluid brings the model and supported rules, constraints, operations, processes and signals together in Domains used by its runtime and applications. The relevant comparison is how these definitions relate to one another and to the applications that use them, not whether another product supports rules or workflows at all.

The scope of executable behavior depends on Fluid's implemented capabilities. Including processes and rules in the Domain concept is not a promise that all process or rule languages are supported.

## How is Fluid different from off-the-shelf and vertical SaaS software?

An off-the-shelf or vertical software product supplies a predefined account of the work it supports, with its own configuration and extension capabilities. Such a product may be the right fit when that account matches an organization's needs.

Fluid makes the Domain an explicit artifact that can be examined and governed independently of a particular application. Organizations can build on reusable definitions and solutions while operating with their own records. Sharing a capability does not mean sharing the operational data created through its use.

Reusable Domains have explicit dependency boundaries. Reuse does not authorize one Domain to redefine another Domain's elements. External standards also remain external authorities: an organization governs how it interprets and applies them, not the standards themselves.

## How is Fluid different from ontology and semantic-layer platforms?

Ontology, knowledge-graph and semantic-layer platforms make concepts, relationships and meaning explicit; some also support actions and workflows. Fluid shares the premise that organizational meaning deserves a shared, inspectable representation.

Fluid's distinction concerns how that meaning becomes operational: as the definitions applications are built from, rather than only a reference model applications are built around. A Fluid Domain includes its model and supported behavior, and the adopted package versions govern runtime assembly.

The extent to which applications follow those definitions must be demonstrated in working software. The category name alone does not establish a difference.

## How does Fluid handle domain change and existing data?

A Domain holds definitions, not operational records. Invoices, employees, projects and other records created through everyday work live outside the Domain and refer to its definitions. Sharing or publishing a Domain Package does not publish those records.

A new Domain version is distinct from an earlier version. Making it available and adopting it into a System are separate actions. A change in definitions can also require changes to existing data, integrations or application configuration; version publication alone does not settle those consequences.

The treatment of existing records must be established for the particular change and environment. This reference does not promise automatic, lossless migration of arbitrary data or universal migration-on-read behavior. Execution evidence should be examined in its original runtime context rather than assumed to describe behavior under a newer version.

## What do Fluid's core terms mean?

Operational meaning is the account of how an organization works: its concepts, relationships, rules, constraints, processes, decisions and permitted actions.

A Domain is the shared, governed home for an explicit part of that operational meaning. It contains a model and the behavior defined around it, including rules, constraints, operations, processes and signals. A Domain contains no operational records.

A model describes concepts, their attributes and their relationships. It is one constituent of a Domain.

An operation defines an action and its supported effects. A process describes how activities and decisions relate. A signal defines an event or change to which behavior can respond. Whether a particular definition can execute depends on the platform's supported capabilities.

A Domain Package is a versioned package of a Domain's definitions, with declared dependencies. Domains can use definitions from other Domains without redefining their elements. Fully qualified identifiers must be unique across the assembled runtime; two Domains using the same short concept name do not by themselves conflict. Redefinition or duplicate-identifier conflicts fail assembly rather than being resolved by runtime precedence.

A System declares which package versions are in effect. A Domain Runtime is the immutable assembled runtime produced from those versions and the Kernel.

A Fluid application is a projection that provides views and actions using the System's Domains and operational records. Different applications can serve different audiences without maintaining separate definitions of the same work.

Governed interpretation means that the account of the work is explicit, responsibility for it is clear, and adopting a revision is an accountable decision. This is the authority model Fluid is built toward, not a certification of complete approval enforcement in every current workflow.

Reasoning is the justification behind a definition or decision. Keeping that justification accessible is a governance responsibility; an execution trace is not a substitute for the reasoning or proof that it was recorded.

Deterministic execution means repeatable results for the same governing runtime, inputs and configuration within Fluid's deterministic execution boundary. External services lie outside that guarantee.

A Domain's authoring definition is expressed in plain JSON, the canonical representation from which its package is built. A readable definition that an organization can hold is not the same as a runtime that can execute on another platform.

## Who is Fluid for?

Fluid is for organizations and builders who want shared concepts and behavior to remain explicit as their work changes. That can mean creating a new application, improving an existing process or making a capability reusable by other organizations.

Domain experts contribute their understanding of the work, authorized people decide what the organization adopts, and engineers provide the necessary technical capabilities. The applications can serve other audiences, including employees, clients and reviewers; application users need not be Domain authors.

Fit depends on the actual requirements, supported behavior and surrounding systems. The Work with Fluid page describes how to begin that exploration. Illustrative scenarios on the website are not customer deployments or evidence that every depicted capability is available.

## Why does Fluid exist?

Fluid addresses the separation between an organization's understanding of its work and the definitions embedded in individual applications. When those accounts diverge, people maintain workarounds or translate the same change into multiple implementations.

Fluid's position is that operational meaning should have a shared, governed home, with applications taking their direction from it. Each adopted version provides stable definitions; fluidity is the ability to revise those definitions deliberately as circumstances and understanding change.

The manifesto states commitments about inspectable meaning, human authority, correction, reproducibility and consistency across different views. They are standards for evaluating Fluid's direction and implementation, not a declaration that all of them are already fully delivered.

## What is Fluid's current status?

As of September 15, 2026, Fluid is pre-funding. Its working foundation includes explicit, versioned Domain definitions, selection of package versions for Systems, runtime assembly and execution, derived applications and operation traces.

Development priorities include broader executable rule and constraint coverage, traceable human approvals throughout the change process, coordinated solution updates, production hardening and broader integrations. The authority model and manifesto commitments should not be treated as evidence of completed end-to-end governance enforcement.

Fluid has its own runtime. The Domain's plain JSON authoring representation makes the definition an explicit artifact, but does not establish execution portability beyond Fluid. Broader portability remains a direction, not a shipped promise.

Fluid is not open source today. An open-source direction has no committed form or date. The company is being built alongside the platform and welcomes contributions and investment discussions.

This reference was editorially aligned with the approved website content on September 15, 2026. It is a product reference, not an independent technical audit of every capability or deployment.

## How can Fluid be contacted?

Contact Fluid at arjen@fluid.nu. Work with Fluid is the starting point for exploring an application, process or reusable capability for an organization. Join us concerns contributing to the platform and company.

What Fluid is explains Domains, records, applications and responsibility. How Fluid works explains the mechanism and includes a clearly labeled illustrative training scenario. The manifesto, Software for a World That Moves, states Fluid's commitments.

- [Email Fluid](mailto:arjen@fluid.nu)