Modeling real-world things requires a layered approach for processes -- recursive decomposition of high-level processes into lower-level processes.  Does the same apply to rules?  Is recursive decomposition of rules possible?  If so, would such recursive decomposition of rules ever lead to lower-lever processes?  Would recursive decomposition of processes ever lead to lower-lever rules?

I believe the answers to all these questions is no.  Processes are processes, and rules are rules.  They are not the same.  A fundamental principle of the business rule approach is that each is a primitive.  Formally, one primitive can never decompose to another primitive.  So processes never decompose into rules, and rules never decompose into processes, at least within the horizon of interest to the business problem.  (What happens at the implementation level may be a different matter, but that's a platform issue.)

Aside:  Higher-level business logic (e.g., policies) does usually need to be translated into more atomic rules, but this analytical process follows different patterns and guidelines than for recursive decomposition of processes.  We therefore use the term reduction (instead of decomposition) for transforming high-level business logic to lower-level form.

An implication of this view is that it is never really accurate to say that policies and rules are innately inside processes.  (You might "find" them there, but that is an artifact of presentation or methodology -- not something inevitable in the natural scheme of things.)  CEOs set policies, then managers create business processes.  Or consultants create business processes, and managers establish policies and rules.  This can happen in either order (or at the same time), but the processes nonetheless remain processes and the rules remain rules.

Consider the playbooks and the rulebook of the National Football League.  Do you see the rules in the playbooks, or the plays (processes) in the rulebook?  No.  Each stands on its own.  Works out very well that way too, I might add!

All bets are off on these questions, of course, if you cross over into a new perspective (row in Zachman terms).  For example, in creating a technical design at the class-of-platform perspective (row 4), you might decide to treat a rule as a process (or vice versa), but that's are entirely different matter.  That's a design decision -- not something innately true about rules and processes.  And by the way, given the power of rule engines these days, it's not even a particularly good design decision!

# # #