A decision log is not a museum
We already push discovery rooms to leave with decisions instead of a backlog. That is the right exit. The failure mode shows up later: the log sits in a Notion page or a docs folder, every status still says Accepted, and the running system has quietly chosen something else. A decision log that is never revisited is a museum. The useful discipline is keeping the live set of decisions roughly true — with statuses, revisit conditions, and superseding records — so the next person does not re-litigate from vibes.
The log that stops at the kickoff
Most discovery packages we hand over include a short decision log: what we chose, why, what we rejected, and who owns the open questions. That artifact is valuable on day one. It is also where hygiene usually ends. Kickoff happens, build starts, and the log becomes something people cite when they remember it exists.
The drift is rarely dramatic. A bake-off said "Sanity owns product copy; Shopify owns price." Three months later a promo field lives in both places because a sprint needed a one-off. Nobody wrote a superseding decision. The original log still looks authoritative. New engineers treat it as current. The system disagrees.
That is not a documentation problem in the abstract. It is a consulting failure mode: we helped the room decide, then left them with an artifact that ages into fiction unless someone owns its maintenance.
Accepted means active, not forever
Borrow the ADR habit even when the client will not adopt formal ADR tooling. Once a decision is Accepted, do not edit the prose to make it "current." Write a new entry that supersedes it, and point both directions. The trail is the value. Quietly rewriting the original entry erases why the first choice was made under the constraints of that week.
Status is the field teams skip. Proposed, Accepted, Superseded, Deprecated. Without it, every old decision looks equally binding. With it, a reader can tell which choices still govern the build and which are history. Deprecation covers the case where the surface went away and nothing replaced the decision — still mark it, still leave one sentence of why.
We put this in the handover: the discovery log is append-only for accepted entries. Changes land as new rows. If the client's wiki culture cannot stomach that, keep a thin index page of "current decisions" that only links out — never a second copy of the rationale.
Write the revisit condition when you decide
A decision without a revisit trigger is a bet that context never changes. Write the condition in the same sitting: revisit if order volume crosses N, if a second locale ships, if the print vendor changes the ticket schema, if the field app must work offline for a full shift. Specific beats "review quarterly" alone, though a calendar pass still helps for high-blast-radius choices.
Revisit conditions are not commitments to reverse the decision. They are named moments when the team is allowed — expected — to reopen the trade-off without looking like they are thrashing. That lowers the social cost of saying "this no longer holds."
In practice we steal a line from scoping assumption logs: owner, check, trigger. For decisions the "check" is often a metric, a release gate, or a dependency the vendor controls. If you cannot name a check, the decision may still be an assumption wearing a confident verb.
Keep the live set next to the work
A decision buried in a slide deck from discovery week is already lost. Prefer a short markdown set in the repo the team actually opens, or a Sanity/studio singleton the editors and engineers both see. The format matters less than the path length from a confusing PR to the governing choice.
One cheap habit: link from the seam in code. A comment at the Shopify webhook ingest that points at Decision-014 ("idempotent on order id; Shopify is canonical") costs nothing and stops a well-meaning rewrite. The same link belongs in the PR template for changes that touch owned seams — supply the decision id or write a superseding one.
For studio-partner work, the studio still owns the client relationship, but someone must own the log. Name them in the handover. "We will know if this goes stale" is not an owner.
A thirty-minute pass beats a rewrite
Hygiene does not mean a second discovery. Once a quarter, or after a cutover, skim the index for fifteen to thirty minutes. Flag anything the running system has already contradicted. For each flag, either supersede it the same day or open a dated question with an owner. Do not leave "probably outdated" unmarked — that is how museums fill up.
We use the pass as a consulting checkpoint on longer retainers: show the live decision set against staging and one production path. If the log and the path disagree, the deliverable that week is the superseding entry, not another feature. Teams that treat this as optional accumulate silent architecture.
The test is simple. Hand the index to someone who was not in the room. Can they tell what still governs, what was rejected on purpose, and what would force a revisit? If not, the log is archive theater.