# How Fluid works See how your organization’s understanding of its work becomes a shared model, how Fluid applications are derived from it, and how both evolve when your organization decides to make a change. ## From understanding the work to working applications The starting point is the work itself—not a set of screens. People describe how their organization operates, AI helps make that understanding explicit, and the people responsible decide what to adopt. The steps below follow that understanding into a shared model, the applications derived from it, and its next revision. ### Describe the work The people who understand the work describe its concepts, rules, processes and decisions: what things mean, how they relate and what needs to happen. ### Make it explicit AI helps turn that description into a structured proposal. This shared model—called a Domain in Fluid—makes the proposed meaning visible so people can inspect, question and correct it. ### People decide The people responsible review the proposal against the actual work. They decide whether it represents the organization’s understanding and should be carried forward. AI assists; it does not make that decision. AI has no write path into a running System. ### Give it a version The model is validated and packaged as an identifiable version. A revision creates a new version rather than silently rewriting the previous one. ### Put it into use The organization chooses which model versions its Fluid System uses. Creating or publishing a version does not automatically put it into effect. ### Work through the applications Fluid applications are derived from the model in use. Different people can have different views of the work while following the same underlying meaning. Operations leave a trace of what happened. ### Revise as understanding grows Experience reveals new needs or gaps in the model. People examine what needs to change and begin a new proposal. The current version remains in effect until the organization adopts a replacement. ## When finishing the lessons is no longer enough An organization changes what it means to complete safety training. For selected courses, finishing the lessons must now be followed by a supervisor’s practical sign-off. This example follows that change through the shared model and the applications derived from it. The screens and records below illustrate the scenario; they are not captures from a running application. ### Complete the lessons. Complete the training. Employees work through the lessons in a course. Under the existing rule, finishing all the lessons completes their training. ### Knowing the material is not enough. For selected safety courses, the organization wants a supervisor to observe the employee performing a practical task. Finishing the lessons alone should no longer complete the training. ### Make the new requirement part of the model. AI helps propose a practical assessment linked to an employee’s training, with a record of the supervisor’s approval. For courses that require it, training is complete only when the lessons are completed and the practical assessment is approved. ### Decide where the new rule applies. The people responsible review the proposal and confirm its scope: selected courses, approval by an authorized supervisor, and new enrolments only. Existing enrolments keep their current requirements. Accepting the proposal and putting the revised version into use are separate decisions. ### One change. Two views of the work. For a new enrolment under the revised model, the employee sees that the lessons are complete but the practical assessment is still pending. The supervisor sees an assessment awaiting review. Both Fluid applications are derived from the same revised model. ### Approval completes the training. The supervisor observes the task and records approval. With both requirements satisfied, the employee’s training becomes complete. A record identifies the employee, the approving supervisor and the outcome. ## Share the capability. Keep decisions local. What one organization has modelled can be useful to another. A safety-training provider could offer the same training solution to several employers. Each employer would use it to train its own employees and record its own supervisors’ assessments. The course structure and completion rules are shared; employee records and assessment results stay with each employer. ### Share what you have built Make the models and applications available as a versioned solution. Another organization can obtain and install it without having to recreate the meaning behind it. ### Keep operational data separate Sharing a capability does not mean sharing the records created through its use. Each organization operates with its own data. ## Where Fluid is—and where it is going ### Today · A working foundation Explicit, versioned models. Applications derived from them. Organizations choose which versions their systems use, and operations leave execution traces. ### Next · More of the work, governed end to end Extend the rules and constraints Fluid can execute directly. Make human approvals traceable throughout the change process, and support coordinated updates across a complete solution. ### Direction · Connect and share more widely Broaden connections to existing systems and explore portability beyond Fluid, so organizations can reuse more of what they have modelled across different environments. ## What would you change? Bring one rule, process or concept that your current software struggles to accommodate. We can examine whether Fluid can represent it. - [Work with Fluid](https://fluid.nu/en/work-with-fluid)