Glossary

Action Set

A formal specification of the permissible modifications a user can make to each feature, defining the boundary between actionable and non-actionable changes in counterfactual explanations.

Get in touch Learn more

Data engineer managing feature store on laptop, feature definitions visible, casual data engineering session.

RECOURSE FEASIBILITY

What is an Action Set?

An action set formally defines the boundary between what a user can and cannot change in a counterfactual explanation, ensuring algorithmic recourse is grounded in reality.

An action set is a formal specification of the permissible modifications a user can make to each feature, defining the boundary between actionable and non-actionable changes. It constrains counterfactual generation by encoding real-world mutability, such as preventing recommendations to alter an immutable feature like age or requiring that income can only increase, not decrease.

By integrating an action set, algorithmic recourse systems produce recommendations that are feasible for the end-user to implement. This framework directly addresses recourse feasibility by translating domain knowledge—such as causal dependencies and monotonicity constraints—into hard mathematical rules that a counterfactual algorithm must respect during optimization.

RECOURSE CONSTRAINTS

Key Properties of an Action Set

An action set formally defines the boundary between what a user can change and what they cannot, ensuring algorithmic recourse is grounded in reality.

Immutable Feature Locking

The primary function of an action set is to hard-code immutable features as non-modifiable. Attributes like age, place of birth, or historical credit events are locked to a delta of zero. This prevents the counterfactual generator from suggesting recourse paths that are physically or legally impossible, ensuring the explanation is actionable rather than merely theoretical.

Δ = 0

Permissible Change

Directional Monotonicity

Action sets enforce unidirectional constraints on features that can only move in one logical direction. For example, a user's credit history length can only increase, never decrease. A loan applicant's annual income might be constrained to only increase. This prevents the generation of counterfactuals that suggest nonsensical actions like 'reduce your years of employment' to flip a decision.

Causal Consistency

A robust action set respects the causal graph of the domain. If changing feature A (education level) causally implies a change in feature B (expected income), the action set must encode this dependency. Modifying A forces a recalculation of B according to a structural equation, preventing counterfactuals that violate known causal relationships and ensuring the recourse path is internally coherent.

Feasibility Intervals

Beyond binary mutable/immutable flags, action sets define continuous feasibility intervals for each feature. A feature like debt-to-income ratio might be constrained to a realistic range (e.g., 0.0 to 0.8). This prevents the algorithm from generating a counterfactual that is mathematically valid but practically unattainable, anchoring the explanation within the high-density region of the real-world data distribution.

Linked Action Costs

Action sets can assign non-uniform costs to feature modifications, moving beyond simple L1/L2 distance. Changing income might have a high cost (difficult), while reducing credit card utilization has a low cost (easily actionable). This transforms the counterfactual search into a cost-minimization problem, presenting the user with the cheapest, most feasible path to a favorable outcome.

ACTION SETS

Frequently Asked Questions

Clarifying the formal boundaries that separate actionable recourse from infeasible suggestions in machine learning explanations.

An action set is a formal specification of all permissible modifications a user can make to each feature in a dataset, defining the hard boundary between actionable and non-actionable changes. It explicitly encodes real-world constraints—such as immutability, monotonicity, and feasibility—directly into the counterfactual generation algorithm. For example, an action set for a loan application might specify that age cannot be changed, income can only increase, and credit_score can be modified within a realistic range. By pre-defining these constraints, the system guarantees that every generated counterfactual instance represents a valid path of algorithmic recourse that the end-user can actually execute, rather than an infeasible mathematical artifact.

Enabling Efficiency, Speed & Accuracy

Intelligent Analysis, Decision & Execution

We build AI systems for teams that need search across company data, workflow automation across tools, or AI features inside products and internal software.

Talk to Us

Search across company data

Give teams answers from docs, tickets, runbooks, and product data with sources and permissions.

Useful when people spend too long searching or get different answers from different systems.

Enterprise searchRAGPermissions

Automate internal workflows

Use AI to route work, draft outputs, trigger actions, and keep approvals and logs in place.

Useful when repetitive work moves across multiple tools and teams.

AI agentsWorkflow automationGovernance

Add AI to products and internal tools

Build assistants, guided actions, or decision support into the software your team or customers already use.

Useful when AI needs to be part of the product, not a separate tool.

AI integrationDecision supportModel routing

COUNTERFACTUAL ECOSYSTEM

Related Terms

Core concepts that define the constraints, generation methods, and evaluation criteria surrounding actionable counterfactual explanations.

Counterfactual Explanation

A causal explanation that identifies the minimal set of changes to an input instance required to alter a model's prediction to a predefined, desired output.

Answers the question: 'What needs to change to get a different result?'
Forms the mathematical foundation for algorithmic recourse.
Must cross the decision boundary while minimizing the distance from the original instance.

Minimal

Change Principle

Algorithmic Recourse

The process of providing an end-user with a set of actionable changes they can make to their input features to receive a favorable model decision.

Translates mathematical counterfactuals into real-world steps.
Requires distinguishing between mutable and immutable features.
A counterfactual is useless for recourse if it suggests changing a protected attribute like age.

User-Facing

Orientation

Recourse Feasibility

The degree to which a counterfactual recommendation respects real-world constraints, including immutable features, causal relationships, and user capabilities.

A feasible counterfactual never suggests 'decrease your age by 10 years.'
Enforces causal monotonicity: e.g., education level cannot decrease.
Directly defines the boundary of the Action Set.

Hard Constraint

Enforcement Type

Immutable Feature

A protected input attribute that cannot be changed and must be held constant when generating counterfactual explanations.

Examples: Place of birth, date of birth, ethnicity.
Violating immutability invalidates the generated recourse.
The Action Set explicitly excludes modifications to these features.

Fixed

Modifiability

Counterfactual Proximity

A metric quantifying the distance between the original input instance and the generated counterfactual, often measured using L1 or L2 norms.

Enforces the principle of minimal change.
Lower proximity means the user needs to make smaller, easier adjustments.
Must be balanced against plausibility to avoid adversarial artifacts.

L1/L2 Norm

Common Metric

Plausible Counterfactual

A counterfactual instance that lies within the high-density region of the training data distribution.

Ensures the explanation is realistic and not an adversarial artifact.
Often enforced using Mahalanobis distance instead of Euclidean distance.
A plausible counterfactual respects the correlation structure of real data (e.g., income and savings move together).

In-Distribution

Requirement

About the author

Prasad Kumkar

CEO & MD, Inference Systems

Prasad Kumkar is the CEO & MD of Inference Systems and writes about AI systems architecture, LLM infrastructure, model serving, evaluation, and production deployment. Over 5+ years, he has worked across computer vision models, L5 autonomous vehicle systems, and LLM research, with a focus on taking complex AI ideas into real-world engineering systems.

His work and writing cover AI systems, large language models, AI agents, multimodal systems, autonomous systems, inference optimization, RAG, evaluation, and production AI engineering.

Limited slotsGet a Free AI Consultation

How We Work

Custom AI workflows for your Business

One-fit-all AI don't work for modern businesses. At Inferensys, we aim to understand your business & custom requirements; which we use to define most efficient agentic workflows, the data, and the tools for your business.