Working with AI on analysis · 7/7
A report that is easier to understand can sometimes be harder to learn from.
We organize findings into clear conclusions, but that polish can hide the steps that changed our interpretation.
Once the active context has narrowed, another handoff question remains: when analysis crosses sessions, people, or agents, what should the workspace preserve? How can the next reader understand the assets it contains?
I recently built Change Context in Lantide. Its starting inspiration was Delta Lake’s transaction log. What I wanted to preserve was how analytical judgments changed.
Document versions do not necessarily preserve turning points
Suppose a team investigates declining retention after an event. Initially, we suspect the quality of the event.
After several queries, we notice more users from a new acquisition channel. We segment the population and check the observation period. Retention within groups has not clearly worsened. The overall decline appears more likely to involve a change in user composition, so we stop treating event quality as the leading explanation for now.
The final Report may contain only that organized conclusion.
The source data did not change, and the SQL may only have gained a few segmentation conditions. Our understanding of the question changed substantially. An agent reading only the latest version can see our current interpretation, but may not know the original suspicion, which results changed it, or what limitations remain.
Even if every document version exists, someone must reconstruct that history from the differences. I can see that the second paragraph was rewritten, but what did I discover at the time?
That is why preserving the final answer alone does not accumulate much analytical experience. The next task needs to know why we arrived here.
A perspective borrowed from Delta Lake
Delta Lake records committed changes in its transaction log, with checkpoints helping reconstruct table snapshots. Separating current state from committed history gave me a useful design perspective for an analysis workspace. Delta Lake protocol: Delta Log Entries
Could the workspace offer a current-state index alongside an ordered record of formal changes? A new agent could locate relevant assets. A returning agent could see changes since its previous position and decide what to reread.
Analysis adds a complication: file differences alone rarely explain a change in judgment.
“Updated Report section two” tells us where an edit happened. “The segmented results suggest a composition effect, so we revised the earlier suspicion about event quality” records its analytical meaning.
When an agent formally modifies a Plan, Report, Reference, or another managed asset, I therefore have it submit the relevant context with the change:
- What analytical judgment changed?
- Why did it change?
- Which evidence, and which version of it, supported the change?
The content and its stated background are recorded together. The relevant discussion and evidence are usually still available when the edit happens. Asking the next agent to reconstruct them from the finished document is archaeology again.
Git preserves versions. Why add Change Context?
Git can track versions and changes, and commit messages can preserve reasons. Connecting analytical judgments to evidence still requires conventions or an additional workflow.
I want this context to accumulate naturally as formal analysis assets are edited: changes in interpretation, stated reasons, and evidence references captured with as little extra recordkeeping as possible.
If the reason is unknown, do not invent one for history
I deliberately kept an option for unknown.
Someone might change a retention observation window from 14 to 30 days without leaving a reason. A later agent could suggest that the goal was to observe longer-term effects, or that the sample had not matured.
Both sound reasonable. Neither proves what the actual reason was.
If an explanation is added as though it were historical fact, a future agent may treat the guess as established team knowledge. It tried to complete the story and gave us a fictional past.
When the reason was not recorded, that uncertainty should be explicit. If an agent provides a reason, its source and confirmation status also need to remain visible. An asset being modified and a reason being recorded do not mean a person has confirmed the interpretation.
This is where the transaction analogy must stop. The system can check versions, references, and whether a submission completed. It cannot thereby guarantee that the analytical explanation is correct.
Change Context captures formal changes entering the workspace and the background recorded with them. Exploratory work that was never saved to an asset does not automatically become part of that history. It is not a backup of every step of the agent’s thinking.
It is also not a permanent repository of every historical asset body. It preserves committed change events, version identities, and the meaning stated at the time. Missing historical text or gaps in capture coverage must be disclosed. A recorded edit does not guarantee that an old document can be reconstructed.
What this can create is a traceable network among analysis assets: what we currently claim, which judgments changed, what evidence was recorded, and where uncertainty remains.
With that context, the next person or agent has a better basis for validation, disagreement, or reopening a path when new evidence appears.
Further reading
Try this way of working in Lantide Data: Download Lantide Data.
Previous：Context Does Not Have to Be Full Before We Compact It