Tenant boundaries are enforced by the database, not by carefulness.

• Tenant rows carry an organization key and are subject to Postgres row-level security under a dedicated runtime role that cannot bypass it.
• Every tenant query carries transaction-local tenant context, so the boundary is enforced per transaction rather than assumed by the caller.
• JobSite's API routes resolve the caller's active organization membership and assert the record's organization before answering.
• JobSite's tables live in a Postgres shared with other Baldwin products. Isolation is by schema and row-level security, not by a separate database instance — stated plainly because the distinction matters to anyone assessing it.

• Consent records are append-only: a database trigger rejects UPDATE and DELETE, so a withdrawal adds a record rather than erasing history.
• Decision and audit ledgers are append-only and hash-chained at the database level.
• Document versions are content-addressed by a SHA-256 content hash, so re-uploading identical bytes is the same version.
• Holdback movements post to a double-entry ledger whose balances are prevented from going negative by a database constraint rather than by application code.

• Nothing reaches a builder's public website unless the builder flagged the record public and gave it a public label. A single module is the only permitted path and it copies an explicit allowlist of fields.
• A testimonial cannot publish without both staff approval and a recorded consent timestamp. With neither present, the section renders nothing — which is the correct output, not a defect.

• HTTPS with HSTS (two-year max-age, includeSubDomains, preload), X-Frame-Options: DENY, X-Content-Type-Options: nosniff, Referrer-Policy: strict-origin-when-cross-origin, and a camera/microphone/geolocation Permissions-Policy.
• A content-security policy on every page and API response with default-src 'self', frame-ancestors 'none', base-uri 'self' and form-action 'self', identical in both policy modes.
• A per-request nonce with 'strict-dynamic' on the signed-in workspace, the client and trade portals, the sign-in pages, the API routes, and builder-hosted site pages.

The nonce applies to an enumerated set of surfaces, not to a category. Two session-gated pages — the site-admin console and the support guide — live in the statically prerendered marketing group, so they are served 'unsafe-inline' with no nonce: being behind a session is not the same as being rendered per request, and only a per-request render can stamp a nonce. That is a deliberate, bounded trade rather than an oversight, and it is published here because the alternative wording would have been false.

File quarantine and a support-access model are present in the schema, and an approvals queue exists for high-risk agent actions. No operating evidence for any of them was produced, so they are described as designed behaviour and are not offered as controls in force. Workforce authentication hardware claims have been removed from the privacy notice for the same reason.

Accepted work, provider acceptance and final completion are separate states, and a degraded dependency does not become a fabricated success. The public status check reports only whether the JobSite web process answered the request and says so on the page.

The public status check