Production systems in AI: facts, rules and conflict resolution
A production system in AI is a symbolic reasoning architecture that applies condition-and-action rules to a working set of facts. It matches eligible rules, chooses which one to fire and updates the facts or performs a defined action. Conflict resolution matters because several rules can match the same situation while proposing different next steps.
Here, “production” refers to a rule that produces a consequence when its conditions hold. It does not mean a manufacturing production line or simply an AI application running in a production environment.
By Ai Flowi · Published
Facts, production rules and the control cycle
The working memory holds the facts currently available to the interpreter. A rule base holds the condition-and-action definitions. The control mechanism matches rule conditions against working memory, resolves competing matches and fires the selected rule. After a change, matching must use the updated facts.
For example, case_state = ready is a fact in a small request-review exercise. A production rule might say: if the case is ready and the next action is undecided, request review. The fact records a state; the rule expresses a permitted transition. Neither implies that a model trained itself to discover that transition.
A match means a rule’s conditions are satisfied, not that its action has already happened. Keep the matched-rule set distinct from the fired-rule record. Otherwise an explanation can incorrectly report every eligible action as completed.
A synthetic case with competing rules
This is an invented symbolic trace, not a recorded Workflow execution. A request is marked ready for review, but the requester has withdrawn it. The example keeps all actions inside the state record: it neither sends a message nor modifies an external document.
On a narrow screen, scroll each fact or rule table sideways. Keyboard focus and arrow keys make the remaining columns accessible.
| Fact | Value | Meaning in this exercise |
|---|---|---|
| request_state | withdrawn | A verified withdrawal has been recorded for this request. |
| case_state | ready | The case was ready before the withdrawal was processed. |
| next_action | undecided | No next step has been selected. |
The two rules below deliberately overlap. Priority is an explicit policy of this fictional interpreter: a larger number wins. It is not a built-in priority field on AI Flowi Workflow’s Condition component.
| Rule / priority | Conditions | Action on firing |
|---|---|---|
| R1 / 20 | request_state is withdrawn; next_action is undecided. | Set case_state to closed and next_action to archive_request. |
| R2 / 10 | case_state is ready; next_action is undecided. | Set next_action to request_review. |
Both R1 and R2 initially match. Firing R2 first would select review before processing the withdrawal. This example therefore gives R1 precedence. The numbers express that decision; they are not confidence scores or measurements of rule quality.
Match, resolve, fire, then match again
| Stage | Matched rules | Decision and facts |
|---|---|---|
| Initial match | R1, R2 | Both conditions hold in the initial memory. |
| Resolve conflict | R1 selected | Priority 20 outranks priority 10. |
| Fire R1 | R2 has not fired | case_state becomes closed; next_action becomes archive_request. |
| Recompute matches | None | Both rules require an undecided next_action; R2 also requires a ready case. |
| Terminate this cycle | None | Return archive_request as the selected next step. |
The trace terminates because the selected action changes the facts that made the rules eligible. Merely writing “archive request” into an explanation, while leaving next_action undecided, would permit R1 to match again. The update must be part of the interpreter’s state transition.
Termination of this decision cycle does not mean the request has been archived. A separate authorized procedure must confirm that action if it is needed. The rule interpreter has selected a next step; it has not performed that step.
Why does conflict resolution need a declared policy in a production system?
Priority is one possible strategy. Other interpreters may prefer a more specific matching rule, consider the recency of facts or use a stable rule order. State the actual policy rather than assuming that “more specific” has an obvious meaning. A rule with more conditions is not automatically more appropriate.
If two rules have equal priority, this exercise stops for review rather than choosing implicitly. If no rule matches, it returns “no applicable rule,” which differs from a completed task. A real interpreter also needs a policy for repeated firing and facts changed by actions. These choices belong in its control mechanism.
Explicit rules help reviewers identify why an action was selected. They do not repair an incorrect fact or a contradictory rule base. A tidy trace can faithfully execute the wrong policy, so check both the source of working-memory facts and the intended consequences of each rule.
What one Condition node illustrates
Use the Condition reference for the comparison interface; the R1 illustration here has status documented: documented in the catalogue; not production-tested by Ai Flowi.
example configuration, not a recorded test
For the R1 comparison in a Workflow workspace, connect the synthetic fact record to Condition.data_input and set key_name = request_state, operator = "equals" and compare_value = withdrawn, using the reference configuration for inspecting its branch result.
This shows one key comparison from R1. It does not evaluate R1’s full compound condition, maintain working memory, assign priorities, update case_state or run the match-and-fire cycle. The exported Condition interface lists no rule agenda or priority input. Building those semantics would require additional, separately verified application logic.
Compare two hypothetical fact records: one has request_state = withdrawn and next_action = undecided; the other has the same withdrawal but next_action = archive_request. The single key comparison would identify withdrawal in both, while full R1 matches only the first. That difference shows exactly why a branch result cannot be treated as a matched production rule. This local comparison requires no model-provider credentials; the complete rule trace remains a separate teaching exercise.
Common mistakes and related concepts
Do not describe a collection of visual branches as an inference engine unless its matching, conflict and state-update semantics are implemented. Do not claim that rule execution demonstrates learning. Rules can be authored manually; changing them after review is configuration unless an actual learning process is defined.
A fixed condition is sufficient when one validated field determines the next branch. Use the existing If-Else routing tutorial for that narrower workflow task. Avoid expanding it into a rule interpreter when no competing rules or repeated fact updates are needed.
Intelligent-agent examples classify how actions are chosen. ReAct discusses action and observation loops. Agent planning explains prerequisites across steps; a production rule may select one next action without constructing such a plan.