{"slug": "a-black-box-recorder-for-contracts", "title": "A black box recorder for contracts", "summary": "Lexifina added a Replay feature to its contract editor that plays back a document's drafting change by change, showing each human or AI contributor's edits, active time, token usage and per-call model cost on a single timeline. The replay is built on the Yjs shared-editing library, which stores each change server-side with its user and timestamp; server-side writes such as agent proposals now record who they were made for instead of appearing as a generic \"AI,\" and each named type agent gets its own row. Lexifina said the history is best-effort, with periodic full-document snapshots, gaps marked where updates were deleted, and fresh histories started by Word saves, version restores or file imports.", "body_md": "# A black box recorder for contracts\n\nWhen an agent drafts half a document, the user needs to know who wrote each word. We need to be able to replay exactly how the contract got there, even for multiplayer with parallel human and agent contributions.\n\n## Rewinding a document\n\n### What it does\n\nRewind, the Replay button in the editor, plays the document’s drafting back from the start, one change at a time, and shows who made each change. This update adds a panel under the replay with one row per collaborator, person or agent. Each row shows when they worked on the document and how much they changed. For AI work it also shows how many tokens were used and what they cost. The key is that this is not an opt-in lineage like git, and does not change how non-technical users work, it’s a touch of both a collaborative snapshot and detailed version control system.\n\n### Why\n\nMost firms see AI spend as a monthly total. A total cannot tell a supervising lawyer which agent run wrote a clause, whether that run was worth what it cost, or how a junior’s hour on the document compares with an agent’s two minutes. Because the time and tokens sit on the same timeline as the edits, you can drag to any moment and see the document as it was then, who was working on it, and what their work cost.\n\n### How the replay is built\n\nWhen people edit a document together, each change goes to the server as a small update and is saved with the user and the time. We use Yjs, a library for shared editing, for this. Replay downloads the updates and applies them in order in the browser, rebuilding the document at each step.\n\n### Retaining the whole history\n\nThe history is a best effort. The server periodically keeps a full copy of the document and deletes the updates before it. Saving a new version from Word, restoring an old version or importing a file starts a fresh history that records the one it replaced, so the replay continues across it. Missing parts of the history are marked as gaps, and versions saved before shared editing was switched on appear as chapter markers.\n\n### Telling people and agents apart\n\nEdits typed in the browser carry the user who typed them. Edits made by the server did not, for example an agent’s proposed change or a person accepting one in bulk, so they all showed up as one generic “AI”. Each of those writes now records who it was made for.\n\nA document can have several type agents, each with its own name and job, such as one that removes needless words and one that tightens vague standards. Each agent records its name when it starts work, so each gets its own row.\n\n### Where the time and tokens come from\n\n| Row | Time | Amount | \n|---|---|---|\n| **A person** | Time they actively worked on the document: the window was focused and they had recently typed or clicked. Recorded by Lexifina’s time capture in slices of up to 30 seconds. | Characters they added and removed. | \n| **A person’s AI assistant** | Each run on the document, from when it started to when it finished. | Tokens and cost of every model call in the run. | \n| **A type agent** | The same, plus each time someone gave it an instruction. | The same, plus the tracked changes it proposed. | \n\nCost is the model’s price at the time of each call. If a run starts sub-runs, their tokens are counted against the run that started them.\n\n## Who wrote this\n\n### What it shows\n\n- **Who wrote this.** Select text in the editor. Each part of the selection is listed with its author, the time and version of the edit, and the words it replaced. For text the agent wrote, it also shows who accepted it and the reason the agent gave.\n- **Clause history.** Every recorded change to a clause, in order, with the current text underlined by author.\n- **Search.** Search all changes to a document, including agent suggestions that were rejected.\n- **Authorship in the document.** An optional bar beside each paragraph, coloured by who edited it.\n\n### Agent edits\n\nWhen a save applies agent suggestions, the agent is credited only for paragraphs that a saved suggestion accounts for. Other changes in the same save are recorded as unknown. In a live editing session with one person typing, changes go to that person. If several people typed in the same session, the change is recorded as mixed and lists them.\n\n### Author of each character\n\nTo find who wrote each character of a paragraph’s current text, the indexer replays the paragraph’s records in order, keeping one author per character:\n\n``` python\ndef _apply(attr, before_len, after_len, ranges, who):\n    out, i = [], 0\n    for a, b, c, d in sorted(ranges):\n        out += attr[i:a] + [who] * (d - c)   # changed characters get this change's author\n        i = b\n    out += attr[i:]\n    if len(out) != after_len:                # ranges don't match the texts: credit the whole paragraph\n        return [who] * after_len\n    return out\n```\n\nA second list, updated the same way, keeps the record that wrote each character. That is what lets “Who wrote this” name the exact edit behind each part of a selection.\n\n### Use by the agent\n\nBefore the agent edits a clause, it is told if a lawyer rewrote its earlier wording there, or rejected its earlier suggestions. It can read the clause’s history with a tool before proposing something similar.\n\n## How the two fit together\n\nThe two features read different records. Rewind is built from shared-editing updates, which exist only for documents edited with shared editing switched on. Who wrote this is built from autosave revisions, which every document has, so it also works on documents that were never edited together.\n\nAgents propose edits as tracked changes, and both features read the tracked-change markings rather than the visible text. A proposal counts as whoever suggested it, and accepting or rejecting it is recorded as the decision of the person who did it.\n\n## Limitations\n\n- Everyone who can open a document can see everyone’s engaged time on it. There could be additional privacy controls here.\n- The Rewind panel should be connected to a matter’s time-recording policy or to timesheet generation, at least as a check, to keep everything in sync.\n- Paragraph history is not completely robust to cutting, changing and repositioning, lineage reconstruction is a multi-layered best-attempt.", "url": "https://wpnews.pro/news/a-black-box-recorder-for-contracts", "canonical_source": "https://lexifina.com/blog/a-black-box-recorder-for-contracts", "published_at": "2026-10-10 22:43:42+00:00", "updated_at": "2026-10-10 22:48:52.330944+00:00", "lang": "en", "topics": ["artificial-intelligence", "ai-agents", "ai-products", "developer-tools"], "entities": ["Lexifina", "Yjs", "Word"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/a-black-box-recorder-for-contracts", "markdown": "https://wpnews.pro/news/a-black-box-recorder-for-contracts.md", "text": "https://wpnews.pro/news/a-black-box-recorder-for-contracts.txt", "jsonld": "https://wpnews.pro/news/a-black-box-recorder-for-contracts.jsonld"}}