One fact derived in two places

What goes wrong

The same fact is worked out independently at more than one site, each from its own inputs, rather than read from a single source. The sites agree on every case anyone tries, so the duplication looks harmless. Callers rely on one settled answer, and on the case where the inputs differ they get two, each path acting on its own.

Example

The planner treats a charge as exempt using the profile in force today, while the calculator treats the same charge as taxable using the profile for the year being computed.

Not to be confused with

Not a copy of one rule drifting after an edit, as in the catalog species for a fix applied to one copy only: both sites here are current and still disagree, because they decide from different inputs.

Discovered by

@sks24git GitHub

Field notes · 13

@sks24git2026-11-06

The preview said a post would carry the user's name and offered to hide it, but the poster signed only when a name existed. On an account with no name, preview and result disagreed, and the hide option did nothing.

Build the preview from the same inputs as the action. A rule repeated in two places drifts apart on the edge case.

@sks24git2026-11-06beat 2 review rounds

A one-off catch-up switch picked its work by the post's whole history, while the worker it fed counted only from the last edit. Edited posts were never scored again, and the report called the backlog done.

Pick work by the same rule the worker uses to judge it. Two readings of one history drift apart.
An opt-in sweep must not widen who sees private text. Ask before old posts go to new readers.

@sks24git2026-11-05

Two workers compare a stored list size, but one counts every entry and the other skips malformed ones. One bad entry makes the sizes differ forever, so every finished answer looks stale and is bought again each minute.

Build a shared set in one function. Two filters that drift apart turn a cheap check into a paid loop.
Key versions by content, not count. An add and a remove leave the count unchanged.

@sks24git2026-11-05

A timed charge and the page that announced it each counted the billable items their own way. The page could promise a charge the timer never made, or stay silent about one it did.

Make the notice call the code that charges. Two counts of the same money drift on the first edge case.
Mark which path charged. Later steps should read the mark, not guess it from verdicts.

@sks24git2026-11-04

Two columns are always written together, but one page checks one and the API checks the other. A test fixture cleared only one of them, building a state no real write makes, so the test proves nothing about production.

Gate every reader on the same field. Two flags for one fact will split one day.
Build fixtures through real writers. Hand-made rows invent impossible states.

@sks24git2026-11-04beat 1 review round

A rule switched which record decides that work is finished, but the deadline still read a timestamp from the old record. When the new record finishes first, the old timestamp is empty and the deadline never fires.

Move the clock with the condition. A filter and its deadline must read the same record.
Test the record that has no end yet. A null timestamp silently fails every comparison.

@sks24git2026-11-03beat 3 review rounds

A fix taught a check to skip one part of a total, but the form line beside it still printed that part. The check went quiet and the form now showed more relief than the total it had to match.

When a check skips a part, drop it from the output too. Fix both ends or the check hides the gap it was built to catch.

@sks24git2026-11-02beat 2 review rounds

A path check matched globs with a shell-style matcher, while the rest of the code used recursive path rules. A recursive pattern covered a root file in one place and missed it here, so its edits were dropped.

Match paths with the one matcher the codebase already uses. Two glob dialects disagree on exactly the edge cases nobody tests.

@sks24git2026-11-01beat 4 review rounds

A history filter sorted rows by a type column, while each row's label read its reference key, and old rows have no type. Those rows show as one kind and file under another, so the filtered totals contradict the labels.

Classify a row in one place. Two classifiers drift apart on the rows neither author pictured.
Seed the oldest row shapes. Legacy data is where the second rule disagrees.

@sks24git2026-11-01beat 2 review rounds

A notice that a write was skipped compared only one field, while the skip dropped the whole row update. A correction to another field, one that changes the bill, vanished with no notice at all.

Report a skip at the grain the write skips. If the whole row is skipped, check every field the caller sent, not just the headline one.

@sks24git2026-10-28beat 3 review rounds

Three consumers of one per-year rule shared a helper, but two passed different fallbacks for dates outside every known year. The planner routes an item one way, the calculator judges it the other, and it stays stuck.

Put the fallback inside the shared helper, not at each call site. A default chosen per caller is a second rule hiding behind the first.

@sks24git2026-10-28beat 1 review round

A planner moved to a per-year rule, but the calculation still chose neutrality by the year being computed, over items of every year. Items of the other year stay unlabeled with nothing left to ask, so it is blocked.

Move every consumer when a decision becomes per-item. A planner and a calculator that disagree turn one answer into a deadlock, not an extra question.

@sks24git2026-10-28

Three modules decided the same tax regime for a record, two by the record's year and one by the latest profile. After a regime change the gate kept failing a prior year that the planner had already marked as settled.

One lookup for one fact. When several modules derive the same fact, give them one function, or they will disagree on the boundary case.