Extracting ODRL Policies from Business Process Models: A Graph Traversal Approach to Compliance-by-Extraction

Imagine a world where every time you walk into a store, a robot guard checks your ID, your shopping list, and your budget before letting you pick up a single item. That robot isn't just guessing; it's following a strict rulebook written by the store owner. In the digital world, this rulebook is called a "policy." It tells computers what they are allowed to do, what they must do, and what they are strictly forbidden from doing. For a long time, writing these digital rulebooks has been like trying to build a skyscraper by hand, one brick at a time. It's slow, it's prone to human error, and if you get one brick wrong, the whole structure might collapse.

Enter the concept of "compliance." This is the fancy word for making sure everyone follows the rules. In the business world, companies spend years drawing out maps of how their work gets done. These maps are called Business Process Models (BPMN). Think of them as the blueprints for a factory or the script for a play. They show who does what, when, and in what order. The big question scientists have been asking is: "If we already have these detailed blueprints, why do we have to write the rulebook all over again?" The blueprints already contain the rules; they just speak a different language. This paper is about building a translator that turns those blueprints directly into a modern, machine-readable rulebook, so we don't have to write the rules twice.

The Magic Translator: From Blueprints to Rules

The authors of this paper, a team of researchers from Spain and Italy, have built a clever pipeline that acts like a digital detective. Their job is to look at a company's process map (the BPMN file) and automatically extract the hidden rules inside it, turning them into a format called ODRL. You can think of ODRL as the "universal language" for digital rights and rules, a standard that computers everywhere can understand.

Here is how their "detective work" works, broken down into simple steps:

1. The Blueprint is Already a Rulebook
The researchers realized that the way a process map is drawn actually is a set of rules. If a map shows that a worker must check an order before shipping it, that's a rule called a "Duty." If the map shows a worker can skip a step if a certain condition is met, that's a "Permission." If the map shows a worker cannot move forward until a specific event happens, that's a "Prohibition." The problem is that these rules are locked inside the drawing. The new pipeline unlocks them.

2. The Graph Traversal (The Maze Runner)
The team's software treats the process map like a maze. It uses a technique called "graph traversal," which is basically a systematic way of walking through every path in the maze to see what happens.

• The "Must-Do" Check: The software asks, "If we remove this task, can the process still finish?" If the answer is "No, the process stops," then that task is a Duty (a must-do).
• The "Can-Skip" Check: If the task is on a path that isn't always taken, it's a Permission.
• The "Wait" Rule (The Big Discovery): This is where the paper gets really clever. In older methods, if a process had to wait for an email or a signal (called an "intermediate catch event"), the rule was often ignored or treated as a simple delay. The authors argue this is wrong. They say, "If you are waiting, you are actually forbidden from moving forward until the signal arrives." So, they invented a new way to label these moments as Prohibitions with a "lifting constraint." It's like a red light that only turns green when a specific car (the event) passes by.

3. The Output
After walking through the maze, the software spits out a clean, valid rulebook in a format called JSON-LD. This is a file that computers can read instantly. The best part? The company didn't have to write a single new rule. The software just pulled the rules that were already hiding in their existing maps.

What They Found (and What They Didn't)

The team tested their translator on five different "benchmark" scenarios, ranging from a simple "Dispatch of Goods" process to a complex "Self-Service Restaurant" with three different people (pools) interacting.

• The Success: In all five cases, the software successfully turned the maps into rulebooks without crashing. It correctly identified who had to do what, who could skip steps, and who had to wait. For example, in the "Credit Scoring" scenario, it figured out that a bank must request a score, but a scoring service cannot compute the score until the data arrives. It even handled the tricky "waiting" rules perfectly, labeling them as prohibitions that lift when the event happens.
• The Limits: The paper is honest about where the magic stops.
  • Loops: If a process has a loop (like a customer trying again and again), the software simplifies it. It treats the loop as a single "must-do" task, which is safe but loses the nuance of "repeating until successful."
  • Names: Sometimes the maps don't have names for the people involved (like "Bank" or "Clerk"). In those cases, the software just uses generic labels like "Participant_1," which makes the rulebook a bit hard for humans to read, even though the computer understands it perfectly.
  • Complex Timing: The software can't yet express complex timing rules like "Task A must finish exactly 5 minutes before Task B starts." It captures the order, but not the precise timing.

Why This Matters

The paper doesn't claim to have solved every problem in the world of rules. It doesn't say this is the final, perfect solution. Instead, it proves that a specific, automatic way of turning process maps into rulebooks works.

Before this, if a company wanted to be compliant with new laws (like data privacy rules), they had to hire experts to manually write thousands of policy documents. This was slow and expensive. If the company changed their process, they had to rewrite the policies. This new approach suggests that if you change your process map, the rulebook updates itself automatically. It creates a direct, auditable link between what a company does and the rules it follows.

The researchers are careful to note that while their method works great for standard process maps, it still needs more work to handle complex loops and precise timing. But for now, they have shown that the rules are already there, hiding in plain sight, waiting for a translator to set them free. It's a step toward a future where compliance isn't a paperwork nightmare, but a natural byproduct of how we design our work.