Chapter 2: Where Rules Live in Dynamic Systems
In many systems, rules are treated as a property of structure. If a table has a foreign key, the relationship is assumed to be enforced. If a class has a non-null property, the value is considered mandatory. If a UI has a drop-down list, invalid values are expected to be impossible.
This approach feels safe because rules appear visible and concrete. You can point to the schema. You can point to the class definition. You can point to the UI control. The system appears to be governed by law and that law seems to live inside structure.
But structure is only reliable while reality is stable. As soon as business requirements evolve, structure either becomes an obstacle or it is quietly bypassed. The rule itself does not disappear. The system simply loses track of where it is enforced.
Process-based systems exist because reality does not stand still. Products change. Regulations shift. Operational workflows evolve. Even the meaning of a "customer," a "case," or an "employee" can transform over time.
When this happens, rigid structure becomes expensive. Not because it is wrong, but because it is slow. A structural change is not just a deployment; it is a negotiation between teams, a migration effort, a training cost, and a support risk.
In practice, business often needs to move before structure can be rebuilt. Temporary flexibility is introduced: nullable fields, generalized columns, serialized payloads, or ad-hoc extensions. The system becomes flexible but rules embedded only in structure quietly dissolve.
In a dynamic system, the central question is not "Is the structure valid?". The real question is: "Is this decision allowed?".
Rules are not ultimately enforced by column types or relationships. They are enforced by authority the part of the system that decides whether a proposed change may become official.
This is why process-driven architecture matters. A business process is not merely a sequence of steps. It is a decision framework. Each transition Submit, Approve, Reject, Cancel, Archive is a point where the system can evaluate rules in context.
When rules live in authority rather than structure, they can be expressed in business language. They can account for timing, roles, exceptional cases, and intent without forcing the data model to carry all meaning.
Once rules are understood as decision-time concerns, common operations take on clearer meaning.
"Accept" is not a flag. It is a decision: an explicit act of authority stating that a proposed state becomes the official one.
"Reject" is not undo. It is a decision not to allow a proposed change to enter the systems authoritative context.
These decisions are essential in systems that distinguish between working context and authoritative context. Users may edit data locally, experiment, and explore alternatives within a working context. But the system must clearly separate what is being considered from what has been formally accepted.
If structure were the sole guardian of rules, systems would need to lock all work until every rule was satisfied. Authority enables something more practical: freedom to work, followed by responsibility to decide.
If you are building dynamic systems, rules cannot remain implicit side effects of structure. You must decide where authority lives and how decisions are made explicit.
In practice, this means designing the business process flow, not just its structure. It means defining when decisions occur, who is allowed to make them, and how their outcomes are recorded.
It also means recognizing reconciliation between existing and incoming information as a normal activity. Rules must be re-evaluated during refresh, replacement, and post-save reconciliation, because in a living system, information is constantly changing, and decisions to change that information must remain explainable.
In the next chapter, we will explore what happens when systems optimize for stable appearances instead of honest meaning and why that trade-off quietly erodes understanding.
Table of Content Previous: What Is an Object? Next: Stable Lies and Fluid Truth
Business Process Programming in .Net
© 20042026 Laskarzhevsky Software Inc.
Unless otherwise noted, the content of this website is licensed under the
Creative Commons Attribution 4.0 International License (CC BY 4.0).
Code examples are provided under the MIT License.
You are free to share and adapt the material provided that appropriate
credit is given and any modifications are clearly indicated.
The information provided on this website is for educational purposes only.
The author and publisher make no warranties regarding the completeness
or suitability of the information and are not responsible for any damages
resulting from its use.