Keep it current

Keeping related documents in sync

Some documents restate a fact that lives in another document. A product one-pager repeats the pricing model; a downgrade checklist depends on the packaging; a deck reuses numbers from a strategy memo. When the source changes, those satellites quietly go out of date — nothing links them, so drift is only caught when a person happens to notice. rooms watches for exactly this: when a document changes materially, it flags the other documents that probably need a look — as a suggestion, never an edit.

A real example. A "freemium model" guide was written before the packaging was finalized. The packaging later changed; the guide didn't — and it kept making wrong claims until a human stumbled on it months later. This feature exists so that when the packaging document changes, the guide is flagged for review the same day.

The idea in one line

When you materially change a published document, rooms looks at the rest of your corpus and asks: which other documents are now probably stale? It records those as "may be out of date" flags you can review — and it works the other way too, so on any document you can see what feeds it and what it feeds.

You edit a source document→ rooms finds the documents that depend on it→ each is flagged “may be out of date”→ a curator reviews & updates it

How documents get connected

Two ways — you never have to do anything for the first one:

Connection	How it happens
Automatic (by meaning)	Always on. rooms already understands what each document is about (the same understanding behind Search & Ask). When a source changes, documents that are clearly about the same thing are flagged — no setup, no linking.
Declared (you say so)	Optional, high-confidence. You can tell rooms “this document depends on that one.” A declared link always flags the dependent when the source changes, even if the wording is very different — perfect for a checklist or deck that reuses a fact without repeating the language.

"This downgrade checklist depends on the packaging model — link them so I'm warned when packaging changes."

Claude tools: linkSource to declare a dependency, unlinkSource to remove one.

What counts as a change

Only a real content change triggers a review — the kind that changes what the document actually says. Renaming a document, restyling it, switching its theme, or an automatic brand tidy-up do not count, so you're never nagged by cosmetic edits. Publishing a genuinely revised version of a source is what sets its dependents blinking.

Where the flags show up

Two places, both suggest-only:

The curation queue gets a new kind of card — “May be out of date (a source changed)” — one per flagged document, listing the source documents that changed. It sits alongside the orphaned/stale/unread cards so upkeep is one list.
The “Depends on / Feeds” panel on any document (in the web app, under a document's ⋯ menu) shows two lists: Feeds — documents that likely go stale when this one changes — and Depends on — this document's own sources, with a ⚠ marker on any that recently changed. Editors can declare or remove a dependency right there.

"What depends on the pricing model? What would I need to review if I change it?"

Claude tools: checkDependents (the full picture for one document — what it feeds and what it depends on), listDependents (just what depends on it).

How a flag goes away

A “may be out of date” flag clears the moment the drift is actually addressed — in one of two ways:

Edit the flagged document. Updating the dependent (in Claude or your editor) is taken as “handled” and clears its flag automatically.
Dismiss it. If it's fine as-is, a curator dismisses the card. If a different source later changes and implicates the same document again, it comes back — dismissing once doesn't silence it forever.

Nothing expires on a timer, and nothing is ever edited for you — the update is authored the normal way, by you and Claude.

Private stays private

Nothing crosses a wall you can't see. Flags are matched across your whole company, but they're only ever shown to people who can already open the rooms involved. If a document you can see depends on a source in a private room you're not in, you'll never see that source — not its name, its room, or even that it changed. The same rule applies everywhere the connections appear: the queue, the panel, and every tool.

What's included — and what isn't

This applies to your ordinary documents. Deliberately left out of the drift model:

Controlled documents and deal-room agreements — they have their own review and sign-off lifecycle, so they're neither flagged nor used as a trigger.
Your private workspace — scratch edits in your personal draft space never flag anyone else's documents.

Everything, both ways

Task	In the web app	Ask Claude — tool
See what depends on a document (and what it depends on)	Document ⋯ → Depends on / Feeds	`checkDependents`
List just what depends on a document	Depends on / Feeds → Feeds	`listDependents`
Declare “this depends on that”	Depends on / Feeds → Link a source	`linkSource`
Remove a declared dependency	Depends on / Feeds → Unlink	`unlinkSource`
Review documents a change made stale	Curation → “May be out of date” cards	`getCurationQueue`, then `curate`

Suggest-only, always. rooms points out what probably needs a look; a person decides and edits. It never rewrites a dependent, never “syncs” documents automatically, and never hides why something was flagged.