Conflict Resolution
When more than one Review Matrix rule matches the same document, the system must determine how to combine the results. Kazinex uses an additive merge approach — all matching rules contribute their reviewers to the step, and the final step has all matched reviewers.
How merging works
Consider a document with:
- Discipline: Structural (STR)
- Type: Drawing
- Zone: Zone-A
And two active rules:
| Rule | Match | Reviewers | Mode |
|---|---|---|---|
| Rule A | Discipline = STR, Type = Any | Structural Lead | All must approve |
| Rule B | Zone = Zone-A, Type = Drawing | Zone-A Coordinator | Any one |
Both rules match this document. The system merges them:
- Reviewers added: Structural Lead + Zone-A Coordinator (both are added to the step)
- Approval mode: The more restrictive mode applies — All must approve (because both the Structural Lead and Zone-A Coordinator must act)
Rule: When merging rules with different approval modes, the system applies the most restrictive mode from the matching rules.
| Mode A | Mode B | Merged result |
|---|---|---|
| All must approve | Any one | All must approve |
| All must approve | Majority | All must approve |
| Any one | Majority | Majority |
| Any one | Any one | Any one |
Avoiding unintended merges
Unintended reviewer merges happen when catch-all rules (with broad conditions like Discipline = Any) combine with specific rules, adding reviewers you didn't intend.
Example: A catch-all rule (Discipline = Any, Type = Any) adds the Project Manager to all reviews. A specific rule adds the Structural Lead. Result: every document has both the Project Manager AND the Structural Lead — which may not be what you wanted.
Solutions:
- Narrow the catch-all rule: Change the catch-all to apply only to specific disciplines or types, rather than true any/any.
- Remove the catch-all: Replace it with explicit rules for each discipline.
- Check the test tool: Use Testing Your Matrix to see exactly which reviewers are assigned for any given document — before activating rules.
Reviewer de-duplication
If two rules both add the same reviewer, that reviewer is only added once (de-duplicated). You don't end up with the same person assigned twice to the same step.
SLA conflict resolution
If two matching rules specify different SLA days for the same step:
- The longer SLA takes precedence — the step gets the most generous time limit
- This prevents one rule from creating an unexpectedly tight deadline when another rule intended more time
Organisation-level vs project-level rules
Organisation-level rules and project-level rules both apply in the project, and both contribute to the merge. A project-level rule can effectively extend or narrow the result of an org-level rule — it cannot suppress it entirely.
If an org-level rule adds a reviewer you don't want for a specific project, the solution is to update the org-level rule to exclude that project (using a project condition), or to clarify the discipline/type criteria so the rule doesn't fire for the unintended documents.
What's next
- Creating Rules — define match criteria and reviewer assignments
- Testing Your Matrix — verify merged results for real documents
- Approval Requirement Modes — how all-must-approve vs any-one interact