A construction project has shared facts and private truths.

The shared facts are obvious: scope, schedule, RFIs, submittals, change events, pay applications, meeting minutes, closeout requirements, and final acceptance.

The private truths are just as real. The owner has board reporting, funding pressure, internal risk, capital-plan tradeoffs, and facilities priorities. The contractor has margin, subcontractor performance, staffing constraints, buyout strategy, and claims posture.

Most CPM tools force those realities into one of two bad models.

Either everyone works in one shared space and hides sensitive context offline, or each side works in separate systems and reconciles the project by email, spreadsheet, and meeting memory.

Why one workspace is not enough

One workspace sounds collaborative until the project gets difficult.

The owner may want to track an internal forecast that differs from the contractor's current position. The GC may need to model schedule risk before raising it formally. The owner may want facilities to review closeout readiness without exposing board-sensitive funding notes. The contractor may need to manage subcontractor issues before they become owner-facing.

If the tool cannot separate shared facts from private working context, people create shadow systems.

That is where trust decays.

Why two disconnected systems are worse

The opposite model is also painful.

The owner uses one system. The GC uses another. The architect lives in email. The closeout log is a spreadsheet. The official record is whatever was attached to the last meeting agenda.

This protects privacy, but it breaks coordination. IDs do not match. Status fields drift. Attachments live in different places. The owner and contractor argue about which version of a change event is real.

The project needs a shared protocol, not a forced shared database.

Federation as the middle path

Sympl · Project is designed around cross-tenant federation.

That means the owner and contractor can each keep their own tenant, permissions, reporting, and private context while sharing selected project records through explicit rules. A change event can be visible to both sides. A forecast narrative can remain owner-private. A subcontractor reliability note can remain contractor-private. A closeout deliverable can be shared when it is ready for acceptance.

Federation is not a chat room. It is a data boundary.

The project can have one shared shape without pretending every participant has the same business interest.

Why this matters at closeout

Closeout is where the model becomes especially useful.

The contractor is responsible for delivering required documents, warranties, training records, attic stock, and final paperwork. The owner is responsible for accepting the building into operations. Facilities needs structured data, not just proof that the project team checked a box.

Federation lets each party do its job. The GC can manage delivery. The owner can review acceptance. Facilities can receive the operating data that matters. Sensitive internal notes stay where they belong.

The project stays coordinated without flattening the business reality behind it.

That is the idea behind Sympl · Project: one project, two tenants, explicit sharing, and a clean handoff into operations.