Exchange
One revision, every party
A head contractor publishes a new revision against the master spec. Exchange figures out, for each subcontractor on the project, the subset of clauses that touches their scope and routes that delta — with an acknowledgement request.
How it works
You issue one revision. Exchange does the per-sub computation: it intersects the changed clauses with each sub's declared scope and produces a per-sub delta. The sub sees only what affects them, on the same revision number as the master.
On a project with twelve subs, you take one publish action; twelve subs get the read against their work.
How the routing decides who gets what
Three inputs drive the routing:
- Subs are bound to scope tags on their invitation — for example, electrical, structural, hydraulic.
- Clauses carry scope metadata, derived from the document structure and refined with manual overrides where the structure is ambiguous.
- A change to a clause routes to every sub whose declared scope intersects the clause's scope tags.
Scope tagging on a new project
Time invested in scope tagging during project setup pays back every revision. Exchange ships sensible defaults, but a five-minute pass with your CA at kickoff produces noticeably cleaner per-sub deltas across the life of the job.Acknowledgement workflow
Acknowledgement is per-clause, not per-document — so a sub explicitly accepts each clause change that touches them.
- Sub view — the diff against their scope plus a per-clause acknowledge button. Optional comment per clause if they object.
- Head contractor view — a live status board showing who has read, who has acknowledged, who is overdue. Reminder cadence is configurable per project.
- Audit log — every read, acknowledgement, comment, and reminder writes a row to the write-once audit log with actor + org + credential snapshot.