Security
Most security pages are adjectives. This one is mechanisms and measurements. By default, every request to the platform's web application is held to its own organisation's data by the database itself — row-level security on a role that cannot switch it off — and the products it builds are audited across thirteen quality domains, eleven against fixed registries of named controls and two computed entirely in code, with every grade calculated from the findings, server-side.
Tenant isolation
The platform's web application connects to its database as a restricted Postgres role that cannot bypass row-level security. Every tenant-owned table, whether keyed to an organisation or to a product, carries a policy tied to the organisation the request is running in, and the policy checks writes as well as reads. A code path that loses that context does not see another tenant's rows — it sees none. Isolation that depends on every query remembering its filter fails open the first time one forgets; this fails closed.
A role that cannot opt out The web application's role has bypass disabled, so Postgres applies the policies whatever the query says.
Fails closed When a request carries no organisation context the policies match nothing, so a lost context returns an empty result rather than everyone's rows, and a write outside the organisation is refused.
Checked on every change An automated check in the test suite examines every database statement in the codebase for one that could reach tenant data with no organisation context, and a change that adds one fails the test.
Monitored at run time Alongside the static check, the database layer records what actually runs, flagging any statement that touches tenant data without an organisation context. A heartbeat means a quiet log can be told apart from monitoring that is switched off.
Products built on the platform are created this way from the start — each with its own database, its own row-level policies and an application role that cannot bypass them. How that is arranged is the technical dossier's subject.
The quality audit
Security is one of thirteen domains a product is scored on, and the security audit alone evaluates thirty named controls — each one written down in advance, with what to check and where to look for it, so two runs ask the same questions of the same code. Across the eleven domains that run against a registry there are 289 controls in all. Every finding is attributed to the control it failed and cited to where it was found, by file and line. Below, one live product's quality page: each domain graded from the control statuses its audit returned, and the aggregate across them.
What the controls cover
Registries, not adjectives. The security registry's thirty controls run from SQL and non-SQL injection and access-control enforcement through authentication integrity, password hashing strength, session expiry and invalidation, cookie attributes, OAuth state and JWT validation, cryptographic algorithm strength, secrets management, PII at rest, error-message safety, security headers, CORS, SSRF, rate limiting, dependency vulnerability scanning, webhook signature verification, API input validation and file-upload handling. The compliance registry adds forty-six more: audit logging of state changes and of sensitive-data access, consent collection and withdrawal, erasure, portability and rectification, retention enforcement, breach-notification paths, encryption at rest and in transit, key rotation and key isolation, row-level tenant isolation, access audit trails, minimum-necessary access, change management, incident response, and backup and recovery. Each control is evaluated per product, every failure is cited to file and line, and every grade is computed server-side. The machinery around the audits — architecture, tenancy, deployment and retention — is the technical dossier's subject.
How it is scored
The audit is arranged so the result cannot be flattering by construction.
Deterministic where it can be Two domains — database and integration health — are scored entirely in code, with no model involved. The database audit verifies the product's tenant isolation directly from its live Postgres catalogue. A check it could not perform is recorded as a finding rather than a pass. Accessibility runs a mechanical lint pass, its rules mapped to named controls, before its auditor sees the repository.
A purpose-built auditor per domain Each of the other eleven domains has its own auditor: its own control registry, its own instructions, and a toolset with no write access to the code it is judging.
A fixed control registry Findings are judged against a fixed registry of controls, not against whatever seems reasonable on the day.
Server-side scoring The auditor reports a status per control. The grade is arithmetic the server does from those statuses — the score an auditor volunteers is never read.
