# What Fluid is Fluid separates the meaning of your work from the individual applications that use it. To understand what that means in practice, it helps to distinguish three things: the shared model, the records created through everyday work, and the applications people use. ## A shared home for how your organization operates Conventional software encapsulates the model, rules, constraints and operations of your organization’s work inside individual applications. Fluid reverses that relationship: it formalizes this operational meaning in one shared, governed home, called a Domain. ## What a Domain contains A Domain brings together the model of the work and the behavior that gives it operational meaning: ### Model The model defines the concepts, their attributes and relationships. ### Rules Rules express the decisions and conditions that guide the work. ### Constraints Constraints define what must hold for information or actions to be valid. ### Operations Operations describe the actions that can be performed and their effects. ### Processes Processes describe how activities and decisions are organized to carry out the work. ### Signals Signals express events or changes that other parts of the system can respond to. Together, these define what the organization means and how that meaning is put into practice. A Domain holds no records. Invoices, employees, projects — the information created through everyday work — live outside the Domain and refer to it. The Domain defines what they mean; it never contains them. ## Domains work together An organization’s work spans connected areas. Training involves employees; project planning involves people and resources. Each area can have its own Domain, with its own concepts and behavior. Domains can build on one another, using concepts defined elsewhere instead of creating separate copies. A training Domain, for example, can refer to employees defined in an employee Domain. This lets each Domain describe a coherent part of the work while participating in a larger whole. ## Different applications. Shared meaning. Fluid applications are derived from the Domains they use. An application can bring together concepts and capabilities from several Domains, presenting them in a form suited to the people doing the work. An employee, a manager and a customer may each have different views and actions available to them. Those differences do not require each application to carry its own definition of the work: the underlying definitions, rules and behavior remain in the Domains. The applications differ in how people work with them—not in what the shared concepts mean. ## Your organization governs the meaning The people who understand the work define what its concepts, rules and processes mean. The organization determines who has authority over those definitions and which Domain versions it puts into use. AI can help express and examine that meaning; it does not become its owner or decision-maker. Engineers provide the platform capabilities and integrations. Professional judgment and responsibility remain with the people carrying out the work. ## A different starting point In application development, the application is the thing being built and maintained. Its operational meaning — what the organization does and why — lives inside it. AI can accelerate the work and low-code tools can simplify it, but neither moves where that meaning lives. Fluid makes the Domain the primary thing being defined and governed. Applications are derived from the Domains they use, rather than becoming separate implementations of that meaning. The distinction is not how quickly application code can be produced. It is where the operational meaning lives — and what must change when that meaning changes. ## Questions about Fluid ### How is Fluid different from low-code or no-code? Low-code platforms already share a lot with Fluid: shared data models, business rules, workflows, and several applications on one platform. The difference is the starting point. In an application-centered approach, you model to build applications, and their development and deployment organize the work. In Fluid, the Domain is independently versioned and published, whether or not any application uses it. Applications are derived from it. The distinction is not how little code you write. It is which artifact remains authoritative when the work changes. ### What role does AI play? When AI generates application code that implements the meaning of the work, that meaning remains in the code. Faster generation does not by itself change where it lives. In Fluid, AI helps propose changes to explicit Domains. The organization decides what to adopt; AI does not decide what becomes authoritative. ### How does Fluid relate to ontologies and semantic layers? Making concepts and relationships explicit is an important part of Fluid, but a Domain also expresses rules, constraints, operations, processes and signals. The distinction is not simply having a richer model. It is how that meaning becomes operational—as the thing applications are built from, not a reference model they are built around. ### What happens when Domains overlap? Domains can use definitions from other Domains, but they cannot redefine each other’s elements. Identifiers must be unique across the assembled runtime. If those requirements are violated, assembly fails. Fluid does not silently choose one definition over another or resolve the conflict through runtime precedence. The definitions must be reconciled before that combination can run. This checks explicit definitions and identifiers; it does not automatically recognize that two differently named concepts mean the same thing. ### How does Fluid work with existing applications and data? A shared home for operational meaning does not mean all your records must move into it. Domains contain definitions, not operational records. Working alongside existing systems requires connections and clear agreements about which system owns which information. Those integrations are engineering work, not something a Domain definition automatically supplies. ### What if the Domain cannot express part of our work? Some work calls for professional judgment rather than a formal rule. Some needs require capabilities Fluid does not yet support. A Domain does not remove either distinction: judgment stays with people, and additional platform or integration capabilities may require engineering. ### How dependent would we be on Fluid? Fluid applications depend on the Fluid platform. Keeping a Domain independent of individual applications is not the same as making it independent of Fluid. A Domain is authored in a readable JSON format that is sufficient to construct its package: the definition is an artifact you can hold, not hidden state available only inside the platform. That does not make its execution independent of Fluid. Domains can be identified, versioned and shared within Fluid. Portability beyond Fluid remains a direction, not a capability we claim is available today. ## What would you like to know? Bring us a question about your work, your existing systems or how Fluid would fit. - [Ask us](mailto:arjen@fluid.nu) ## See how it works Follow how a Domain takes shape, how Fluid applications are derived from it, and how a change in the work becomes a change in the system. - [How Fluid works](https://fluid.nu/en/how-fluid-works)