Version four
The living read
The name is literal: it knows what day it is, staying true or ceasing to be true as time passes, and saying so. For a client, it is the file that stays current as documents arrive over weeks, shows what is in force on any date from the policies’ own printed terms, and says what needs attention. Each version changed the unit of value: the reading, the reviewed reading, the compared reading. V4’s unit is the client’s file, and the product becomes a system of record: a reading is one event in a history the broker keeps, not the whole of what is kept. Its requirements came from the audience’s own meeting notes of 21 August, every one of which assumes something above a single reading.
The contract is settled and recorded, ADR 0009. The front door is built on top of the parts that already ran, and it is where each demo now starts; the V4 demo opens a client’s file and shows the trail beside it. The rest of the file is designed, and this page labels every piece.
Five objects, in plain terms
- The run. One execution of the reading over one set of documents. It is what the product stores today under the name review, and it never changes after it finishes: not edited, not appended to, replayable years later exactly as it was.
- The trail. The file’s history, and the audit trail, because they are the same thing. Every action is an entry: a run executed, a document added, a match confirmed, a value settled, a reading superseded. Each entry says who, when, and what it acted on. Entries are never changed or removed; a mistake is reversed by a later entry, never erased. What was known on a given date is the trail read up to that date, so a determination made later cannot color what was known earlier.
- The file. One per subject: the client’s file, in the broker’s own vocabulary. It holds the client, the declared subject, who is working it, and the pool of documents, and it points at the current reading. Everything else it appears to contain is derived from the trail.
- The document. An exhibit in the file’s pool, identified by its content fingerprint, which ingest already computes. The same exhibit can serve many pieces of work without being copied, and a citation resolves against the exhibit itself, which is what keeps a citation meaningful years later.
- The scenario. A named piece of work inside the file, typed by what it takes in: a read takes documents, a comparison takes two readings, a loss run entry takes a reading and a loss run. The scenario’s type is where the work’s declared purpose lives.
Three disciplines hold the five together: a run is immutable, the trail is append only, and the file’s present state is a pointer that moves. Nothing is ever edited in place, so supersede is honest: an entry saying so, and the pointer moving.
Filed work and scratch work
Selecting a client and working their file is filed work: tracked in the trail, kept. The standalone review is scratch work, stated plainly in the product as outside the system, nothing kept, with one honest one-way door: while the session still holds the documents, the work can be filed to a client. The existing promise on uploads, read and discard, is the scratch mode’s guarantee and is unchanged. Storing an uploaded document becomes a choice made at upload, per file: read and discard, or file with the client. Neither is a default imposed silently.
The state of every piece
- Built and live: persistence behind the storage interface when a database is configured; the readings history, grouped by client, with any two readings openable as a comparison; a person’s confirmation of a near match completing the tower, recorded as a decision; the front door, inside each demo, where a broker selects a client and sees the work their documents support, or reads documents with no client at all; and the V4 demo, where a client’s file opens: the work their documents support, the readings filed under their name, the current reading marked as current, and the trail entries with their dates.
- Built and not demonstrated: the renewal comparison, the expiring reading against the proposed one, derived fresh from two stored readings on every view. It answers the meeting’s first ask and has not yet been shown to the audience that asked.
- Designed: the five objects and the migration to them, every stored review becoming a file with one scenario, one run, and an empty trail; the scenario as a stored object owning its runs, rather than the named piece of work the client’s file derives from the corpus today; a reading writing its own entry when it runs, which today only reopen and add and the resemblance answer do; reopen and add for uploads, so a filed document can be joined by the ones that arrive after it; the check that the documents name the subject the file declares.
- Direction: the portfolio, many files held against one requirement, the building owner with twenty tenants; personas beyond the broker. The contract forbids the file from foreclosing the portfolio and does not build it.
Done when
A client’s file opens to its own history: the runs as entries in a trail, the current reading marked current, a superseded reading still readable, and a document added later joining the same file. Part of that stands: a client is selected first and their work opens under their name, a reading run there is filed under that client and listed on the readings page, and the V4 demo shows the file, its current reading, and its trail. A reading still does not write its own entry when it runs, so the trail is visible but not yet the whole history the contract describes. This page says so rather than letting the page imply otherwise.