We talk a little bit about this in the paper, but just a bit. And it is an important question. Real entities change! We’re not just trying to create a representation of now, but a historical record of how we got here. The two ideas we played with that didn’t make it in the paper were 1) explicitly tell the NERD system to keep a timeline for each entity that tracks “core state” changes. 2) Let the NERD-agents also access the full change log of the NERD documents, so that they could see the history of the document. Possibly like a git history. For the paper we left these out because they were both too complicating.

the git history idea is interesting and probably worth revisiting. the complexity concern makes sense for a paper, but in practice git already solves a lot of the hard parts - branching for "what if" scenarios, blame for "what changed this field", diff for "what's the delta since last checkpoint".

for browser sessions the state problem is even more acute because you have multiple timescales: there's the slow-changing config state (proxy assignment, profile settings) and the fast-changing runtime state (cookies, auth tokens, detection score). a flat NERD document can capture the slow state pretty cleanly but the fast state goes stale the moment it's written. a timeline approach where the NERD just tracks "core state" transitions and points to external logs for the fast stuff might be the right split - you're not trying to snapshot everything, just the inflection points.

the complications in the paper might also look different once you scope it to a specific domain. for code entities the history is mostly append-only and agents mostly read it. for operational entities like browser sessions, the agent is writing frequently and needs to detect conflicts. those are pretty different access patterns.