Before any agent logic gets written, before we touch the integration layer or configure a single workflow, we do a rule mapping session. This is the first substantive working meeting of every dodoAI engagement, and it's where we most often discover that the organization's documented policies and its actual operating practices are not the same thing.
The gap isn't surprising. Policy documents are written at a point in time, often by someone who no longer works at the company, to describe an ideal process. The actual process evolves to handle exceptions, accommodate specific relationships with certain vendors, work around ERP limitations, and reflect the informal authority of particular individuals. Over time, the document and the practice diverge. Nobody updates the document because the informal version "just works." Then someone tries to automate the documented version and wonders why the agent keeps flagging things that humans approve without question.
Rule mapping is the process of surfacing that gap and resolving it before it becomes an agent configuration problem.
What We Ask For Before the Session
We ask the customer to provide three things before the rule mapping session: the current written policy document for the process we're automating; an export of the last six to twelve months of transaction data showing actual decisions (approved, rejected, escalated); and access to the primary person who makes approval decisions day-to-day.
The transaction history is essential. It lets us compare what the policy says against what actually happened. If the policy says "all purchases above ¥500,000 require department head approval," but the data shows that 40% of approvals above ¥500,000 went through without a department head sign-off, something is wrong — either the policy isn't being enforced, the thresholds are applied differently in practice, or there's a category of exception not captured in the document.
The person who does approvals daily is more valuable than the policy document. They know the real logic. They know which vendors have special treatment, which categories have different rules, which managers can override, and what the company's actual risk tolerance is for different types of purchases. The policy document is a starting point. The practitioner interview is where you get the real specification.
The Rule Mapping Session: What Actually Happens
The session typically runs two to three hours, sometimes spread across two meetings if the process is complex. We go through the policy document section by section, but we spend most of the time on the practitioner interview rather than the document.
We ask three types of questions. The first type is definitional: "What does 'department head approval' mean exactly — is that the direct manager of the requestor, the manager of the cost center being charged, or both?" Policy documents use organizational terms that seem unambiguous until you realize that organizational structure and cost center ownership don't always align. A request from the marketing team charging a budget owned by the regional sales director involves at least two different hierarchies.
The second type is boundary exploration: "What happens when a request is for ¥498,000 — do approvers treat that the same as a ¥600,000 request or differently?" Threshold-adjacent behavior reveals whether the threshold is a hard rule or a soft guideline. We've seen situations where the formal threshold triggers one approval level, but anything within 5% of the threshold gets voluntarily escalated because the approver doesn't want to be in a gray area. That informal behavior needs to be captured in the rule set or the agent will handle threshold-adjacent cases differently than humans do.
The third type is exception mapping: "When was the last time you approved something that violated the standard policy, and why?" Exceptions reveal the decision-making logic that the policy doesn't capture. Common exception categories we see in Japanese manufacturing environments include: approved vendors who have a longstanding relationship and receive faster processing; emergency purchases under time pressure where normal approval chains are compressed; and purchases from group companies that have different documentation requirements than external vendors.
Common Gaps We Find in Every Engagement
After several engagements, certain types of policy gaps appear reliably. We're not saying these represent poor policy design — they represent normal organizational drift that any well-run company should expect.
The first common gap is threshold currency misalignment. Approval thresholds in Japanese companies are almost always expressed in yen, and they're often set in nominal terms that haven't been adjusted for inflation or business growth. A ¥1,000,000 approval threshold set in 2012 represents a meaningfully different percentage of operating budget in 2025 than it did when written. The practical effect is that the formal approval process involves more items than it should, creating a backlog that forces informal workarounds. When we implement the literal policy, the approval queue overloads and operations stop. We flag this and recommend a threshold review before implementation.
The second common gap is undefined escalation paths. Policies say "escalate to senior management" without defining who "senior management" is, what information they need to approve, or what turnaround time is expected. In a manual process, someone picks up the phone and calls a specific person. In an automated process, the agent needs an explicit escalation target, a defined information package, and a timeout rule for non-response. All of that has to be defined before we can configure escalation behavior.
The third common gap is missing negative conditions. Most policy documents are written as permission trees: "if X, then approved; if Y, then requires escalation." They often don't explicitly enumerate conditions that should trigger rejection. In practice, approvers have mental rejection criteria — "if the vendor tax registration number looks wrong, reject it" — that never made it into the written document. The agent has no way to apply rules that aren't specified. Eliciting the rejection criteria explicitly is a significant part of the rule mapping work.
The fourth common gap is cross-document inconsistency. Large organizations often have multiple policy documents that touch the same process: a procurement policy, a spend authority matrix, a vendor qualification policy, a separate policy for IT purchases. These documents are maintained by different teams and are frequently inconsistent with each other. The procurement policy may say purchases above ¥3,000,000 require board approval, while the spend authority matrix says the CFO can approve up to ¥5,000,000 unilaterally. Which document governs? In a manual process, a person would recognize the conflict and ask. An agent needs an explicit hierarchy of authority.
The Rule Model We Use
We represent rules as a structured YAML configuration that the agent runtime reads. Each rule has an identifier, a condition expression, an action, a priority (for conflict resolution), and a version timestamp. A simplified example for a procurement approval rule looks like this:
rule_id: PROC-APPROVE-001
version: 2.1
effective_from: 2025-04-01
condition:
all:
- field: request.amount_jpy
op: lte
value: 500000
- field: vendor.qualification_status
op: eq
value: APPROVED
- field: request.category
op: not_in
values: [IT_HARDWARE, PROFESSIONAL_SERVICES]
action: AUTO_APPROVE
priority: 10The condition structure supports AND/OR/NOT combinations and can reference any field exposed by the process context — request metadata, vendor master attributes, requestor organizational hierarchy, historical transaction data. The YAML format is intentionally readable by non-engineers: the customer's procurement manager should be able to read a rule and confirm it matches their intent. If they can't read it, we've failed in the translation.
Rule sets are versioned. When a policy changes, we create a new version of the affected rules with an effective date. The decision log references the rule set version that was active at the time of each decision, so historical audit queries can replay decisions against the policy that was in effect at the time.
Validation Before Deployment
Before any agent goes live, we run the configured rule set against the historical transaction data. This produces a comparison: for each historical transaction, here is what the agent would have decided under the new rule set, versus what actually happened.
A 100% match rate is not the goal — it would mean the agent is replicating historical decisions including all the informal exceptions and inconsistencies. The goal is a match rate that the customer's policy owner considers reasonable, combined with clear categorization of every mismatch. Mismatches fall into three categories: the agent is more conservative than history (which may be correct if past approvals were policy violations), the agent is more permissive than history (which requires explanation — is the historical restriction accurate or was it excessive caution?), or the agent's decision is genuinely ambiguous under the policy as written (which requires a policy clarification before deployment).
This validation step is the point at which we most often find that the rule set needs revision. The exercise is valuable regardless — it forces a concrete conversation about what the policy actually means in the context of real transactions, which is more productive than an abstract discussion about policy intent.
Rule mapping is not glamorous work. It involves a lot of document reading, careful questioning, and the organizational patience to surface disagreements about what the policy actually says. But it's the step that determines whether an agent deployment succeeds or fails. An agent with perfect reasoning but a misspecified rule set is worse than no agent at all — it's wrong with confidence. Getting the rules right before deployment is where the real value is created.