hal2Bayes: shares toward the reachable threshold, and a persistence qualifier

[flic]

Two changes, both found while modelling "the house is in night mode" — a design where the prior
sits above the on-threshold, so the node rests on and rules push it off. That turns out to be a
useful way to say "assume the house is quiet until something says otherwise": no rule has to argue
the resting case, and silence is the answer rather than something to reconstruct.

Shares were measured toward a threshold the node could not reach

requiredGain is logit(pOn) − logit(prior), which goes negative when the prior is above the
on-threshold. A rule pushing the output down has a negative ln(LR). Two negatives divide
positive — so a decisive makes it false was reported as +283 % of the way to on, and the
editor summarised a rule set that only ever turns things off as "692 % → turns on".

The estimate underneath was right the whole time, which is what made it look cosmetic. It was not:
the runtime uses the same gain to scale a value-following weight, so a scaled rule in this
configuration computed the wrong direction.

The gain now references whichever threshold the configuration can actually cross — pOn when the
node rests off, pOff when it rests on. Both branches return a signed gain, so a rule pushing the
way the node can move always reports a positive share, and shares still add against one
denominator. An ordinary configuration is byte-identical, which a test pins by comparing the result
with and without the new argument.

The editor follows: bars read "of the way to off", the summary leads with "Rests on — the prior
(0.93) is above the on-threshold (0.8), so the output starts on and rules push it off", and the
decay sentence is replaced, since with nothing pushing the estimate returns to a prior above the
line and silence reads as on.

Reported from a live node at prior 0.93 showing 34 % and 283 % for two vetoes. Those now read 13 %
and 106 % — and 106 % is exactly right: one decisive rule takes 0.93 to 0.307, just past an
off-threshold of 0.35.

A "for a while" step qualifier

A condition that must have been continuously true for its own duration before it counts.

The problem that produced it: a trip to the bathroom and getting up for the day are identical
readings at the moment they happen, and only time tells them apart. The workaround being replaced
was requiring two people to be up — which filtered the bathroom trip, but only for a two-person
household. With one person home it filtered out the case that should pass, since one person up is
then the entire household. Count was standing in for duration and only worked by coincidence of
household size.

With the qualifier the model says what it means — decisive per person, filtered by persistence,
correct at any number of people home:

	p
everyone asleep	0.93	night
bathroom trip, 2 min	0.93	night
one up > 10 min	0.31	→ day
one person home, up > 10 min	0.31	→ day

Three decisions worth knowing. The duration is measured from the rising edge already tracked for
the sequence overlap rule, so a genuine hold survives a restart rather than being reset by a
deploy. A condition found true with no edge on record — true while the node was down, or on the
very first evaluation — starts its clock then rather than counting as held: a hold that has not
been observed has not been observed. And the clock restarts whenever the condition drops, so
eight minutes, back to bed, eight more is not ten in a row — which is what makes it a filter
against repeated short blips rather than a stopwatch.

It counts as a condition everywhere that matters: a rule of them is continuous rather than a
sequence, and inside a sequence it waits for its time rather than failing the step.

Testing

324 passing. The new ones cover both directions of the share arithmetic (including that an ordinary
configuration is untouched), and the qualifier's edges — not credited on sight, the clock
restarting, a zero duration behaving as a plain condition, and a hold surviving serialize/restore.