Why can a change to De Morgan’s Law alter J1QL query results?

A change to De Morgan’s Law changes how negation is distributed across grouped conditions. In practice, a query written as not equal to a set of values no longer behaves like separate not equal checks joined together. That can widen or narrow results, so teams should revalidate saved queries whenever the logic engine changes.

How a Logic Rewrite Changes the Shape of the Result Set

De Morgan’s Law is a rule about how negation moves across grouped conditions. In a query engine, that matters because the engine may interpret a single negated set differently from a series of separate exclusions. Once the logic is rewritten, the effective filter can change from “exclude this whole group” to “exclude each value independently,” which can change who or what remains in the result set.

This is why the same-looking query can return a different population after a change in the evaluation engine. A saved query is not just text, it is logic with operator precedence, grouping, and negation behavior. If the engine changes how it applies those rules, the query can widen unexpectedly or become more restrictive without any visible syntax change.

In practice, the key issue is semantic drift. A rule that used to behave like a grouped exclusion may be normalized into a logically equivalent form only under one interpretation of the law. If the implementation changes, the set algebra behind the query changes with it, and previously reliable filters may no longer match the same records.

Why Set Logic Matters in Saved Queries

Most query systems are evaluated by a parser and optimizer before results are returned. That means the final result depends on how the system groups conditions, distributes negation, and resolves precedence between AND, OR, and NOT. A small change in that evaluation path can produce a different answer even when the visible query string appears stable.

This is especially important when a query is used for alerts, reports, routing rules, or access decisions. If the query is meant to exclude one set of values, but the engine changes the way it interprets the negation, the output can include records that were meant to be filtered out, or exclude records that were meant to remain. The issue is not the mathematical law itself, but the implementation choice about how that law is applied to query syntax.

Teams often discover the problem only after comparing old and new results side by side. That is why the safest assumption is that any change to query evaluation semantics is a breaking change for saved logic, even if the vendor describes it as a correction or an optimization.

What Practitioners Should Revalidate After an Engine Change

When a query engine changes its handling of negation, the most important check is not whether the query still parses, but whether it still selects the same records. Saved queries should be re-run against known data sets and compared to a baseline so that widened or narrowed filters are visible before they affect production workflows.

If the query controls an operational process, treat result drift as a change-management event, not a cosmetic difference. A filter used for security triage, entitlement review, or operational routing can silently alter downstream decisions even when the query definition has not changed. That makes regression testing more valuable than syntax review alone.

It also helps to rewrite ambiguous expressions into forms that make grouping explicit. Clear parentheses and simpler condition blocks reduce the chance that a future engine update will change meaning through a different negation strategy. Where possible, store representative test cases alongside the query so the intended behavior is preserved over time.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST CSF 2.0, NIST SP 800-53 Rev 5 and OWASP ASVS set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
NIST CSF 2.0	ID.IM-01 — Improvements are identified and managed	Query logic changes require review of outcome drift and follow-up fixes.
Recommendation — Track query-semantic changes as control improvements and validate intended output after each engine update.
NIST SP 800-53 Rev 5	CM-3 — Configuration Change Control	A query engine change can alter saved query behavior and needs controlled review.
	AU-6 — Audit Record Review, Analysis, and Reporting	Result drift in saved queries should be detected by comparing expected and actual outputs.
Recommendation — Subject logic-engine changes to change control and regression testing before production release. Review query outputs against baselines to spot unexpected semantic drift after upgrades.
ISO/IEC 27001:2022	A.8.32 — Change management	Changes to query evaluation semantics are software changes that can affect controlled results.
Recommendation — Assess query-engine updates through change management and verify affected logic paths.
OWASP ASVS	V8 — Authorization	When queries drive access or filtering decisions, altered logic can change authorization outcomes.
Recommendation — Re-test permission or filtering logic whenever query semantics change.

Practitioner Guidance

What to verify: Compare the old and new result sets against a fixed sample of records, especially where the query uses negation around grouped values. If the output changes, confirm whether the difference is intentional or a regression in logical interpretation.

Common mistake: Treating a parser or engine upgrade as safe because the query text did not change. For logic-heavy saved queries, the engine version is part of the control surface.

Decision rule: If the query governs an alert, report, or workflow, require regression testing before release; if it only supports ad hoc analysis, a result shift still needs explanation, but the operational risk is lower.

Practitioner takeaway: Query correctness depends on both syntax and semantics, so any change in how negation is distributed should be treated as a potential change in business meaning, not just a technical refactor.