# Change tracking and diff checks

PM on Rails is not a build-it-once tool. Every time new meeting notes arrive it **updates existing requirements intelligently** and **tells downstream items (stories and tasks) and the people involved what changed**.

## Re-ingesting meeting notes and updating automatically (diff check)

As you hold more meetings on the same engagement, requirements shift little by little. When it generates requirement cards from new meeting notes, the AI compares them against the existing cards and finds the ones that should be updated.

![PM on Rails diff check. Similarity, before/after and create / update / skip. Before: you hunted the impact of new notes yourself. After: people choose only what to take in.](https://pmonrails.com/docs-img/diff-check.png)

- **Matching by meaning** — newly extracted requirement cards are **matched against existing cards with vector search**. Even when the wording differs, the same requirement is picked up (the "similarity" in the image above).
- **No automatic merge** — even when an overlap is found, nothing is merged for you. Several candidates are offered **newest first** as a starting point (with a badge on the newest one), and a person chooses.
- **Field-level diffs** — for each candidate you see "which field changes, and how" as a diff (for example, overview from "A" to "B", priority from Should to Must). Up to the 5 most recent candidates are shown.
- **Apply in bulk with three choices** — for each extracted requirement, pick "create new / update existing / skip" and apply them together.
- **Rationale is preserved** — for requirements built from source material, the link back to that source material survives updates ([Knowledge](https://pmonrails.com/en/docs/knowledge.md)).

## Ripple effects (automatic impact detection)

When a requirement changes, everything downstream of it is affected too.

- Updating a requirement card automatically finds and shows the **stories and acceptance scenarios** that move with it, along with which fields change.
- Marking a requirement card as **"Won't"** automatically moves the requirements derived from it to out of scope, so no requirement is left dangling.
- "What breaks if I change this" can also be checked with the chain-following features ([Manage progress](https://pmonrails.com/en/docs/progress.md), or for engineers [MCP](https://pmonrails.com/en/docs/mcp.md)).

## Making sure updates get noticed

Even when the AI or another member updates something, **the person doing the work is guaranteed to notice**.

![PM on Rails Changed badge on the scope board. Cards added or edited since you last looked are colour-coded. Before: you went looking for what was new. After: only your unread changes arrive on their own.](https://pmonrails.com/docs-img/scope-change-badge.png)

- **"New / Changed" on requirement cards (per person, auto-read)** — on the scope confirmation and requirement card screens, cards that were added or changed since the last time you personally viewed the screen are color-coded (the "Changed" badge in the image above). It is judged from your own last-viewed time, so once you have looked and moved on it is marked read automatically (no clicking required).
- **The "unreviewed upstream changes" list** — when the content of a requirement card, requirement, story, or scenario changes (by AI or by a person), the change is recorded and shown with a count as "unreviewed upstream changes" on the user story screen. You can see what changed (before and after) and which stories and scenarios are affected, and the AI proposes downstream updates too. Reviews are recorded per person.
- **Upstream change markers on tasks** — when the upstream of a task in progress (its requirement or scenario) changes, the task is marked so you can tell that upstream moved and has not been reflected yet.
- **Spec drift after work started** — if the spec changes after you started a task, the task is marked as needing a re-check when the pull request is merged.
- **Every record keeps its change time** — requirement cards, requirements, stories, scenarios, and tasks all record when their content changed. That is what lets implementers such as Claude Code ([MCP](https://pmonrails.com/en/docs/mcp.md)) detect that upstream changed after they started. Changes to the spec itself are treated separately from operations that only touch the assignee or the status.

## Change notifications

- When requirements or scope change, the people involved get a **change notification** (the in-app bell, email, or the daily digest).
- Requirements that have not been updated for a long time are flagged as stalled (a warning at 90 days, critical at 180 days). Pull requests stalled in review show up in the digest too.
- For the kinds of notifications and how to receive them, see [Notifications and Slack](https://pmonrails.com/en/docs/notifications.md).

## When an open question is answered, the spec updates

When a question on [Open questions](https://pmonrails.com/en/docs/clarifications.md) is answered and resolved, AI builds update proposals for the linked requirements, stories and scenarios. The proposals **wait for approval**, and the spec does not change until you apply them. When you press "Resolve" on the Open questions screen, AI drafts the proposals from the answer on the spot and shows the diff. "Apply" writes them to the spec; "Later" keeps them under "Update proposals awaiting approval", where you can "Apply" them one by one or all at once with "Apply all". "Create update proposal" on a resolved question opens the same view. While proposals are still waiting, the morning team status in the project's dev channel lists them under items to act on, oldest first, with how long each has waited, and mentions the person who resolved the question if their Slack account is linked. If the answer changes later, the old proposal is withdrawn and rebuilt. Proposals that an AI agent creates through the MCP tool `create_question_reflection_proposal` do not wait: they are written to the spec when the tool is called (the call itself counts as the approval).

**Downstream update proposals caused by direct edits** to requirement cards, requirements or stories by people or AI are reviewed in the update-proposal list and applied the same way.

## Switching versions (keeping history)

Changing an in-flight spec creates **a new version** rather than overwriting, and the old version stays as history (the same for requirement cards, requirements, stories, scenarios, and tasks). Details in [Bugs and change management](https://pmonrails.com/en/docs/bugs-changes.md).

## AI quality checks

The AI assistant can automatically point out **quality risks** such as requirements whose chain is broken, stories without scenarios, in-progress tasks left stale, and gaps in traceability ([AI assistant](https://pmonrails.com/en/docs/ai-assistant.md)).

## Next steps

- [Manage progress](https://pmonrails.com/en/docs/progress.md)

---

https://pmonrails.com/en/docs/change-tracking