Calculate Data Quality rule success rates based on the filtered/evaluated row count instead of the total underlying table row count.

A customer stores production data in a single large table and applies Data Quality rules only to specific subsets of that data by using SQL WHERE clauses.

Currently, the Data Quality rule success rate appears to be calculated against the total row count of the underlying table instead of the number of rows actually evaluated by the rule. This causes misleading success-rate results when the rule is intended to validate only a filtered subset of the table.

Example:

The source table contains 10,000 rows.
The DQ rule is intended to evaluate only 100 rows based on a WHERE clause or SQL-based subset.
90 rows pass the rule.

Current behavior:
90 / 10,000 = 0.9%

Expected behavior:
90 / 100 = 90%

Example SQL logic:

SELECT *
FROM Teknik.Business.TeknikServisler.Enerji.DigitalEnerjiIkizi.EnerjiEkipmanlari
WHERE tag = 'Root.P-1.U1100.BacaDamperi.AHV101-1.MV.Value'
 AND "value" NOT BETWEEN 35 AND 50;

The current calculation makes the DQ result look much worse than it actually is and does not reflect the quality of the data subset being evaluated.

Expected enhancement:

When a DQ rule is applied to a SQL-based asset, filtered dataset, or rule logic containing a WHERE clause, the success rate should be calculated based on the number of rows actually evaluated by the rule, not the total row count of the underlying physical table.

For filtered or SQL-based DQ rules:

Success Rate = Passed Rows / Evaluated Rows

instead of:

Success Rate = Passed Rows / Total Rows in Underlying Table

Several possible approaches and workarounds were discussed internally, including definition-based rules with if/then expressions, SQL query assets, and profiling record-count behavior. However, these approaches do not fully address the customer’s use case in a clean and scalable way, especially because the customer wants to keep the rule logic compatible with their planned Text-to-SQL automation workflow.

Internal discussion context:
https://ibm-analytics.slack.com/archives/CMBN9DB9C/p1777539461071819