Tenancy and access
Data is scoped to the organisation and project that own it. Row-level security is enabled on every application table in the public schema, with 890 policies applying that scoping to user-originated reads and writes.
Security and controls
Enforced in the database for user-originated writes.
An assurance record is only worth what its controls can guarantee. BuildAssure puts the controls that matter — authority, evidence, history — beneath the interface, where bypassing the screen does not bypass the rule.
Authority
Signing, rejecting and releasing are role-checked in the database. Direct signature insertion is restricted; a signature exists because the signing action ran, with the right role, at the right step.
Evidence
Evidence rules — such as Red and Amber audit answers requiring an evidence note — are database constraints, not form validation. They hold for every user-originated write path.
History
Key record types carry append-only histories. Updates and deletes to recorded events are blocked; corrections are new events with a named author.
Reporting
Completed insight reports are published as immutable snapshots, so a report reviewed by leadership cannot quietly change afterwards.
Scope of the claim
These controls constrain user-originated writes. Platform administration and infrastructure operate under their own responsibilities — we do not claim the service role or infrastructure administrators can never bypass controls.
Security and controls
Controls that do not disappear when someone bypasses the screen
Key controls are enforced beneath the interface, in the database, for user-originated writes. The screen is a convenience; the control is the constraint.
Row-level security throughout
Every application table in the public schema has row-level security enabled, backed by 890 policies scoping data to the organisations and projects that own it.
Append-only histories
Key record types keep append-only histories. Corrections are new events with a named author, never edits to what was recorded.
Authority checks in the database
Who can sign, reject or release is checked in the database for user-originated writes — not only in the interface.
Evidence rules enforced
Rules like “Red and Amber audit answers require an evidence note” are database constraints, so they hold however the record is written.
Immutable published reports
Completed insight reports are published as immutable snapshots. The pack the board saw stays the pack the board saw.
See how BuildAssure would structure one of your live work packages.
Bring a package name, an ITP or a project specification. We will show how BuildAssure turns it into a controlled project workflow.