Business rules, and why yours should be readable

Where rules run

Rules evaluate at three points, and keeping them distinct is most of what makes a rule engine comprehensible.

• On save — field-level validation. A tolerance without a unit, a lead time that is negative, a description below a minimum length. Cheap, immediate, and the right place for anything that is malformed on its face.
• On state transition — gate conditions. A revision cannot reach *Released* without an approved specification, a completed impact analysis, and no open nonconformances against it. This is where most real rules live.
• On schedule — standing conditions. Released items with no approved manufacturer, open changes past their target date, controlled copies outstanding on a superseded revision. These raise tasks rather than blocking anything.

Declarative, and what that costs

Rules are declarative: a condition expressed over object attributes, relationships and states, with a message. There is no scripting language, and that is a deliberate limitation with a real cost — some rules you can imagine cannot be expressed.

The reason is what happens to scripted rules over five years. They accumulate, they acquire side effects, they call each other, and eventually a save takes eleven seconds and nobody can say why. A rule engine with arbitrary code in it stops being configuration and becomes an undocumented application running inside your PLM.

Declarative rules stay analysable. Manufacturing PLM can tell you which rules will evaluate against an object before you attempt a transition, which is why the release screen can show the gate conditions and their current status rather than presenting a button that fails.

Where a rule genuinely needs computation, it belongs in the connector SDK or as an agent evaluation, both of which have execution boundaries, timeouts and audit trails. The escape hatch exists; it is just not inside the validation path.

The failure it prevents

An engineer tries to release a revision. The system refuses with *validation failed*. They check the obvious things, ask a colleague, and eventually raise a ticket. Two days later an administrator finds it: a rule added four years ago requiring a field that a different process stopped populating.

The rule was correct when written. The cost was not the rule — it was that its failure message said nothing, so a two-minute fix became a two-day investigation with three people in it.

Every rejection here names the rule, states its condition in the words it was configured in, and shows who configured it and when. That is not a nicety. It is the difference between a rule engine people work with and one they work around.

How it meets the rest of the product

Workflows own transitions; rules own the conditions on them. A workflow says an approval is required and who provides it; a rule says the object must satisfy these conditions before that approval can even be requested.

Rules are per-tenant configuration and are versioned. A rule change is recorded with an actor and a timestamp, which matters at an audit because *when did this control come into effect* is a question with a real answer rather than a guess from a code repository.

Agents respect rules absolutely. An agent preparing a change produces a draft that satisfies the same validation a person would face, and where it cannot, it says which rule it could not satisfy. An agent that could bypass validation would make every rule advisory, which would quietly make the whole configuration meaningless.

Mass change runs against rules rather than around them. A bulk edit that would violate a condition on four hundred of six thousand objects reports those four hundred with the rule named, applies the rest, and leaves the failures as a work queue — which is what makes bulk operations safe to attempt.

The audit trail records rule evaluations that refused a transition, not only the ones that permitted it. A pattern of repeated refusals on the same rule is a signal worth having: either the rule is wrong or a process upstream of it is, and both are worth knowing.

How it meets your ERP

The most valuable gate conditions in most deployments are ERP-facing: a revision cannot release unless its published predecessor reconciled cleanly, or unless every item in its structure exists in the ERP item master.

Those rules turn a class of integration failure into a pre-condition. Catching a missing ERP item at release is a thirty-second fix; catching it when a work order fails on the floor three days later involves a production supervisor and an escalation.

Rules read ERP data through the same cached reads as everything else, with the as-of stamp visible in the rule result. A gate that depends on stale data says it depends on stale data rather than passing quietly on a read from last Thursday.

Where the boundary is

There is no scripting. Rules are declarative conditions over attributes, relationships and states. Computation belongs in the connector SDK or an agent evaluation, where it has a timeout, an execution boundary and an audit trail.

Rules also do not modify data. A rule permits or refuses and explains itself; it never silently sets a field to make a condition pass. A rule that edits data is a change with no actor, which is the one thing the audit model does not tolerate.