Rules Help

PPDM Rules Help

PPDM Data Rule

A data rule is a statement that provides the opportunity to validate compliance to expected conditions or to identify and review exceptions. It always resolves to either true or false. Data Rules are intended to ensure that a program operates on accurate and useful data providing higher user confidence in the quality of the data. Data rules apply to data and information, not workflows and processes. They provide a method to define specific tests, validations or constraints associated with data items. Data rules are atomic; they each check one thing.

PPDM Business Rule

A Business rule is a statement that defines or constrains some aspect of the business. Business rules describe the operations, definitions and constraints that apply to an organization and are put in place to help the organization achieve its goals. Business rules can apply to workflow, policies, procedures, regulatory compliance, computing systems, individual behavior or corporate behavior in an organization.

Conformance to a business rule must be measured by determining whether the necessary processes have been applied to data and information. Business rules is a grouping of data rules by describing how to assert business structure or control or influence the behavior of the business. A business rule will contain one or more data rules, and data rules will be contained in more than one business rule.

PPDM Metadata Rule

A metadata rule is a statement that provides the opportunity to validate the information about a data record in terms of compliance to expected conditions or to identify and review exceptions.

A metadata rule has the same purpose and design as a data rule, but is aimed at the data record rather than at the real-world object.

Metadata is “data about data”. Metadata rules apply to the database row (record). For example, row created date must not be null; published date is greater than created date.

Rule Statuses

  1. Draft You have saved the rule as draft. Nobody else can see the rule. This status is only used for a rule being created online with the Rules application.
  2. Submitted The rule has been received by PPDM, through the Rules application or as an email. It is waiting to be assigned to an Editor.
  3. In Progress An Editor has been assigned to examine and classify the rule, check for duplicates, etc. The Editor may consult with a relevant subject matter expert. You will be informed if changes are made.
  4. In Review The Editor has approved your rule and moved it into the public review process.
  5. Published The rule has gone through the public review process with no challenges, or has cycled back through the author / editor / review process and is now published. Any subsequent changes to the rule will be noted in the Discussion (Comments).
  6. Deprecated The rule has been removed from the published list and is no longer recommended. This may be because it is has been replaced by another rule, or because it was successfully challenged as inaccurate or not useful.

Rule Dates

The metadata for each rule includes the following dates related to status.

  1. Created on: This is the date when the rule was created in the Rules application. If the rule was submitted by another method (email), the created date may be blank or equal to the Submitted Date.
  2. Submitted on: This is the date when the status changed to Submitted.
  3. Review started on: This is the date when the status changed to In Review. It is the start of the open review period.
  4. Published on: This is the date when the status changed to Published.
  5. Updated on: This is the date when a rule’s data field (e.g. statement, diag_exceptions) was amended. This could be a change in wording or the addition of more supporting content. A comment in the Discussion tab explains the reason for the edit. A comment alone does not trigger the update date. A change of status (e.g. from In Review to Published) does not change the updated on date.

Rule Discussion

Anyone may add a comment about a rule the Discussion tab on the Rule Viewer page. We welcome comments about the wording of a rule Statement, the business value of the rule, or any of the Description items that support the understanding and application of the rule.

An editor or administrator must add a comment to explain a change to a Published rule.

A comment is also required if the rule Statement is changed during In Review status.

Quality Dimension

Quality can be assessed in several ways based on certain expectations about how the information describes a real thing (object or event). In the information management world, there is no standard or consensus on what quality dimensions are necessary or how the terms are defined. The PPDM Rules use the following defined terms.

ACCURACY The record must conform to the real world object or event. E.g. top depth less than base depth. The opposite is meaningless or garbled: the thing reconstructed from the data is ridiculous.

COMPLETENESS The data is part of the minimum set of information that is necessary to describe the real thing. E.g. if top depth is missing, an interval cannot be described. The rule is usually a "not null" check.

CONSISTENCY There is no conflict in how two records describe the same object or event. E.g. well record says ABD but production record says it's producing. This comparison may be within one record or between two data sets. The opposite is ambiguous: you can construct the real thing in 2 different ways and you don't know which one is right.

UNIQUENESS There is no duplication. E.g. one well cannot have two locations; one location cannot have two wells. The rule should make allowance for different sources, versions, etc. of course.

VALIDITY The record value is in the accepted format and range. The range could be numeric or a text list (e.g. status codes). The set of values may be adjusted to suit local conditions, e.g. a location in the State of Colorado (USA) must have a latitude of 37 to 41 degrees.

Note: Timeliness is another important quality dimension. However, it is not used for PPDM rules because the measure of timeliness is highly dependent on the business requirements of the data. For example, UPDATE_DATE must be less than 1 month after SPUD_DATE might satisfy most business units but the drilling department might require timeliness of 1 day or 1 hour for some wells. Timeliness may be evaluated with a business rule (not a data rule).


Subject areas (categories) are a high-level classification of E&P information. They are based on the published roadmaps for the PPDM 3.9 data model.

Subjects available for filtering are limited to those used in published rules. As new rules are contributed, more Subject choices will be added. With additional subjects, some existing rules may be re-classified.

Wells General information, depths, dates, directional surveys, logs, tests, cores, interpretations, drilling and completion operations, etc.

Land Rights General information, authorizations, status, acquisition, interests

Seismic Acquisition, processing, licenses, transactions, interpretations

Production Fields, pools, units, production strings, reporting

Spatial Information about areas, parcels, fields, units, coordinate systems, etc.