Append-only ruling/amendment logs

When a founder correction lands on a standing doc — a design contract, a milestone tracker, a scored roster — the RDCO pattern is not to silently edit the old text to match the new truth. It is to append a dated, attributed amendment entry, strike or bracket the superseded text in place, and state explicitly what changed and why, so a reader can see both the current truth and the reasoning trail that produced it.

Four recent examples show the same shape independently:

• [[DESIGN-scribble-works]] carries a dated "Amendment log" at the bottom (2026-09-02 06:16 ET) that names the founder's exact rulings and which sections they touched, rather than just rewriting the wordmark/Ray-mascot rules in place.
• [[2026-09-07-scribble-works-process-map]] opens with a same-file "AMENDMENT 2026-09-08" block that overturns the review-gate model the rest of the document describes, and a second "Workflow amendment — 2026-09-10" block retiring the release-branch flow — both left as prose blocks ahead of the (now-historical) body rather than rewritten into it.
• [[2026-08-30-shortlist-refresh-scored]] uses literal markdown strikethrough (~~...~~) to preserve the original dental-lab disqualification reasoning immediately next to the note that Ruling 2 struck it, "kept visible so the reversal is auditable."
• [[cert-progress]] and [[milestones]] both carry explicit "CORRECTED"/"stale, do not cite" language on the Snowflake deadline, cross-referencing the exact founder correction date (2026-08-17) rather than quietly changing the date.

Why this is in the vault

Ray operates continuously across long-running docs that founders correct in real time (iMessage rulings, cron pulses, re-scored funnels). A silent edit destroys the evidence trail a later reader or a future Ray session needs to answer "why does this say X now, and did we get here from Y or was X always true?" It also protects against a specific failure mode Ray has hit before: a stale note being read as current because nobody could tell whether it had been corrected or simply never updated.

Mapping against Ray Data Co

This is a convention worth formalizing rather than reinventing per-skill: any skill or session that amends a standing vault doc (design contracts, comp/cert trackers, scored rosters, SOPs) should default to append-and-strike over silent rewrite, with the amendment line naming the date, the source (founder iMessage, cron pulse, etc.), and the specific claim it overturns. /compile-vault and /self-review could eventually score for this pattern the same way they score for missing "Why this is in the vault" sections. Candidate owner: a new invariant in the vault-writing rubric that /verify-vault-write checks, alongside the existing "Why this is in the vault" check.