This content has been marked as final. Show 5 replies
The answer depends a lot on the source material you are using for your project.
Are the rules based on existing legislation, regulations, a policy manual etc.? If so, the best practice is to use this material as the starting point for the documentation. Adding too many intermediate transformative steps can increase effort and reduce the mapping from source material to the natural language/tabular OPA rules.
The answer may be different if the rules have not previously been documented.
One approach some customers use is to use the same logical structure that OPA uses to define the rules in a visual tree form. This is not a decision tree (where the decsions are at the leaves), rather it is the same top-down "this decision is reached if..." structure, where for each node the children are connected with either "and"s or "or"s. These forms then translate easily into the actual rule documents, and it has the advantage of "poking holes" just as effectively as it would if you were actually modeling the rules in OPA.
Another approach that works well is to co-develop the rules in a more agile fashion with the policy expert and rule author working side-by-side. Then there is no intermediate step.
In this case, it's also easier to capture test cases with expected results as you go.
If you're thinking about design, here are two documents you may want to peruse:
Guide to Designing a Policy Model: http://www.oracle.com/technetwork/apps-tech/policy-automation/learnmore/opaguidetodesigningapolicymodel-1531936.pdf
Best Practice Guide for Rule Developers: http://www.oracle.com/technetwork/apps-tech/policy-automation/learnmore/opaguidetodesigningapolicymodel-1531936.pdf
One that I'm thinking of uses "if" on the line directly below the decision node, then puts either "and" or "or" simply as separate text floating half-way between each pair of sibling nodes.
To mirror OPA, for each set of siblings make sure to use either ANDs or ORs, not a combination of both.