Governance
Governance & data management
What the platform enforces, what it logs — and what it does not do today.
This page is deliberately plain. Every statement here matches what is actually implemented in the product. Where something is enforced only in the application and not on the server, it says so — because that distinction is exactly what matters in a dispute.
Roles & permissions
Access derives from the organisation role, the project role and optional per-document grants. The check is enforced on the server on both paths — in the application and on direct file access; the two share the rules but not the same code.
What the platform does
- Organisation roles: admin, manager and user — only the admin manages billing and roles.
- Permission levels build on each other: read ⊂ write ⊂ approve ⊂ manage.
- Nine project roles from construction practice with preset permissions — from project controller to public authorities.
- The right to sign off inspections is a separate, additional right: approval alone is not enough.
- Per-document grants can be issued; granting and revoking are logged.
- The check also applies on the direct file path — not only in the interface.
What it does not do today
- The “commenter” level is currently treated the same as “reader”.
- On the direct file path only one project membership is evaluated. Anyone holding several roles in the same project may have fewer rights there than in the application.
Project roles and their preset permissions
| Role | Permissions |
|---|---|
| Project controller | Read Write Approve Manage |
| Architect | Read Write Approve |
| Site manager | Read Write Approve |
| Specialist planner | Read Write |
| General contractor | Read Write |
| Health & safety coordinator | Read Write |
| Client | Read Approve |
| Subcontractor | Read |
| Public authorities | Read |
Presets; adjustable per project and per person. The levels build on each other — whoever may approve may also write.
Approvals
Approvals are where it shows whether a platform delivers what it promises. So we draw a clear line here between what the server enforces and what the application merely manages.
What the platform does
- Approval per document version: bound to the approval right, restricted to a fixed set of states, and logged.
- Anyone touching an approval field — status, suitability code, or the approval itself — needs the approval right, even with write permission only. The approver is taken from the authenticated session, not supplied by the caller.
- Daily site reports: multiple signers, frozen names and roles, the signature bound to the document's checksum, access links stored only as a hash.
- The sequential report number is issued in a single, indivisible step — no duplicate and no skipped numbers.
- Inspection sign-off requires the separate inspection right.
What it does not do today
- A document's status transition from WIP through Shared to Published is managed in the application. The server does not currently validate that transition.
- The general workflow engine with templates and distribution lists runs exclusively in the local browser.
Versioning
Revisions are kept as long as the retention rules allow — approved and rejected ones permanently. If a file is explicitly replaced, the previous revision is discarded.
What the platform does
- Before writing the metadata, the server verifies that the file exists and that its size matches.
- If the metadata step fails, the already uploaded file is removed again — no orphaned files are left behind.
- Restoring an old revision overwrites nothing: it creates a new version with its own copy of the file.
- Approved and rejected versions are excluded from clean-up.
- Every version can be downloaded individually and opened in the viewer.
What it does not do today
- There is no lock on concurrent editing. If two people save in parallel, two consecutive versions are created — nothing is merged.
- Preparation for 3D display is best-effort. If it fails, the version exists but cannot be displayed for the time being.
- Restoring only requires write permission. An approved version is therefore not locked against being superseded by a newer one.
Audit trail
Logging happens on the server and is append-only — but it does not cover everything. What is not captured is listed here.
What the platform does
- Document events are logged continuously: creation, status change, move, delete, new version, restore, comment, and the granting and revoking of access.
- Signature events are captured separately and as evidence — with checksum, timestamp, IP address and device identifier.
- The history is visible per document in the application.
- The server-side log can be exported as CSV or JSON — document and signature events chronologically in one file, with names resolved. The export is restricted to project administrators.
What it does not do today
- Changes to organisations, memberships, roles and billing are not logged.
- Downloads are not logged on the server.
- An export returns the most recent entries per log; very long histories are truncated — the application says so.
- The activity feed on the dashboard comes from local browser storage and is not reconciled with the server. It is not an audit trail.
Data storage
Three layers with distinct jobs: project and document data in the database, files in object storage, prepared model data locally in the browser.
What the platform does
- Files sit in object storage, strictly separated per project; path manipulation is rejected on the server.
- Models are parsed in the browser and cached locally. Once you place a model in project storage, the prepared geometry and property data is additionally stored in object storage so any device can open it directly.
- Storage limits per plan: 20 GiB on Free, 100 GiB on Team, by agreement on Enterprise.
- Retention rules govern the clean-up of old versions: the latest three, approved revisions and any shared through an active link are kept.
- Shared links can be protected with an expiry date and a password; accesses are counted.
- Our processors are named in the privacy notice: Cloudflare, Clerk and Stripe.
What it does not do today
- We do not contractually commit to a particular storage region and do not pin one technically.
- Beyond the platform's own encryption we do not additionally encrypt content at the application level.
- There is no bulk export of your project data and no self-service data portability.
- We do not operate a backup of our own beyond the platform's mechanisms.
- No automatic clean-up run is currently scheduled — the cleanup has to be triggered.
Export & data portability
Open formats, no proprietary containers — with one honest limitation on how plan limits are enforced.
What the platform does
- IFC: edited models are written back as IFC.
- BCF 2.1: import and export, for issues as well as for check reports. The issue export currently carries no viewpoints — findings arrive without a camera position and without an element selection.
- Excel and CSV from the data table and quality management.
- PDF: daily site reports including the signature page, defect QR codes, drawing and markup output.
- Classification systems as a lossless JSON bundle; rule sets as JSON.
- Every individual document version can be downloaded.
- Audit trail as CSV or JSON: the project's document and signature events.
What it does not do today
- We can read IDS but not author it.
- Four Free-plan export limits are checked only in the application, not on the server.
- GAEB import and export, the quantity exports, and merge and split are implemented but not yet enabled.
Standards — precisely
Which standard we support and to what depth. Partial means partial.
| Standard | Scope |
|---|---|
| IFC 2x3 & IFC 4 | Read, edit and write back. |
| BCF 2.1 | Import and export. Check reports are written without a snapshot image and without an extensions file; the issue export currently writes no viewpoints, so neither camera position nor element selection. The check-report export does carry the element selection. |
| IDS | Import and evaluation of a meaningful subset: entity, property, attribute, classification, cardinality, value ranges and patterns. Not supported: material and part-of facets, and authoring IDS. |
| DIN 276:2018-12 | Complete catalogue with 335 cost groups, a rule set for automatic assignment and write-back into the model. Cost roll-up across the group hierarchy is not implemented. |
| Uniclass | Available as a classification system. |
| LAS / LAZ | Point clouds are read entirely in the browser and rendered with levels of detail; as-built comparison against the model. E57 is read as well, but only to a limited degree today: the preferred conversion service is not deployed, so a less reliable fallback takes over. Please convert to LAS or LAZ. |
| GAEB DA XML 3.2 | Import and export are implemented but not yet enabled. |
| ISO 19650 | Orientation, not certified compliance. Suitability codes, revision codes, container structure and the PIM/AIM breakdown are implemented; the approval status transition is not enforced on the server, and the naming convention is stored but not validated. |
What we do not claim
This list is here because it is the most useful page when you compare vendors. It grows when we notice something, and shrinks when we have built something.
- We are not ISO 19650 certified and do not enforce the approval status transition on the server.
- We do not commit to a storage region or to availability unless that is expressly agreed by contract.
- We have no single sign-on, no dedicated instance and no on-premises operation. The corresponding enterprise items are marked “on request” because they are to be agreed contractually and are not part of the product.
- Our audit trail is not gapless: changes to roles, memberships and billing, and downloads, are not captured.
- We do not claim every geometric check is exact: collision checking confirms hits triangle-accurately, but distance, containment and duplicate checks work on bounding volumes.
- We have no reference customers to show. As soon as approved ones exist, they will be named here.
- Modules labelled “in development” store data locally in the browser. They are suitable for trying out, not for working as a team.
- We do not quote figures about processing limits that a code change could silently render false.
The statements on this page come from a code audit of the platform dated 25 August 2026.
Questions about governance or data protection?
We answer them concretely — including the awkward ones. Write to us, or have the permission and approval logic shown to you in a demo.