Business Rules Discovery Working Skill

What this skill is for

Business rules are the decision logic that determines what happens when: who approves what, which customers get which terms, when an order blocks, how a price is calculated. Most of this logic lives in people's heads, scattered spreadsheets, or buried in code. This skill extracts rules independently of any system, documents them with conditions and outcomes, and maps where they are enforced, violated, or missing. The output prevents the common failure where a new system is built without critical logic, or where existing systems enforce rules that the business no longer wants.

When to use this skill

• A system implementation or replacement is planned and no one knows all the rules the current system enforces.
• A process redesign keeps failing because different teams apply different versions of the same rule.
• A data quality investigation reveals records that violate policy but were created anyway.
• A compliance audit asks for documented business rules and the answer is "ask the person who retired last year."
• An integration mapping exercise needs to know which rules apply at which system boundary.
• An incident shows system behavior that contradicts business expectation, suggesting a hidden or changed rule.
• A master data governance setup needs validation rules with clear owners and override conditions.

Real work situations

Customer credit limit assignment

A sales team complains that credit limits seem arbitrary. Discovery reveals three rules: new customers receive a 10,000 EUR limit by default; existing customers receive 3 times their average monthly billing; exceptions require CFO approval and are logged to audit. The current system enforces only the default rule. The other two are applied manually via spreadsheet and email, causing delays and inconsistency. The rule documentation must separate the business intent from the current broken implementation.

Purchase order approval hierarchy

A procurement process has approval delays. Discovery reveals: orders under 5,000 EUR require a manager; 5,000 to 50,000 EUR require a director; over 50,000 EUR require a VP. Emergency orders bypass up to 10,000 EUR with a post-hoc review. The current SAP release strategy enforces only the manager and director levels. The VP level is handled by email after the fact. The emergency bypass is not in the system at all. The rules must be documented before the release strategy can be reconfigured.

Delivery block logic

A warehouse reports unpredictable delivery blocks. Discovery reveals: incomplete address blocks delivery for all customers; credit hold blocks delivery for non-cash customers; specific material groups (hazardous, cold chain) require special handling and block standard delivery. The current system checks address and credit but not material group. The material group rule is enforced by a warehouse clerk manually checking a paper list. The rules must be documented so the system can be extended or the manual check can be governed.

Inputs required

• Current system configuration showing where rules are enforced: workflows, validation routines, condition tables.
• User interviews with people who apply, override, or suffer from the rules.
• Regulatory documents or compliance frameworks that mandate specific rules.
• Incident tickets showing where rules were violated or produced unexpected results.
• Existing procedure manuals, policy documents, or training materials.
• Master data samples showing how rules affect different record types.
• Workflow logs or approval history showing override frequency and approvers.

Questions to ask

• What conditions must be true for this action to happen, and what conditions prevent it?
• Who can override this rule, under what conditions, and what evidence is required?
• What happens when two rules conflict? Which one takes precedence?
• Where is this rule enforced today: system, manual check, spreadsheet, or unwritten habit?
• What is the business consequence if this rule is not followed?
• Which rules are written down and which exist only in people's heads?
• When did this rule last change, and who authorized the change?
• Which rules are enforced by the system but no longer match business policy?

Working method

1. Identify decisions in the process. Look for points where the path splits: approve/reject, block/release, calculate price, assign category.
2. For each decision, list conditions and outcomes. Format: "If [condition] and [condition], then [outcome]." Be specific about field values, thresholds, and dates.
3. Separate business rule from system implementation. The rule is the intent. The implementation is how a specific system enforces it. Document both, but separately.
4. Identify rule owner and override authority. Who can change the rule? Who can override it? What evidence is required for override?
5. Map where the rule is enforced and where it is missing. Use a matrix: rule vs system. Mark enforced, partially enforced, manual, or missing.
6. Document conflicts between rules. When two rules produce different outcomes for the same conditions, record both and flag for governance decision.
7. Validate with the rule owner. Walk through each rule, condition, and outcome with the person who has authority to change it.
8. Document in a Business Rules Catalog. One entry per rule. Include conditions, outcomes, owner, enforcement map, override conditions, and related rules.

Decision rules

• If a rule exists only in a user's head, it is not a rule until documented and validated with the owner.
• If two rules conflict, document both and flag for governance decision — do not silently pick one.
• If a rule is enforced in code but not documented, the rule is at risk of being lost in the next upgrade.
• If a rule has no owner, it is a governance gap, not a technical gap.
• If a rule is violated in more than 5 percent of transactions, either the rule is wrong or the enforcement is broken.
• If a rule can be overridden, the override conditions must be as explicit as the rule itself.
• If a system enforces a rule that contradicts current business policy, the system is out of date, not the business.

Deliverables

• Business Rules Catalog — One entry per rule. Contains conditions, outcomes, owner, enforcement location, override conditions, and related rules. See template below.
• Rule Ownership Matrix — Table mapping each rule to its business owner, technical implementer, and override authority.
• Conflict Register — List of rule conflicts with business impact and governance decision status.
• Enforcement Gap List — Rules that are documented but not enforced in any system, with proposed enforcement mechanism.

Templates

Business Rules Catalog entry (compact)

---
artifact: Business Rules Catalog Entry
id: BR-001
status: draft | reviewed | approved
---

## Rule name


## Conditions


## Outcomes


## Business owner


## Override authority


## Enforcement location


## Enforcement status


## System implementation


## Violation handling


## Related rules


## Last validated

Quality checklist

• Every rule has explicit conditions and outcomes.
• Every rule has a named business owner who can authorize changes.
• Rules are separated from current system implementation.
• Override conditions are documented, not assumed.
• Conflicts between rules are flagged with governance status.
• Enforcement locations are mapped for every rule.
• Rules are validated with owners, not just inferred from system behavior.

Common mistakes

• Documenting system behavior as business rules. Consequence: rules are tied to current system limitations. The new system inherits old constraints that were technical, not business.
• Failing to identify override conditions. Consequence: exceptions break processes because no one knows who can approve them or what evidence is required.
• Ignoring rule conflicts. Consequence: unpredictable outcomes when two rules apply to the same situation. Users develop private workarounds.
• Not identifying rule owners. Consequence: rules change without authority, or stale rules persist because no one is responsible for updating them.
• Missing tacit rules that exist only in people's heads. Consequence: new systems omit critical logic that was never written down. Business operations degrade after go-live.

Agent instructions

AI agents should use this skill to extract and document business rules before recommending system changes, integrations, or automation.

• Start with decisions, not systems. For each decision point in a process, ask what conditions lead to what outcomes.
• Separate the business intent from the current system implementation. Document both, but in separate fields.
• Identify who can change the rule. If no one can, flag a governance gap.
• Document override conditions explicitly. Who can override, what evidence is required, and how the override is logged.
• Flag conflicts between rules instead of resolving them. Document both rules and ask who has governance authority.
• Map where each rule is enforced. Use a matrix: rule vs system. Mark enforced, partial, manual, or missing.
• Produce a Business Rules Catalog entry per rule. Validate every entry with the named owner.
• Do not infer rules from system behavior alone. System behavior may be a bug, a workaround, or outdated configuration.
• Link to Atlas diagnostics when rules relate to SAP validation. For example, delivery block rules should reference SAP Delivery Block Analysis.

Related skills

• Requirements Elicitation Working Skill
• Process Analysis Working Skill
• Acceptance Criteria Working Skill
• Data Governance Working Skill

Related Atlas pages

• SAP Credit Management Diagnostics — Rule context for credit limits.
• SAP Release Strategy Diagnostics — Approval rule context.
• SAP Delivery Block Analysis — Block rule context.
• Master Data Issues Blocking Sales Orders — Rule violation scenario.

Verification status and limitations

This skill is a public working interpretation of business rules discovery practices. It is not official BABOK, DMN, or SAP documentation. It focuses on operational decision logic in enterprise systems and may not cover complex decision models or predictive analytics rules.

Known limitations: the skill assumes access to rule owners and system configuration. In environments with high turnover or poor documentation, rule discovery becomes archaeological work. The skill does not cover formal decision model notation (DMN) or business rules management systems (BRMS) implementation.