Represent intrinsic parameter support independently of likelihood bounds
- Dominant language
- Python
- Stars
- 124
- Forks
- 24
- Avg merge
- 19h 32m
- Merged PRs (30d)
- 60
Description
## Problem
Some HSSM parameters have intrinsic mathematical support that is not represented
in the parameter's `bounds` metadata. The clearest case is `p_outlier`, which is a
probability in `(0, 1)` and receives a Beta prior in the calibrated HDDM path, but
often has `bounds=None` in parameter construction.
This creates two gaps:
1. generic safe-prior generation and support diagnostics cannot see the intrinsic
domain;
2. an additive identity-link regression can leave the natural domain even when its
intercept prior has suitable support.
#1269 correctly keys its generated bounded hierarchy off configured HSSM bounds,
so it intentionally cannot repair a parameter whose bounds are absent.
## Scope
- Audit every regression-capable HSSM parameter whose distribution or likelihood
imposes natural support not encoded in `Param.bounds`.
- Decide where intrinsic support belongs in configuration: parameter metadata,
likelihood metadata, or a separate support contract distinct from finite
LAN/training bounds.
- Start with `p_outlier` across HSSM, aDDM, RLSSM, analytical/black-box DDM, and
generic/custom-model paths.
- Define how the support contract is consumed by links, safe priors, validation,
representation, and diagnostics without mutating user model configurations
unexpectedly.
## Acceptance criteria
- `p_outlier` exposes `(0, 1)` consistently wherever it is regression-capable.
- Natural support is distinguishable from a finite approximation/training domain.
- Existing calibrated Beta priors remain unchanged unless a separately reviewed
policy says otherwise.
- Identity and transformed-link regression cases have explicit graph/diagnostic
tests, including additive predictors that can leave the domain.
- Serialization, repr, subclass paths, and fixed/simple-parameter behavior remain
backward compatible or have a documented migration.
- No duplication of the general complete-predictor diagnostic: this issue supplies
trustworthy support metadata; the broader issue decides what to do with an
additive predictor.
## Related
- #1269 covers parameters whose configured bounds are already available.
- The complete-predictor support follow-up consumes this metadata once defined.
Contributor guide
Research direction
Start by auditing regression-capable HSSM parameters, beginning with p_outlier across HSSM, aDDM, RLSSM, analytical/black-box DDM, and generic/custom-model paths. Trace how support is represented and consumed by links, safe priors, validation, serialization, repr, and diagnostics. Done means consistent (0, 1) metadata, explicit graph and diagnostic coverage, and backward-compatible fixed/simple-parameter behavior.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- machine-learning
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 32/100