A transaction can look almost closed for days. The checklist says complete, signatures arrive in separate inboxes, the funds email sounds reassuring—and then somebody discovers that an approval covered yesterday’s draft.
CloseRoom turns that fragile final mile into one evidence-backed system. It coordinates parties, conditions, documents, decisions, signatures and funds, then derives whether the transaction can actually close.
Readiness cannot be typed
A mandatory condition is complete only when its dependencies pass and its required evidence exists. Conditions that require verification separate the submitter from the verifier. Readiness is recalculated from those records and reports each blocking gate by category and subject.
“Ready” is the result of the evidence, never a colour someone picked in a spreadsheet.
Dependent
A downstream condition cannot outrun an unresolved mandatory predecessor.
Versioned
Every approval and signature names the exact document bytes it covers.
Frozen
The close event preserves the record used to authorise completion.
The version is the deal
CloseRoom gives every document one explicit current execution version. Approval requests and signature envelopes bind to it. Promoting a replacement version marks older approval and signature records stale, even if they were previously approved or completed. They remain in history but stop contributing to current readiness.
Resolve dependencies, submit evidence and obtain independent verification.
Promote one ready version and bind decisions and envelopes to it.
Collect every required signer and independently verify mandatory flows.
Hash the readiness result and exact evidence manifest in one close event.
One atomic close event
CloseRoom refuses the close call while any blocking gate remains or the actor lacks closing authority. When the final gate passes, it writes the authority, timestamp, note, readiness hash and manifest hash together and changes the transaction to closed in the same database transaction. A second close attempt conflicts; the original event cannot be replaced.
A book that matches the close
The closing book is generated from the frozen manifest, not from the room’s later contents. It contains the satisfied conditions, exact current document hashes, approval decisions, signature certificates and verified funds used at close. Post-close filings can continue, but they cannot rewrite that historical basis.
How it is built
CloseRoom uses the System32 house stack: a Go API with SQLite and a Next.js 16 / React 19 interface. Its demo portfolio contains 28 transactions, 920 conditions, 720 evidence records, 360 documents with 610 versions, 180 approvals, 145 envelopes with 390 recipients, 170 funds items, fourteen close events, 22 books and 1,500 activity events. Tests cover dependencies, evidence, independent verification, template snapshots, stale versions, signer completion, funds controls, authority, atomic close and book provenance.
CloseRoom is available now in the System32 catalog. Open a live transaction, inspect the blocking path, and follow its exact approved and signed version into the closing book.