Chapter 08 · Rulesets

Technical reference · Chapter 08

Rulesets

Purpose

Rulesets control how ConfigCompare interprets comparison results.

They help organisations reduce noise, focus attention, classify importance, and assign Responsibility for both Differences and Matches.

This chapter describes concepts and behaviour; step-by-step operating guidance sits outside this reference.

Why Rulesets matter

A raw comparison can produce many results. Not every Difference or Match has the same importance.

Differences vary in importance and ownership: some are expected or harmless, others deserve escalation, and different results belong to different teams such as finance, supply chain, or security.

Similarly, some Matches are expected and desired. Others represent problematic similarities that should not exist (see the Flagging undesired Matches section in this chapter).

Rulesets provide the policy layer that turns comparison output into governed review, elevating both important Differences and undesired Matches.

Hierarchical rules

A Ruleset is a hierarchy of rules. Each rule maps the comparison results (Same AB, Diff AB, Only A, Only B; see Chapter 05: Comparison Engine) to an assessment severity, and can assign Responsibility.

The levels, from least to most specific:

Global: default assessments for the four result types, plus dedicated rules for the system columns that exist on every table (created and modified users, timestamps, and record identifiers), which are typically set to Ignore.
Company: overrides for one company. A common use is taking an entire company out of scope, such as an empty template company or a company owned by a different governance regime.
Table: overrides for one table. This is the most heavily used level: it tunes severity per table and routes ownership per table through Responsibility.
Table and company: overrides for one table in one specific company, for example a pilot or live company where the same table deserves extra scrutiny.
Column: overrides for individual columns within a table rule. Column rules carry only Same AB and Diff AB: a field can only be compared when its row exists in both Snapshots, so whole-row results (Only A, Only B) are decided by the broader rule levels.

The most specific applicable rule wins. For a given field in a given row, rule resolution walks from Column, to Table and company, to Table, to Company, to the Global default, adding the assessment level to the result along with the corresponding Responsibility.

Rules can also carry a short note. The note is copied to the results the rule classifies, so reviewers see the rule’s rationale alongside each assessed result.

Responsibility

Rulesets assign Responsibility to comparison results. Default Responsibility, defined on the Ruleset, is a fallback that separates the assessments produced by existing rules from the results that may need new rules.

Without explicit Responsibility assignment, comparison results lack clear ownership and may be overlooked or reviewed by the wrong stakeholders.

Responsibility can be assigned by:

Module (Finance results → Finance Team)
Company (USMF results → USMF Administrator)
Table (GL Account results → Accounting Manager)
Column (Payment Gateway results → Security Team)
Business process (Intercompany reconciliation results → Treasury)
Role (High-risk changes → Compliance Officer)
Governance owner (critical configuration areas → Data Steward)
Custom criteria (combinations of these criteria)

With Responsibility assigned:

Each result has a clear owner
Results reach the right stakeholder
Governance accountability is maintained
Reviews happen with appropriate expertise
Response SLAs can be defined and tracked

Noise reduction

Rulesets can control the volume of comparison results.

This is important for daily or Scheduled Comparisons. Over time, organisations can refine rules so that routine comparisons become quieter and more focused (see the adoption pattern in this chapter).

Starting from zero

ConfigCompare does not ship with a library of predefined Rulesets, because which Differences and Matches matter, how severe they are, and who should review them are organisation-specific judgements; a generic rule library would encode someone else’s priorities.

Instead, Rulesets are built progressively from real comparison results.

Adoption pattern: from noisy to focused

A first comparison over a meaningful scope produces many results. The recommended way to start is iterative and result-driven rather than designed up front:

Capture a baseline and run a real comparison.
Triage the results: identify what matters and what never will.
Set rules directly from real findings: promote the severity of results that deserve attention, assign Responsibility, and set expected or immaterial results to Ignore.
Repeat. Severities and Responsibility accrete with each review cycle.

Routine Scheduled Comparisons become progressively quieter and more focused, until daily runs surface only results above the organisation’s attention threshold. Noise reduction is an outcome of using the platform, not a prerequisite for starting.

Flagging undesired Matches

Rulesets are often associated with Differences, but they are equally applicable to identifying problematic Matches.

The Match concept, and the canonical Production-Endpoints-in-UAT example, are described in Chapter 03: Core Concepts. Many Matches are expected and correct, but some represent configuration that should differ.

Examples of undesired Matches:

Production Endpoints appearing in UAT (environment isolation issue)
Production data warehouse URLs in test environments
Live payment gateways configured in sandbox systems
Sensitive API credentials identical across environments

Rulesets can be configured to flag these undesired Matches with high severity, so that configuration similarities that should not exist are escalated and reviewed with the same attention as severe Differences.

Severity and attention

Rules classify results using an eight-level assessment scale. From most to least severe:

Emergency, Escalations, Exception, Deviation, Concern, Notice, Insight, Ignore.

Ignore suppresses a result from assessment output entirely. Assessment counts roll up through the comparison result grids, so attention concentrates where severity is highest.

A common progression is severity promotion: results default to a moderate severity, and a table is promoted, for example from Notice to Deviation, once the organisation decides that any change there deserves a heightened response.

Ruleset patterns

Several idiomatic patterns fall out of the rule hierarchy:

Moderate table severity with escalated columns: a table rule sets a moderate severity for general change, while named column rules escalate far above it. Bank details may change at Notice severity, but a SWIFT code change is an Emergency.
Suppress immaterial fields: a table rule keeps its severity, but column rules drop immaterial fields such as cosmetic name changes to Ignore. This is the primary tool against alert fatigue at field level, complementing the global system-column rules.
Inverted Rulesets: global defaults are all Ignore, and table rules make Same AB the severe result for environment-specific tables such as email settings, payment gateways, and batch schedules that must differ after a Production database is restored into a downstream environment. For these tables the Match is the finding: an unchanged value after a refresh is the problem, and a Difference confirms the remediation was applied. This is the Ruleset expression of undesired Match flagging (see Flagging undesired Matches).
Scoped Rulesets: global defaults are all Ignore, and only the tables of one functional domain carry active rules. The Ruleset is silent about the entire configuration surface except its named scope, supporting module-focused governance such as a finance-only Ruleset.

Relationship to AI Insights

AI Insights can use Deterministic Comparison results and Ruleset context to generate more useful summaries.

Rulesets help AI Insights identify which changes need attention first and which responsible groups may need to review them.