Work a project's document register

What is being asked of somebody, what is in force, and what was replaced, for one project.

The register is arranged by what it wants from you. The review queue and the gaps come first, because those are what somebody has to act on. Then what is in force. Then what has been replaced.

Everything that adds to the register, meaning an upload, a recorded link or a noted gap, is a button that opens a form when you ask for it. The record itself is the first thing on the page rather than the third.

Filing from storage

Sync is the main action here, because it is how most of a register gets filled. It sits at the top right rather than in a caption. The dry run on the project sync page shows exactly what filing would do before anything is written.

The project's email intake address sits at the foot of the page, with a Copy button beside it. Only an admin can grant or revoke who may send to it, and regenerating it asks twice, because the old address stops working at once.

Superseding a document

Replacing a document is an act on a row. You open the form against the document you clicked, and it already knows which one you meant. The superseded document stays in the register, marked as replaced, because the fact that it was once in force is part of the record.

What the register feeds

A filed document is read for what it requires. Those requirements land in the constraint register and, where they gate an event, in the obligations register.

Reading a document that is already on the register, one at a time or twelve at a press, pulls the file back out of storage and sends it to the reader. It asks for the same standing as moving or uploading one, and it is offered only to people who have it. Each press reads the twelve oldest that have not been read; a document the reader has already seen and left in the queue is waiting on a person, and is not read again.

A press reads for up to four minutes and then stops, saying how many it did not reach; the next press continues with them. When the reader was asked about a document and failed, the row says so and that the kind on it is the filename's guess, so a failed read is not mistaken for a read that never happened; and when no reader is configured at all, the queue says that once, at the top.

What the reader sees is the document itself, not only its name: the first pages of a PDF, the words of a Word document, the rows of a workbook, and a scanned page or photo as an image. A PDF too large to send whole is read through its text, or through its first page or two when it is a scan. A file that cannot be read at all is filed by its name, and the row says so.

A picture is read as a PNG, JPEG, WebP or TIFF, and it is judged by what is in the file, not by what it is called. A photo whose bytes are something else, such as an HEIC or AVIF saved under a .jpg name, is not opened, and the row says which it was and to export it as a JPEG. Nothing is decoded on the strength of a filename.

Every Keep, correction, rejection and re-filing in the queue is kept as a record of what was proposed and what you said, so the reader can be measured against people's answers and improved through a reviewed change, never by adjusting itself. Those records hold the decision and the kinds, not the file.

Finding one

The Filed view has a search: words matched against the filename, the folder and what the register calls the document, in any order, and a kind to narrow by. A search is a flat list, because the folder a match sits in is one of the things it matched on and is printed on the row. Sorting keeps the search; switching to Needs you drops it, because a queue is worked in arrival order rather than searched. A search is an ordinary link and can be sent to somebody.