The regularizing prior set is not a narrowed version of the uninformative one, and its bot anchor is biased for a count response

[beckyfisher]

What

The "regularizing" prior set does not mean the same thing in every family, and
on a count response its bot prior excludes the asymptote it is meant to
locate. Both are properties of the response-scaled top and bot entries,
which are the only ones prior_type selects between.

prior_type does not exist on master (2.1.3.1, the CRAN release), so
"regularizing" is entirely unreleased and can be changed without affecting any
published analysis.

Why it matters

A user selects prior_type = "regularizing" when the data are sparse or noisy
and they want the prior to do more work. On a poisson or negbinomial
response fitted on the identity link they instead get a bot prior whose
central 95% interval excludes the true lower asymptote, so the parameter is
determined by the prior rather than by the data. The "uninformative" set,
which is the default, does not have this defect.

Separately, the word "regularizing" does not describe one thing. For a Gaussian
response it narrows the prior to 0.40 of its uninformative width; for a
negbinomial top it makes it 1.15 times wider; for a Beta response it
changes the width by 12 per cent and does not change what the prior is anchored
to at all. A user cannot reason about what selecting it will do without knowing
which branch their family takes.

Evidence

Priors only; nothing was fitted. Responses were simulated from a nec4param
curve with a known top and bot, over three designs --- a series spaced evenly
from zero, a two-fold dilution series, and the nassarius contaminant A series
--- by four families on the identity link. Priors were read through
get_priors(), which runs the same check_data() and define_prior() sequence
bnec() runs, and each was truncated to its own bounds before being summarised.
dev at aa2c7dbd, R 4.6.1, brms 2.23.0, 2026-09-10.

The regularizing bot prior excludes the true value on a count response.
It is gamma(5, 5 / (min(y) + min(y > 0) / 10)), whose maximum density is at
about 0.8 times the smallest observation. For a continuous response that is
defensible. For a count the smallest observation sits well below the asymptote:
against a true bot of 5 the observed minimum was 1 to 3 across cells.

family, identity link	cells with the true bot outside the central 95%
poisson, regularizing	3 of 3
negbinomial, regularizing	3 of 3
Gamma, regularizing	0 of 3
gaussian, regularizing	0 of 3
all four, uninformative	0 of 3 each

The truncated prior CDF at the true value runs 0.988 to 0.99999 in the failing
cells. The count of failing cells varies with the draw, because min(y) is a
random variable; the direction does not.

The two sets are not separated by the same amount in every family. Prior
standard deviation, regularizing divided by uninformative, on the same runs:

family	top	bot
gaussian	0.40	0.40
Gamma	0.87	0.34
poisson	0.83	0.10
negbinomial	1.15	0.16

For the families that route to the normal entries the ratio is about 0.4, which
is the intended narrowing. For the gamma branch it is inconsistent between top
and bot, and for negbinomial top it is above 1.

The Beta branch reads nothing from the response. beta(5, 2) becomes
beta(5, 1) and beta(2, 5) becomes beta(1, 5): the standard deviation
changes from 0.1597 to 0.1409, a narrowing of 12 per cent, and the anchor does
not change because there is no anchor. So "regularizing" means "centre on the
observed extreme" for a Gamma or Gaussian response and "use a slightly different
fixed prior" for a Beta one, which are different in kind rather than in degree.

The one published demonstration is on the branch where the feature does
least. Searched every vignette on every branch of this repository: the only
one that mentions prior_type or "regularizing" is example3, and the only
fit is in its "Selecting the default prior set" section --- nec3param on
nec_data, a Beta response on the identity link. nec3param has no bot, so
the single difference the vignette prints is top: beta(5, 2) against
beta(5, 1). Neither the branch with the defect nor a bot prior is shown
anywhere.

Implementation detail

Where the code is

R/define_prior.R, the prior_type == "regularizing" block that builds u_t_g,
u_b_g, y_t_prs and y_b_prs. positive_scale(response, probs = 0) is the
minimum and positive_scale(response, probs = 1) the maximum; the + min(y > 0) / 10 term on bot is a fudge to keep the rate finite.

The uninformative set in the same block is the one Fisher et al. (2024)
describe and is on CRAN. It should not change.

Three ways to fix it, in increasing order of what they alter

1. Anchor the regularizing set on an extreme quantile rather than the
extremum. q95 and q05 instead of max(y) and min(y). This addresses the
count defect directly --- the smallest observation is a biased estimate of the
asymptote for a discrete response and an extreme quantile is not --- and changes
nothing about the uninformative set, which already uses interior quantiles. It
does not address the inconsistent separation or the Beta branch.

2. State the contract for both prior types once and derive each branch from
it. A prior type would be defined by a location quantile and a spread
multiple, both family-independent, and each branch would use whichever
distribution matches the parameter's support, with its parameters set so that
its mode is the location and its standard deviation is the spread. For a
gamma with mode L and standard deviation S the shape solves
sqrt(s) / (s - 1) = S / L, which has the closed form
sqrt(s) = (L/S + sqrt(L^2/S^2 + 4)) / 2, and the rate is then (s - 1) / L.
For a beta on the unit interval the two shape parameters are determined the same
way, numerically.

This is what would make "weak" and "regularizing" mean the same thing in every
family, and it is what would stop a family added later from drifting. Adopting
it with weak = (q90/q10, 2.5 sd) and regularizing = (max/min, 1.0 sd) would
change released numbers for the gamma branch, because its weak location moves
from a mean at q75 to a mode at q90.

A middle option preserves the released locations and fixes only the
specification convention: keep q75/q25 for the gamma branch and q90/q10 for the
normal branch, but set the gamma's mode to its location rather than its
mean. gamma(2, 2/q75) currently has its maximum density at q75/2, while
normal(q90, 2.5 sd) peaks at q90, so the same stated rule peaks in different
places. That is the same mean-against-mode ambiguity that produced #273 and #302
on the predictor side.

3. Decide whether the Beta branch should read the response. The article's
justification --- that a 0-1 bounded parameter needs no scaling --- is a
statement about support, not about location. If regularizing is to mean the
same thing for a binomial response as for a Gamma one, the 0-1 branch has to be
given a location taken from the response, at which point the mode-and-sd
construction above supplies the shape parameters. If it is to stay fixed, that
should be recorded as a deliberate exception rather than left as an asymmetry.

What to check

• All four identity-link branches: normal (gaussian, and any family under log
  or logit), gamma (Gamma, poisson, negbinomial, the zero-inflated counts),
  beta (bernoulli, binomial, beta_binomial, Beta), and the hurdle mu block,
  which routes through hurdle_mu_family() and takes the branch of whatever the
  non-zero subset looks like.
• Both top and bot, and both prior types, against known values.
• A response with a large zero fraction, since positive_scale() rescales the
  quantile level there and the interaction with an extremum anchor is untested.
• The group-level scales, which take half the uninformative scale under
  regularizing and are stated in vignette("example3") as "roughly the same
  degree of narrowing the response-scaled priors receive" --- a claim that is
  true for the normal branch and false for the others.
• amend() builds a default prior for each model it adds, so a set fitted
  across any change here is internally inconsistent in its priors.

Definition of done

A regularizing set that places the true top and bot inside the central 95%
of the prior on every family and design tested, that is narrower than the
uninformative set by a stated and similar factor in every branch, and whose
definition is written once rather than per branch. vignette("example3")
demonstrates it on a branch where it does something, and states what it does. A
NEWS entry recording that prior_type was unreleased, so nothing published
changes.

Stop and ask rather than guess

Which of the three options above. Option 1 is contained and fixes the defect a
user would actually hit; option 2 is the one that stops the problem recurring
and changes released numbers for the gamma branch; option 3 is a question about
what prior_type is for.

Not blocked, and not blocking

Independent of #302. That issue and PR #304 concern the predictor-scaled nec
and ec50 prior, which is a function of the predictor alone and identical under
both prior types; PR #304 adds a test asserting that. The measurements above
come from the same prior sweep and are recorded on #304 as out of scope.

[beckyfisher]

NEC and E50 parameters should also be given regularizing priors

Since #302 has landed, the default priors for NEC and EC50 are also very wide. This was done to align with the original JSS publication as much as possible, but they should also be allowed a regularizing version to improve performance of these models.

[beckyfisher]

Addressed by #307, merged to dev as 9941a41.

The "regularizing" set is now stated once, as a location and a spread, with every family's entry derived from it. Option 2 of the three in this issue, restricted to the regularizing set, which answers option 3 as "the 0-1 branch reads the response, for that set only" and leaves the "uninformative" entries untouched. The follow-up comment is included: nec and ec50 are narrowed too, by qnorm(0.975) / qnorm(0.99) rather than by 0.4, because their width is set by the requirement to reach every concentration tested.

Measured over the 720 top and bot cells of the prior sweep, the released set placed the true value outside the central 95% of its own prior in 65 and this one does so in 1. Four rounds of review found eight further defects, every one on a design the sweep does not contain; both sweeps are archived under notes/scripts/.