Why we ship only signal
The SNR meter on /noise is not a metric. It is a publishing rule. We will not post anything that would push the ratio below 1.00. That costs us. It is the cost.
Most publishing rules are soft. They feel like rules but they have no enforcement. The signal-to-noise meter on /noise is not like that. It is a publishing rule with teeth.
The meter reads signal / (signal + pending + noise), clamped at the floor of 1.00. The numerator counts posts that are live on platforms. The denominator counts everything else: pending posts (live on the site, awaiting dispatch), noise posts (draft or archived, held back). The floor is a brand statement, not a metric. We are not optimising the ratio; we are refusing to ship below it.
What the rule costs
The rule costs cadence. With the previous two-bucket meter, an approved post was visible on the site but counted as neither signal nor noise — a third state hidden from the meter. The reader saw the post. The meter said the ratio was unchanged. The two disagreed. The third bucket (pending, rev.09.14r) fixed that. An approved post is in the denominator now. If we have five posted and two approved, the meter reads 5/7 ≈ 0.71. The brand floor clamps the display to 1.00. The cost is invisible on the page. The cost is real on the editorial calendar.
The rule also costs draft churn. Some posts are drafted, reviewed, and rejected — sent back to draft with notes. The state machine allows a backward arrow from approved to draft for exactly this reason. The rejected posts live in the brand-system repo, not on the live site. They are not noise because they don't surface.
What the rule buys
The rule buys trust. A reader who lands on /noise sees three numbers: signal, pending, noise. The reader can verify by counting the posts in the list and the posted posts. If the meter and the list disagree, the reader knows the section is lying. The rule says: the meter and the list always agree.
The rule also buys editorial restraint. The cron workflow at .github/workflows/noise-publish.yml runs hourly and finds any post whose linkedin.scheduledFor is now or in the past, but it cannot promote a draft to posted. The promotion is a human flip: status: approved requires a reviewer. The cron can ship an approved post at the scheduled time; it cannot approve a draft. The human gate is the rule.
What we would change
We would not soften the floor. The four states are enough. The backward arrow from approved to draft is the only exit that doesn't end in posted or archived, and that's the point.
We would change one thing: the cron should not run for posts that are already posted. The current workflow is idempotent (replace: true deletes the old post before publishing the new one), which is the right behaviour for reruns and edits, but a misconfigured post can be silently re-published. A simple guard — if status: posted and linkedin.urn is set, exit without action — would prevent that.
The meter does not measure the editorial process. It enforces a publishing rule. The publishing rule is: ship only signal. The brand floor is the contract with the reader.
Filter the noise. Protect the margins. Architect the signal.
