A client document portal for consulting firms. Each SOP, policy or audit report lives on one link, where the client comments on the exact step, approves section by section and signs. The Assistant turns a comment into suggested edits to the text, tables and diagrams, and a consultant accepts each one before the next version goes to the same link.
Somewhere tonight a consultant is saving final_v7_FINAL.pdf and hoping the name is true.
Last week’s SOP came back as a reply-all thread and a set of notes on the PDF. Each comment means an edit in the Word file, a swimlane redrawn in another tool, a RACI row fixed by hand and a new PDF emailed. Then the replies start again.
At the end, someone signs whichever file they printed. Nobody can say which version the client approved, or whether anyone read past the summary.
That is a consultant’s judgement spent on chasing versions, on every document for every client.
Every review round happens on one link. When the client comments on a step, the consultant asks the Assistant for the edit and accepts it on the page before the next version goes to the same link.
| Step | By hand | With ProcessOS |
|---|---|---|
| Client feedback | Comments in email threads and PDF notes, merged by hand | The client comments on the exact step in the document. Each comment stays tied to that step and the version they read |
| A requested change | The consultant edits the Word file and hopes nothing else moved | The consultant asks the Assistant, quoting the comment. The edit is drawn on the page, and the consultant accepts or declines each suggestion |
| Diagrams and tables | The swimlane is redrawn in another tool and the RACI fixed by hand | Step lists, RACI tables and diagrams are structured parts of the document, so a new step, row or box shows in place, with the original one switch away |
| Publishing | A new PDF is saved and emailed | Only a consultant publishes. Publishing waits until every suggestion is decided and the print proof passes, then the client’s link opens the new version |
| Version of record | final_v7_FINAL.pdf and a guess | Every published version is kept unchanged, and the client sees what changed since their last review, side by side |
| Sign-off | A signature on whichever file was printed | The client approves section by section and signs the exact version. The signature is bound to that version, and a public page re-checks it |
| Who read what | No record of who read what | The consultant sees time, views and comments per section, and each signature carries how much of the document the signer’s browser reports as read |
| Access | An attachment anyone can forward | Each link can be restricted to named emails or a domain, opened with a one-time code sent by email, set to expire or revoked at any time |
What changes in this diagram: adds 1 step to the IT Support lane, after set up system access.
Bring one document your clients sign off, with the last round of comments it went through. We set it up as a live link in your house style and run its next review round on the link.
Discuss a system like thisEvery document is one typed object: an ordered list of blocks, 27 block types in all. The consultant’s edits, the Assistant’s accepted suggestions, the versions the client reads and the hash each signature records all come from that one object.
The app is Next.js and TypeScript on PostgreSQL through Prisma, with row-level security keeping each firm’s records apart and Redis queues running the Assistant and the PDF jobs. Drafting a first version from a brief can use any of seven model providers. The Assistant runs on Anthropic or OpenAI, because it works through tool calls.
The client’s link reads published versions only. Each one is stored unchanged with a SHA-256 hash of its content, and approvals and signatures bind to that hash. The PDF and Word copies are set from the same blocks.
Drafts the first version from a brief, then asks the Assistant to act on a comment
Reads, keeps a task plan, runs checks and proposes; 21 tools, none that publish
Resolves each proposal against the current draft: previous values, a dry run, the revision
Stores each published version unchanged and binds approvals and signatures to its hash
Comments, section approvals and signing, with a public page that re-checks each signature
The Assistant never sends a raw patch. It names the block and the change it wants, and the server resolves the block, the version and the previous value from the draft itself.
Signing records the SHA-256 hash of the published version the client read, with their intent, their consent and the share of the document their browser reports as read.
Follow the client’s comment from sheet 4 through one review round, from version 1 to the signature on version 2. The left edge of the drawing shows who does each step.
The client reads version 1 on the review link and leaves a comment on step 3, Set up system access. The comment is stored against that block and the published version they read, so it stays tied to the exact text it concerns.
In the workspace, the consultant attaches the whole document, keeps the working style on Suggest and quotes the comment in the request. In Suggest, nothing reaches the draft until a person accepts it.
The Assistant reads the outline and each block it will change, then keeps a task plan the consultant can follow: three changes, one per block. Every request runs inside fixed limits on steps, tool calls, time and spending, checked before each model call Verified: mechanism
It proposes one suggestion per block: a new step in the list, a new row in the RACI table and a new box in the IT Support lane. Each arrives as intent. The server checks that the block sits inside what the consultant attached, fills in its previous value from the current draft, dry-runs the change through full schema validation and saves it only if the draft has not moved. A diagram change that would stop the flowchart drawing is refused, with a note to make it smaller.
Each suggestion is drawn where it lands, with Accept and Decline at the block and a Changes / Original switch on the diagram. The consultant accepts all three. The Assistant then runs the five checks on the new draft, and each result records the revision it checked, so a later edit marks it as from an earlier version.
Publishing waits until no suggestion is open and the print proof passes. Version 2 is stored unchanged, and the client’s link now opens it, with a banner showing what changed since their last review. The approval round on version 1 closes with its decisions kept, and the consultant starts a new round for version 2.
The client signs in three steps, Review, Sign and Confirm, after a one-time code sent to their email confirms who they are. The record stores the SHA-256 hash of version 2 with their intent, consent and the share their browser reports as read, and the public verify page re-hashes the stored version against it. The next comment on version 2 starts the same loop, on the same link.
Each row is a promise about what a client sees or signs, and how the code keeps it.
Every row has a test that runs against the code and fails when the promise is broken.
ProcessOS runs from the consultant’s brief to the client’s signature, on one link per document.
A version for your firm keeps that path, with the Assistant suggesting and your consultants deciding, and fits it to your documents and the way your partners sign them off.
If your firm still sends each SOP as a PDF and chases comments and signatures by email, start with one document your clients sign off. Bring it with the last round of comments it went through.