[AdrianSosic]

Finally fixes #794, enabled by the previous PRs merged to #837.

The constraints attribute on SubspaceDiscrete conflated two fundamentally different roles:

• filtering constraints (applied once during construction to prune the candidate grid) and
• batch constraints (applied at recommendation time to enforce structure across the recommended batch)

Storing both under a single field was misleading – filtering constraints are only relevant during construction, and even then only for certain construction routes: when building via from_dataframe, the candidate grid is already fully specified by the caller, so filtering constraints were meaningless from the very beginning and had no effect whatsoever. Retaining them on the object after construction served no purpose and gave a false impression that they remained active throughout the object's lifetime. As a further consequence, from_dataframe never accepted any constraint objects at all – since filtering constraints are not needed there, and batch constraints were introduced later, users had no way to attach batch constraints when constructing a subspace from a dataframe.

This PR makes the distinction explicit and removes the dead storage:

• Adds SubspaceDiscrete.batch_constraints: a dedicated field for DiscreteBatchConstraint instances that are evaluated during recommendation. from_dataframe now accepts a batch_constraints argument – fixing the previously missing ability to attach batch constraints when constructing from a dataframe. Filtering constraints passed to from_product/from_simplex are applied during construction as before and then discarded – there is nothing left for them to do.
• Deprecates SubspaceDiscrete.constraints: passing it emits a DeprecationWarning; any DiscreteBatchConstraint instances are automatically migrated to batch_constraints to ease the transition.
• Removes is_constrained properties from SubspaceDiscrete, SubspaceContinuous, and SearchSpace: these were thin Boolean wrappers that obscured which kind of constraint was being checked and, in the discrete case, were backed by the now-meaningless stored filtering constraints.

[Copilot]

Pull request overview

This PR refactors discrete-subspace constraint handling by separating creation-time filtering constraints from recommendation-time batch constraints, deprecating the legacy SubspaceDiscrete.constraints storage/usage, and removing ambiguous is_constrained convenience properties.

Changes:

• Introduces SubspaceDiscrete.batch_constraints and migrates legacy constraints (argument/serialization) to batch constraints with deprecation warnings.
• Updates discrete subspace constructors/serialization to split filtering vs batch constraints and discard filtering constraints after construction.
• Removes is_constrained from SubspaceDiscrete, SubspaceContinuous, and SearchSpace, updating call sites and tests.

Reviewed changes

Copilot reviewed 6 out of 6 changed files in this pull request and generated 6 comments.

Show a summary per file

File	Description
baybe/searchspace/discrete.py	Adds batch_constraints, migration/deprecation logic, constructor updates, and a temporary structure hook for legacy constraints key.
baybe/searchspace/core.py	Updates SearchSpace.constraints to use discrete batch_constraints; removes is_constrained.
baybe/searchspace/continuous.py	Removes is_constrained and updates sampling logic to check constraints directly.
baybe/searchspace/_filtered.py	Drops deprecated _constraints when cloning filtered subspaces.
tests/test_deprecations.py	Adds regression tests for legacy constraints argument/key migration into batch_constraints.
CHANGELOG.md	Documents additions/changes/deprecations around constraint API updates and is_constrained removal.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[myrazma]

Looks good to me, just some minor comments.
I like the separation of filtered and batch constraints. Previously when they were combined, it created the false impression that the filtered constraints were applied to exp_rep after creating the Searchspace, which they are not. So this update removes that ambiguity and hopefully prevent user confusion.

[AdrianSosic]

So this update removes that ambiguity and hopefully prevent user confusion.

@myrazma: yes, but the user will never actually see this state of the code. Once merged to main, we'll have the full architecture in place, including your Candidates as the new attributed populating SubspaceDiscrete. There, constraints will be cleanly re-introduced as part of ProductCandidates – the only context where constraints actually make sense and are then also used during lifetime 🙃

[fabianliebig]

Hi @AdrianSosic, sorry for the delay. Couldn't catch anything incremental beyond the current discussions :).

[AdrianSosic]

Hi @AdrianSosic, sorry for the delay. Couldn't catch anything incremental beyond the current discussions :).

@fabianliebig No worries at all. Your review came in exactly the right moment. We're talking about seconds after I fixed the last open thread 😄 So I can now happily merge 🚀