Scope cannot be widened quietly
Scope lives in the title and the description, so neither can be rewritten without the old version surviving. Everything else that moves on a record, status, priority, privacy, assignee, due date, is on one timeline with who did it, when, and from where.
Three questions a record should already answer
The description says something wider than it did in March, and nobody can prove when.
It was urgent, then it was not, and the only witness is somebody's memory.
An automated write looks identical to a person's, so nobody trusts either.
Every edit keeps the version it replaced
Editing the title or description of an issue, a feature request, a change request or a client request snapshots the previous wording first, with who made the change and when. An agent doing the same thing over MCP goes through exactly the same path.
Nothing is recorded when an edit leaves both fields unchanged, so status changes, reassignments and comments do not fill the history with noise. Versions are kept per record for the life of the record, and the original is always reachable.
- An edited marker with a count, and a dialog showing any version
- Conversion carries the whole history onto the new record
- Editing a comment marks it, and the bubble carries an updated note
Export returns an empty CSV on Safari
One timeline, with the source written on it
Status, priority, privacy, assignee, due date, title, description, creation, conversion and deletion all land on a single trail with the old value beside the new one, the person who did it, and whether it came from a browser or over MCP. Comments are interleaved into the same timeline, so a record reads as one story rather than two tabs.
Where AI triage is enabled, its verdicts are on the same trail as a system actor, so an automatic decision is never mistaken for somebody's judgement.
- Sorting is stamped with who sorted it and the reason they gave
- Closing records the closing date and reason, and issues can record why the work existed
- Every member table records who added somebody and when
Activity · ISS-104
The client trail is reduced, on purpose
Clients see the changes that concern them and not the internal argument behind them. Privacy flips, priority changes and module changes are never shown to them, and there is no trail at all on an internal record because there is no record for them to open.
Reasons are the part they should read. A sort reason and a closing reason sit on the record where they can see them, which is the difference between being told a decision and being shown one.
- Nothing on internal records reaches a client trail
- Comments and attachments survive the conversion, so they never repeat themselves
- Records are append only: history is not silently rewritten
The project's story, week by week
A record's trail answers what happened to one item. A project's Activity tab answers what happened to the project: one timeline grouped by week, covering work items that changed, members added or removed and by whom, meetings that took place, files, links and notes shared with the client, and changes to the project's secrets register.
It is the same evidence read at the altitude a status conversation actually happens at, which is why it exists as a tab rather than as a report somebody assembles. Clients see the parts that concern them, the same reduction their record trail already makes.
- Sharing a file with a client lands on the timeline as an event, with who did it
- A meeting that took place appears with the work items it was linked to
- Nothing from an internal record reaches a client's view of the timeline
Activity · week of 31 Aug
- A revision screen for task history: today a task's older wording is read through the API rather than a dialog.
The things teams ask about this
Can I read an old version of a description in the app?
On issues, feature and change requests and client requests, yes: the record carries an edited marker with a count and a dialog that shows any version, with the original always reachable. Tasks keep their history on the server rather than behind a dialog, so an older wording there is read through the API today.
What exactly lands on the activity trail?
Status, priority, privacy, assignee and due date changes, title and description edits, and the creation, conversion and deletion of the record, each with the old and new value, who did it and whether the change came from a browser or over MCP. Comments are interleaved into the same timeline, and where AI triage is enabled its verdicts appear there as a system actor.
Does a change made by an agent look different from one made by a person?
It is attributed to the same user, because the token carries their permissions, but the source is recorded as MCP rather than web on every entry. Title and description edits go into the same version history whichever surface they came from, so you read the wording change the same way and can still tell how it arrived.
How long is any of this kept?
Versions and the activity trail are kept for the life of the record, and conversion carries both onto the new record rather than starting fresh. Records are append only: if a status changed, the trail says who changed it and when, permanently. The one thing with a shorter life is the server error log, which is deliberately kept for thirty days.
Where this connects to the rest of it
See it against your own work
Thirty minutes on a call, one of your real client projects on the screen, and an honest answer about whether this part of the product earns its place in how you work.
partnerships@dhcertainty.com