In this piece
Enterprise software: settle the business rules before AI writes the code
A refund feature looks ready for an AI coding agent: purchases less than 30 days old qualify. Then sales forwards a 60-day promise. Finance asks whether the amount exceeds €5,000. Support explains that customer success has always made exceptions.
The engineer can write the condition. The company still has to agree what the condition means.
Consider this fictional enterprise workflow. One compliance colleague accepts the current practice; another believes it violates a policy that nobody can locate. The sales promise came from a Confluence page whose author has left. Each department expects the new software to preserve its understanding.
Conflicting business rules are incompatible instructions about the same business decision. Resolving them requires evidence, an authorized owner and an explicit outcome for disputed cases. More generated code does not supply that authority.
Enterprise systems also contain difficult engineering, especially around security and distributed state. This article addresses the earlier bottleneck: deciding which behavior the business will stand behind. The refund periods and approval threshold below are illustrative company rules, not statements of statutory refund rights.
Start with a business-rule conflict register
Record each claim separately before combining it into a specification. A polished paragraph can hide a disagreement that a small table makes obvious. Keep the original wording, source version and affected transactions beside the question that needs a decision.
Check scope first. A 30-day default and a confirmed 60-day commitment can both be valid for different purchases. Finance approval answers a separate question. Establish that two instructions concern the same transaction and decision before treating them as contradictory.
| Claim | Evidence to collect | Decision still needed |
|---|---|---|
| Purchases under 30 days qualify. | The approved policy, its effective date and the event that starts the clock. | Which purchases use this period, and what happens exactly at the deadline? |
| Sales promised 60 days. | The dated sales page and the actual commitments made to affected customers. | Which commitments apply, and who can resolve disputed coverage? |
| CSMs may make exceptions. | The delegation of authority and examples of recorded exceptions. | Who may approve an exception, for which reason, amount and purchase? |
| Amounts over €5,000 need finance approval. | The approval policy, the amount definition and its current owner. | Does this mean the purchase amount or refund amount? Is the threshold strictly greater? |
| Compliance colleagues disagree. | The claimed obligation, its source and the person authorized to interpret it. | Who resolves the interpretation, and how are live requests handled meanwhile? |
An old document is evidence to investigate. Its age alone does not invalidate a customer commitment. Equally, repeated exceptions do not establish that staff had authority to make them. An unsuccessful document search leaves an unresolved question.
The NASA Systems Engineering Handbook explicitly connects stakeholder conflict resolution with knowing who holds decision authority. The same basic discipline helps here: identify the decision that remains open.
For each conflict, add a named owner, a decision deadline and a temporary handling instruction. If an unresolved sales promise affects a live refund, send it to the agreed review route. Give that queue a responsible person and an escalation time that respects the applicable customer deadline.
Assign authority for each decision
Choose an owner for the specific decision and record the limits of that person's mandate. “The business will decide” is an assignment to nobody.
Atlassian's DACI framework separates the person driving the decision from its approver, contributors and people who need the outcome. That distinction helps a coordinator gather evidence without quietly becoming the policy authority.
In the refund example, the finance owner decides the approval rule. The authorized commercial and legal owners establish which customer commitments apply. A designated policy owner defines exceptional circumstances and delegates any exception authority. The product lead coordinates the resulting workflow within that mandate.
A fractional CPO can make the unresolved decisions visible and coordinate the work. The role does not automatically confer permission to waive finance or compliance requirements. Where a decision requires several approvals, name each one and their sequence.
Record the agreed rule, its rationale, required approvals, affected customer group and effective date. Include the source links and the person who will maintain it. A product lead should be able to explain why the rule exists after everyone in the original meeting has moved on.
When agreement is blocked, take a concrete choice to the person with the necessary authority. For example: “These purchases have disputed 60-day commitments. Should they enter the review queue while the contract owner resolves coverage?” That is easier to decide than an open request to align on refunds.
Separate refund eligibility from payment approval
An eligible refund can still require finance approval before payment execution. Combining both questions in one boolean makes the approval requirement easy to lose.
Suppose the fictional owners approve the following limited scope: one full refund for one settled purchase with a positive EUR amount, with no previous refund or active dispute. Other cases go to a separately owned review route. The worked tables are proposed examples, not a production policy or an executed refund system.
For this example, the purchase record identifies its approved policy version and a window of either 30 or 60 days. The 60-day window applies only where the authorized review confirms that commitment for the purchase. An unresolved promise remains in review.
The clock runs from completed purchase to receipt of the refund request, using UTC timestamps and elapsed 24-hour periods. “Less than 30 days” therefore excludes exactly 30 days. These are explicit choices for the example; your business must decide its own event, timezone and boundary.
| Condition | Eligibility result | Reason |
|---|---|---|
| Required facts, applicable policy or authority are unresolved; or the case is outside scope. | REVIEW | An authorized reviewer must resolve the missing basis. |
| In scope, with facts, applicable policy and authority established; request age is below its approved window. | ELIGIBLE | The standard period or confirmed 60-day commitment applies. |
| In scope, with facts, applicable policy and authority established; the window has expired; a valid, purchase-specific exception is approved. | ELIGIBLE | The authorized exception changes time eligibility only. |
| In scope, with facts, applicable policy and authority established; the window has expired; an exception request awaits a decision. | REVIEW | The exception owner must decide. |
| In scope, with facts, applicable policy and authority established; the window has expired; there is no exception request or the exception was denied. | NOT_ELIGIBLE | The recorded policy basis does not grant eligibility. |
A negative age, missing timestamp or unverified exception authority is unresolved data. An approved exception must identify the purchase and remain valid for the request. Expired, revoked, conflicting or mismatched exception approvals go to REVIEW. A NOT_ELIGIBLE result describes this policy decision; a disputed contractual or mandatory entitlement requires the appropriate review.
Now evaluate payment approval separately. In this worked scope, the threshold uses the settled gross EUR purchase amount. Exactly €5,000 does not exceed €5,000. The owners must define a different amount basis before adding partial refunds or other currencies.
| Condition | Next state | Responsible action |
|---|---|---|
Eligibility is REVIEW. | Business review | Resolve the case with its named owner; monitor the response deadline. |
Eligibility is NOT_ELIGIBLE. | Policy outcome | Explain the reason and the route for challenging it. |
| Eligible, positive amount at or below €5,000. | Ready for payment checks | Continue through the separate execution controls. |
| Eligible, above €5,000, finance approval absent, pending or invalid. | Awaiting finance | Request the required approval for this purchase and amount. |
| Eligible, above €5,000, valid finance approval recorded. | Ready for payment checks | Continue through the separate execution controls. |
| Eligible, above €5,000, finance declines approval. | Approval escalation | Resolve the refusal with the authorized owners; eligibility does not silently change. |
A CSM's approved late-refund exception never satisfies finance approval in this example. “Ready for payment checks” also does not mean that money has moved. Authorization, duplicate requests and payment failures still need engineering and verification.
OMG's Decision Model and Notation provides a standard for expressing decisions. A spreadsheet can also expose these conditions before the team selects an execution engine.
Rule ordering deserves a separate check. In Camunda's documented hit policies, Unique permits at most one matching rule; First returns the first match. Neither decides which business policy deserves priority.
Our tables are explanatory, not executable DMN. Before implementation, verify every input combination you intend to support. Zero matches need a defined outcome, and a catch-all row must not overlap the normal rows under Unique. Reordering rows to remove a visible conflict can silently choose a business winner.
Turn disputed boundaries into acceptance examples
Ask the owners to approve concrete input and outcome pairs before implementation begins. The following examples test the choices made above. They are proposed acceptance cases, not reported test results.
| Request | Expected result | Decision exposed |
|---|---|---|
| 30-day window, age 29 days 23:59:59, €100. | Eligible; ready for payment checks. | The strict time boundary. |
| 30-day window, age exactly 30 days, no exception. | Not eligible under this policy. | Exactly 30 differs from less than 30. |
| Confirmed 60-day window, age 45 days, €100. | Eligible; ready for payment checks. | The applicable customer commitment. |
| Confirmed 60-day window, age exactly 60 days, no exception. | Not eligible under this policy. | The longer window still has a defined boundary. |
| 30-day window, age 31 days, valid exception, €6,000, no finance approval. | Eligible; awaiting finance. | An exception changes eligibility, not payment authority. |
| 30-day window, age 31 days, exception pending. | Review. | An unanswered request is not an approval. |
| Age 10 days, €5,000. | Eligible; ready for payment checks. | Exactly €5,000 does not exceed the threshold. |
| Age 10 days, €5,000.01, no finance approval. | Eligible; awaiting finance. | The first cent above the threshold. |
| Sales claims 60 days; the applicable commitment is unresolved. | Review with an owner and deadline. | Missing authority cannot become automatic approval or rejection. |
| The policy changes after purchase; the earlier version applies to that purchase. | Evaluate the recorded applicable version. | A newly edited page does not rewrite the selected policy basis. |
Attach these examples to the decision record. Developers can turn the approved pairs into tests, and reviewers can trace a failed test to the business choice it protects.
Test uncovered combinations as well, including invalid inputs and conflicting approvals. Once payment execution is in scope, add its own failure and replay cases. Keep those controls distinct from the eligibility examples so a passing policy test cannot be mistaken for a safe payment integration.
Give AI the evidence work and the approved implementation
Use AI to surface contradictions, prepare alternatives and translate approved decisions into code and tests. A coding agent can help with substantial parts of the work. The organization still supplies the authority under which a rule takes effect.
Before the decision, ask an assistant to compare authorized source material, preserve dates and quotations, and flag missing definitions. It can find that one document says “purchase amount” while another says “refund amount”. It can propose the €5,000.01 case that nobody discussed.
A useful analysis request is:
Compare these refund sources. List conflicting claims with their source, version, effective date and affected customer group. Separate recorded decisions from assumptions and historical practice. Identify who needs to resolve each question. Draft boundary examples, but leave the expected outcome open where the authorized decision is missing.
After the owners approve the rule, give the coding agent the versioned decision and accepted examples. Require it to flag new ambiguity instead of selecting a policy by document recency or frequency. Tests derived only from the same unresolved prompt can repeat the same assumption.
Our GitHub Spec Kit production guide covers the subsequent specification, plan and implementation workflow. A specification becomes more useful when the disputed business decisions behind it have an owner and an outcome.
Keep the decision current after release
Publish the approved rule where sales, support and engineering will actually use it. Update the sales guidance and support instructions alongside the implementation. Mark superseded material clearly while preserving the history needed to explain earlier purchases.
NASA's requirements-management guidance connects approved changes with impact assessment and traceable records. For this workflow, that means identifying which customers, instructions and tests a rule change affects.
The record should retain a rule ID, version, owner, approval evidence and effective scope. Link it to the acceptance examples and the implementation change. A new 30-day policy may apply to future purchases while an earlier customer group retains a confirmed 60-day window.
Give temporary exceptions an expiry or review trigger. Watch the age of unresolved cases and the reasons staff use the review route. Repeated exceptions can reveal a rule that needs reconsideration. They should reach its owner through a visible change request.
Our AI-ready company wiki guide covers how to maintain the approved knowledge. The discovery-phase guide explains the broader engagement for turning a product problem into an agreed scope.
To evaluate whether AI coding is helping this workflow, track time awaiting decisions and rework caused by clarified rules alongside implementation time. If code gets faster while approvals remain unresolved, the delivery bottleneck will still be visible.
Start with one decision people disagree about. Bring the conflicting evidence, choose the authorized owner, and walk through the boundary examples together. That gives the team something precise to implement and a reason to trust it.
Enterprise business-rule conflicts: FAQ
How do you resolve conflicting business rules before automation?
Record each claim with its source, version and affected transactions. Identify the authorized decision owner and required approvals. Agree the rule, its effective scope and unresolved-case handling, then approve concrete examples before implementing it.
Who should own a business rule in enterprise software?
The person or role with delegated authority over that decision. A product lead can coordinate the workflow, while finance owns financial approval and the appropriate commercial or legal owner resolves customer commitments. Record the mandate and escalation route.
Can AI decide which policy document is correct?
AI can compare sources, identify contradictions and apply an explicitly approved precedence rule. Its generated answer does not itself establish organizational authority. If the applicable rule is disputed, preserve the uncertainty and route it to the responsible owner.
What belongs in a business-rule decision record?
Include the question, rule ID and version, owner, sources, rationale, approvals, affected customer group, effective date, exception authority and acceptance examples. Link the record to the implementation and tell affected teams when it changes.
Should every enterprise workflow use a DMN engine?
No. A small reviewed table may be sufficient for discussing the rule. An execution engine becomes a separate architecture decision. Whatever implements the rule must preserve approved precedence and handle missing facts, overlapping conditions and uncovered cases.
What should the team do while a policy decision is unresolved?
Use an explicitly authorized temporary handling route with a named owner, response deadline and escalation. Avoid turning uncertainty into an automatic rejection or approval. The temporary process must account for applicable customer obligations and be revisited when the decision is made.