Business Rule Life Cycle

What are the States for a Business Rule? Business Rules are more "real" than requirements in that decisions get made in the production environment based on a Rule. Sarbannes-Oxley type of seriously is applicable, whereas requirements are subject to a lot of manipulation and interpretation. Here are States we propose for an upcoming project. We encourage your reactions:
Candidate - these are nominations. They may come from new legislation or harvested from a legacy application. Rules discovered from Legacy applications are a different type of Candidate than a Rule proposed as a result of newly enacted legislation (or Board action or Audit Exception finding). Harvested rules are already in Production. But we don't really know if the Rule is correctly implemented or even widely understood. Therefore, harvested Rules require as much scrutiny as newly proposed Rules. Comments encouraged on this premise.

Clarified - The initial wording from the Candidate is re-stated based on templates or peer review.

Articulated - The Rule has gone through a Business rule authoring tool -- preferably.

Verify - This is a combination of authenticating the source of the rule (legislation, board action) AND testing of the Rule -- preferably by the Articulation production.

Approved - This might be an overly bureaucratic step that implies that after documenting the Verification that someone must Approve the Rule.

Versioned - The Rule goes into configuration management.

Build - The Rule is translated into a programming language either through a Tool or through the work of the Developer.

Tested - The Developer has conducted Unit and String Testing. String Testing includes combining the Rule with Rules executed in conjunction with the Rule.

Orchestrated - The Rule is part of an Orchestration intended for Deployment for Production. It is ready for System Testing and Unit Testing. It is not necessary to log the success of the Rule in these types of testing. If a defect is found, the orchestration goes through modifications to determine if it is the rule or the orchestration that is at fault. If the defect is in the Rule, then the developer must return the Rule to Verification. There may be a disagreement between the Unit Acceptance Testing participants as to what the Rule is and what the Verification authority determines the Rule to be. This poses an interesting set of problems to track resolution to make certain the User Acceptance folks accept the final decision. But this may mean the Verification authority will have to dissect whether the problem is with the Rule or with the Orchestration.

Deployed - The Rule is in production. Ideally, the Rule management system can track which Orchestrations use the Rule.

If the Rule is deployed in automations other than a Business Rules Engine--in hand coded implementations, then it becomes more important to know where the Rule is utilized. Because if the Rule is modified where accessed by the Business Rules Engine, then there has to be a way of detecting the Rule needs modification in the hand-coded solution(s) as well.

When a hand coded change is made, there has to be a governance process than ensures the Rules Management Repository reflects the change as well. Otherwise, we will have stove piped applications changing Rules that go unnoticed by the governance process and the Rules Repository and the other implementations throughout the Enterprise.