How do you keep engineering context alive when requirements change? Post:

PM here, curious how others handle this.

Scenario that happens constantly:

1. We document requirements thoroughly
2. Engineering builds it
3. Three months later, we need to modify something
4. Nobody remembers why certain decisions were made
5. Engineering has to reverse-engineer the "why" before changing anything

The problem isn't the documentation. We have docs. The problem is the documentation doesn't capture the discussions, debates, and trade-offs that happened during the build.

When I ask "why is it built this way?", the answer is often "let me check Slack" or "I think we discussed this in a meeting but not sure which one."

Is this just an accepted cost of product development? Or is there a process that keeps this context alive?

Not asking about specific tools - more interested in processes, rituals, or habits that work.