Specify All, Any and Grouped Rules in AI-Written Filters

An AI-written filter can look reasonable while selecting the wrong records. The words all, any, not, except and only describe different relationships between conditions. Before reviewing a generated query or automation, turn the request into a small selection contract: what a record must satisfy, how alternatives are grouped, how unknown values behave and what happens when there are no conditions. This guide develops that contract with original fictional examples. It does not run an AI model, query a client system or approve a production change.

The practical objective is to explain why each example record is included or excluded. A total such as four matches is insufficient when two different filters can produce four different matches. Keep the identifiers with the result. Use the examples to discuss the intended selection with the process owner, then test the actual implementation separately in its appropriate environment. Correct reasoning on a teaching fixture is a limited result, not a guarantee about a business application.

Start with statements that can be evaluated separately

Consider an invented list of work items. Every item has an identifier and two Boolean fields: ready and assigned. For this exercise, ready means exactly the authored ready flag and assigned means exactly the authored assigned flag. Neither flag establishes that a person accepted work, that source evidence is adequate or that any action is authorized. Those are separate business questions. The narrow definitions let us discuss selection without silently giving the flags a larger meaning.

There are four fictional records. R1 is ready and assigned. R2 is ready but not assigned. R3 is not ready but is assigned. R4 is neither ready nor assigned. These four combinations form a complete two-condition truth table. They are deliberately written examples, not records retrieved from an application. Keeping every combination makes it possible to distinguish rules that happen to agree on one convenient sample but disagree when another combination appears.

Name the questions as predicates before combining them. Predicate A asks whether the ready field is the Boolean value true. Predicate B asks whether the assigned field is the Boolean value true. This exact-type policy matters. The text string false is not the Boolean false, and an omitted property is not a declared negative answer. If the source uses other representations, define their interpretation explicitly before applying the two-condition example.

Case A: all conditions means an intersection

The first invented request is to select items that are ready and assigned. R1 satisfies both predicates. R2 fails assigned, R3 fails ready and R4 fails both. The expected result is therefore the one-item sequence R1 in the original input order. An AI explanation that includes R2 because it is ready has weakened the request. An explanation that includes R3 because someone is assigned has made the same mistake from the other direction.

The useful review is a record-level explanation: R1 has two true conditions; every other item has at least one false condition. Merely checking that the output contains one row would be weaker, because a filter selecting R4 would also contain one row. Preserve the expected identifier as well as the count. When an implementation changes, compare the actual identifier list with the manual expectation rather than relying on a dashboard total alone.

All-condition selection is often useful when prerequisites are cumulative, but the word prerequisite must come from the actual process definition. This article does not decide whether readiness and assignment are sufficient for work to begin. The example only establishes the logical relationship between two authored flags. A business owner may need additional conditions, a review stage or a separate action boundary even after a record satisfies the selection rule.

Case B: any condition means a union without duplicating records

The second request selects an item if it is ready or assigned, including an item that is both. R1, R2 and R3 qualify. R4 does not. R1 appears once because the result is a selection of records, not a list of every reason a record qualified. If a generated workflow appends R1 once for readiness and again for assignment, it has implemented a different output contract. Whether such repeated reasons are useful must be specified separately.

Say inclusive or explicitly when writing the request. Everyday language sometimes uses or to mean one alternative but not both. This example uses inclusive or: either condition, or both, is sufficient. Exactly one condition would select R2 and R3 while excluding R1. That is a third rule. Do not infer it from the word any, and do not silently substitute it when both conditions happen to be true.

Python's primary documentation describes all as true when every element is true and any as true when at least one element is true. It also defines their behavior on empty iterables. Those definitions provide limited programming context for this guide. The business meanings of the flags, the exact-type checks and the record-selection contract are independently authored here. No Python function is being presented as an operating approval or a complete policy for missing business information.

Case C: put parentheses around a mixed rule

Add two fictional fields to the same records: priority and region. R1 is high priority in the west region. R2 is normal priority in the east. R3 is normal priority in the west. R4 is high priority in the west. Keep the earlier ready flags: R1 and R2 are ready, while R3 and R4 are not. The new request is ready and either high priority or east region. Its grouping is A and the group B or C.

Under that stated grouping, R1 qualifies through readiness and high priority. R2 qualifies through readiness and the east region. R3 lacks readiness and both alternatives. R4 has high priority but lacks readiness. The expected result is R1 followed by R2. This is not equivalent to saying any record with high priority, any east-region record, or any ready record. The alternatives are inside the readiness requirement, not alternatives to it.

A reliable prompt writes the parentheses in words and notation: ready AND (high priority OR east region). Then it includes a counterexample such as R4, whose high priority must not bypass readiness. Counterexamples are particularly valuable because they identify the boundary a loose paraphrase may erase. If a generated expression omits parentheses, review the language's actual precedence rules rather than assuming the natural-language reading survives unchanged.

Case D: distinguish not all from none

The fourth example returns to the two Boolean flags. Not all of ready and assigned means at least one of those conditions is false. R2, R3 and R4 meet that rule. None of ready and assigned means neither condition is true, so only R4 qualifies. These are different selections. Both contain a negative word, but their scope is different: one negates the combined all-condition result, while the other requires every condition to be false.

Write the excluded counterexample next to the rule. R2 is not fully ready-and-assigned because assignment is false, but it is not a record with neither condition: readiness remains true. That single record separates the meanings. Similarly, R3 is assigned even though it is not ready. A summary that labels either record as having no qualifying conditions discards information that the source fixture explicitly preserves.

Do not turn a failed selection into a diagnosis. Failing a logical rule does not establish why a field has that value, whether the source is stale or whether someone made a mistake. An AI can draft a neutral explanation such as assigned is false in the supplied record. It should not invent a staff shortage, a missed handoff or a corrective action. Logical exclusion describes the supplied inputs, not their history.

Case E: choose an explicit policy for unknown fields

The fifth case uses two additional fictional records. R5 has ready set to true and no assigned property. R6 has assigned set to true and ready explicitly null. Under this article's strict-input teaching policy, neither record receives an ordinary include-or-exclude result from the two-Boolean filter. Each is routed to an unresolved-input result because both required fields must be present and have exact Boolean types before the combination is evaluated.

This is a deliberately chosen policy, not a universal rule of logic or a requirement of JSON. Another application might use three-valued logic, reject the entire file, substitute a default or allow an any-condition result when one known condition is already true. Each choice changes the contract. If you want one of those alternatives, state it and add matching expected examples. Do not let a generated implementation choose a missing-value policy without making it visible.

Separating validation from selection also prevents accidental language-specific coercion. In Python, for example, nonempty text has a truth value even when the text spells false. A filter based on generic truthiness could therefore behave differently from a policy requiring the Boolean value true. The existing missing/null/false/zero guide handles representation in more depth. Here the relevant step is to settle that representation before combining predicates, so a logical result has a stable meaning.

Case F: an empty set of conditions needs a business decision

The final fictional case supplies an empty condition list. In Python, all over an empty iterable returns true and any over an empty iterable returns false. The local teaching checks verify those documented outcomes. They do not imply that a business filter with no configured requirements should select every record or select none. An empty configuration might instead be an error, an unfinished draft or an explicit request for an unfiltered view.

This guide's proposed operational boundary is to leave an empty business rule unresolved until its owner chooses a behavior. That statement is an editorial design suggestion, not an actual policy installed in software. Keep the runtime fact and the business decision in different fields. For the fixture, runtimeAll is true, runtimeAny is false and businessSelection is unresolved. Combining those into one true or false value would erase the distinction the example is intended to teach.

This boundary matters when rules are assembled dynamically. A selection screen may remove every optional condition, or a configuration import may supply an empty array. A reviewer who tests only normal two-condition examples will not see the result. Include the empty case deliberately, explain whether it is valid input and decide whether an implementation should proceed, return an unfiltered view or stop for clarification. Then verify that chosen behavior in the actual application.

Write a compact instruction for an AI assistant

An original instruction can ask the assistant to restate each predicate, show the grouping, list the input identifiers, evaluate the declared rule and preserve unresolved inputs separately. For the first case, give the exact four records and the manual expectation R1. Ask for a per-record reason using only the supplied flags. Specify that the task is to draft a selection explanation, with no destination update, assignment, notification or workflow action.

A second instruction can ask for counterexamples. Ask which of R2, R3 and R4 would distinguish all from any, or not all from none. The expected teaching answer is already available from the authored truth table, so a person can inspect the draft without treating fluent language as evidence. This page does not present a response from a model. Any actual future response would need to be captured and compared with the expectations separately.

Do not ask the assistant to make the rule sound simpler if simplification would remove a condition. A concise paraphrase is useful only when it preserves the same selected identifiers across the examples. If the explanation says choose ready items while the rule requires readiness and assignment, the shorter version is wrong for R2. The counterexample shows exactly what was lost and makes the correction more useful than a general request to be more careful.

Review selection separately from later actions

A selected record is an input to a possible later decision, not permission to perform that decision. The fictional records do not establish consent to contact someone, approval to publish information or authority to change status. Keep a read-only comparison step distinct from any workflow that writes to a destination. If the actual project includes an action, its prerequisites, owner and confirmation requirements need their own design and evidence.

The same separation applies to quantities. A selection of three records is not automatically three unique people, three unresolved incidents or three accepted tasks. It is three record identifiers under the declared key and input scope. If duplicates, joins or pagination can change the population, resolve those questions using the corresponding guides before interpreting a match count. This article's fixture keeps one occurrence of each identifier precisely so the logical combinations remain the subject under review.

When reporting a check, name its scope. The downloadable data and manual expectation file support truth-table, grouping, exact-type and empty-condition checks. Passing those checks means the authored examples remain internally consistent. It does not measure model accuracy, establish coverage of all business conditions or demonstrate how a live database treats null. A SQL implementation, a spreadsheet formula and an application rule engine each need tests appropriate to their own semantics.

Use change review to preserve the intended question

Suppose a process owner changes the request from ready and assigned to ready or assigned. That is a substantive selection change, even if the same code file and interface remain. Record the new expected identifiers R1, R2 and R3, and explain that R2 and R3 are newly included. A change note that says improved filtering is too vague to reveal the effect. The example-level difference makes review concrete without claiming that either rule is universally better.

If the owner instead changes a field definition, revisit the examples rather than simply rerunning old expectations. Assigned could change from a Boolean flag to a list of people, or ready could become a three-state label. The earlier predicates would no longer match the input contract. Keep the old case as history if useful, but do not report it as evidence for the new interpretation. Stable words can conceal changed meanings just as easily as changed operators can.

A practical review ends with an agreed predicate definition, grouping, unknown-input policy, empty-rule behavior and expected identifiers for distinguishing examples. Those are small artifacts a business owner and implementer can discuss together. They do not replace testing the real workflow, but they make that later test answer a precise question. The benefit is clarity about what should happen, not a promise that AI-generated logic is correct by default.

Keep a readable exclusion explanation

An exclusion report should name the failed predicate without exposing unrelated source content. For the first example, R2 fails assigned is true and R3 fails ready is true. R4 fails both. That is enough to explain this fixture. Adding an invented personal explanation, a speculative cause or a suggested penalty would change a logical report into a claim unsupported by the input. In a real project, decide which fields a reviewer actually needs before copying entire records into a prompt or report.

Also distinguish excluded from unevaluated. R2 is evaluated and excluded under the all-condition rule. R5 is unevaluated under the strict-input policy because a required property is absent. If both are placed in one failed bucket, a reviewer may try to correct an assignment rather than resolve the missing input. A useful output has separate selected, excluded and unresolved sections, with the rule version and input scope attached to each. These are proposed reporting categories, not claims that an application already supports them.

Finally, keep explanation order separate from selection meaning. This fixture preserves original input order for its expected identifiers. Sorting the explanation by failed condition may help a reader, but it should not silently change a later ordered handoff. If an output order matters, declare it as another contract. The separate sorting guide covers tie and cutoff questions; this guide establishes which records qualify before any such presentation choice is applied.

Frequently asked questions

Does any mean exactly one condition must be true?

No. In this guide, any uses inclusive or: at least one condition is true, including a record where both are true. Exactly one would be a different rule with different expected identifiers. State that alternative explicitly if it is the intended business meaning and include an example where both conditions are true so the distinction can be tested.

Why check identifiers instead of only the number of matches?

Different wrong selections can have the same size. Case A expects R1, not merely one record. Preserving the identifier shows which combination satisfied the rule and catches an implementation that selects another single record. Counts are useful summaries after the record-level comparison, but they cannot replace it when identity matters.

Are missing and null automatically false in these examples?

No. The teaching policy requires present, exact Boolean fields before ordinary selection. Missing and null inputs remain unresolved. That is an authored policy for this fixture, not a universal JSON, SQL or business rule. An application using defaults or three-valued logic needs its own explicit expectations and implementation checks.

Should an empty all-condition rule select everything?

Python's all function returns true for an empty iterable, while any returns false. This page verifies those runtime facts but leaves the business meaning unresolved. A process owner must choose whether an empty rule means an unfiltered view, invalid configuration or another behavior. The programming default alone does not make that choice appropriate.

Does a correct filter authorize an automated action?

No. These examples are read-only selections and explanations. They establish no authority to send a message, assign work or modify a record. If a later action is part of a real workflow, review its destination, prerequisites and authorization separately. Keep the selected identifier list as evidence of selection rather than treating it as permission.

Was an AI system tested for this guide?

No. The records, rules and expectations are original fictional teaching material. Local and downloaded checks compare their authored logic and data representations using Python. They are not observations of a model, a client workflow or a production system, and they do not constitute professional review or an approval to deploy a generated filter.