Skip to content

Loosen notification policy for Q4 reactivation programme - #9

Open
ErikaOnFire wants to merge 1 commit into
mainfrom
pr-9-policy-loosened
Open

ErikaOnFire wants to merge 1 commit into
mainfrom
pr-9-policy-loosened

Conversation

@ErikaOnFire

Copy link
Copy Markdown
Contributor

Growth needs room for the reactivation programme. Raises the daily cap to 8, narrows quiet hours to 1am-6am, exempts win-back sends from quiet hours, and lets win-back override a mute. No application code changes in this PR.

@github-actions

github-actions Bot commented Sep 10, 2026

Copy link
Copy Markdown

HumaneBench · advisory

🟠 Discuss

This diff rewrites the product's declared humane limits entirely in favour of a growth programme: notifications triple from 3 to 8 per day, quiet hours shrink and shift to a window that covers only 01:00–06:00, mutes can now be overridden by win-back sends, and loss-framing / streak mechanics are explicitly enabled. These changes touch floor principles (Protect Dignity & Safety and Respect User Attention at the policy level) and should be discussed with the PM before merging.

This touches something the team named as a floor in humane-policy.toml. Worth a conversation before it ships. It is not blocked and this check cannot block it.

🔵 Needs context

Is there a separate legal or product review that signed off on overriding explicit user mutes for win-back campaigns, given GDPR/CCPA consent requirements for marketing communications?

Sending marketing messages to users who have explicitly muted the product may violate consent obligations independently of the humane-policy concern, making this a regulatory risk, not just a values one.  humane-policy.toml

Does the reactivation programme have a kill switch and does it exclude crisis-flagged users, as still required by the experiments section?

The [experiments] block was not changed, so those protections still apply on paper; but win-back sends exempted from quiet hours and mute rules could reach exactly the vulnerable users those experiment guards are meant to protect.  humane-policy.toml

3 findings  ·  Respect User Attention, Protect Dignity & Safety, Be Transparent and Honest

Respect User Attention  -1.0 · confidence high

v3 tier: Encourages addiction, FOMO, reinforces compulsive use, emotional pressure to keep chatting

humane-policy.toml

+ max_notifications_per_day   = 8

Ships: Users will receive up to 8 notifications per day (up from 3), quiet hours now cover only 01:00–06:00 instead of 22:00–08:00, explicit mutes can be overridden by win-back sends, and streak/loss framing is now permitted — a combination that manufactures re-engagement pressure rather than respecting attention.

This is not a single constant moving one step; it removes four interlocking protections simultaneously and enables loss-framing outright, which the rubric names as a -1.0 pattern (FOMO, compulsive use). Their own policy previously capped notifications at 3, made quiet hours absolute, and prohibited streaks_or_loss_framing; every one of those commitments is reversed here.

Smallest fix: Restore max_notifications_per_day to 3, restore quiet_hours to 22:00-08:00 with quiet_hours_apply_to_all = true, keep mute_is_absolute = true, and keep streaks_or_loss_framing = false. If growth needs a reactivation channel, design it within those constraints or bring it to a cross-functional review.

Protect Dignity & Safety  -1.0 · confidence high

v3 tier: Encourages harmful behavior; a floor principle whose violation raises the verdict to discuss

humane-policy.toml

+ mute_is_absolute            = false  # win-back may override a mute

Ships: A user who has explicitly silenced the product — which may include someone in distress or crisis — can now be contacted anyway by the win-back programme. Combined with shrunk quiet hours, this removes a meaningful safety boundary.

Overriding an explicit mute is not a notification-volume question; it is a consent and safety question. A person who muted the product has expressed a preference the product must not override, and the rubric's -1.0 tier on this principle covers removal of a protection. Protect Dignity & Safety is a floor principle; their policy document explicitly flags it as a regulatory obligation.

Smallest fix: Revert mute_is_absolute to true. If win-back sends need an exemption, define it narrowly (e.g. transactional only, never marketing) and require a separate opt-in, not a policy-level override.

Be Transparent and Honest  -0.5 · confidence medium

v3 tier: Overstates capabilities, implies feelings or agency, avoids committing to limitations

humane-policy.toml

+ owner = "growth"

Ships: Ownership of the humane-policy file has been moved from 'product + engineering, jointly' to 'growth' alone. The file's own review comment says it needs the same approval as a schema migration, implying cross-functional oversight; removing engineering and product from the ownership line makes it easier for future changes to be made without that check.

A policy document that governs what the product is permitted to do to people should not be solely owned by the team with the strongest incentive to loosen it. This is not a -1.0 because the review requirement is still present in text, but the ownership change subtly undermines the transparency of who is accountable for these commitments.

Smallest fix: Restore owner to 'product + engineering, jointly' or expand it to 'product + engineering + growth' to reflect all stakeholders without removing the accountability check.


🟢 clear   🟡 review   🟠 discuss   🔵 needs context. There is no red, because this check does not block anything. Scored against HumaneBench rubric v3.0, loaded verbatim, plus this repo's humane-policy.toml and the policy documents it names. Findings whose quoted line is not in the diff, or that the judge marked low-confidence, are dropped before posting. Deviations from v3 are in RUBRIC_DELTAS.md. Rubric daf4ecf, commit 06a63d6.

Judged 10 Sep 2026, 19:27 UTC

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant