Security · measured Aug 27, 2026 · 15:01 UTC
Most security pages describe intentions. The controls below are read from the database catalogue when you load this page, so they describe the system as deployed. If someone on this team ships a table without row-level security, the number moves that day — not at the next audit.
Measured from the database catalogue at the moment you loaded this page, not from a document written at audit time.
Tenancy is enforced by the database, not by a WHERE clause someone can forget. Counted from pg_catalog, so a table shipped without it moves this number the same day.
every ah_ table has row level security enabledA SECURITY DEFINER function in `public` runs as its owner and is reachable by anyone holding execute. Every one of ours lives in a private schema behind an explicit grant.
Privileged implementations live in ambition_private, never in publicAn unauthenticated caller holds execute on nothing in the private schema. Measured by asking the catalogue, not by reading the grant statements we intended to write.
anon holds execute on no privileged implementationBefore any policy is consulted, the anonymous role has no select privilege on a single tenant table. Policies are the second line here, not the first.
anon holds select on no ah_ tableA scan result is only evidence if you can say which version of the rulebook produced it. Scans without that attribution are counted and reported internally.
A caller's organisation and brand are derived inside the database from their membership rows. Nothing a client sends — no header, no body field, no query parameter — can widen what they can see, because the identity the policies consult is never taken from the request.
Every policy names the roles it applies to rather than relying on a single permissive rule. A policy written for an operator does not accidentally hold for an anonymous caller, which is the failure that turns one missing predicate into a full table read.
Functions that need to run with elevated rights sit in a private schema and are granted individually. The public schema — the only one an API client can reach — contains no privileged implementation at all, so there is nothing there to find.
Administrative surfaces require a second factor, and that requirement is evaluated in the same policies that evaluate tenancy. An application bug cannot route around it, because the application is not the thing checking.
The third figure is the one worth reading. A database test that runs as the owner never consults row-level security at all, so it proves the query works and nothing about who may run it. 36 of these suites switch into the real anon or authenticated role first and then assert what that role can and cannot reach — including one suite dedicated to the anonymous role specifically. This figure is generated from the suite files, so a suite that stops doing it lowers the number here.
| Suite | Covers | Assertions | Runs as |
|---|---|---|---|
| 0015_sprint_zero_database_contracts.sql | The test is transactional and leaves no fixtures behind | 2 | admin only |
| 0016_sprint_zero_contract_lock.sql | Sprint 0 contract-phase adversarial behavior tests | 7 | authenticated |
| 0017_sprint_one_provider_task_lifecycle.sql | Sprint 1 provider-task lifecycle adversarial contract | 6 | authenticated |
| 0018_sprint_one_communication_roundtrip.sql | Sprint 1 governed communication round-trip adversarial contract | 9 | authenticated |
| 0019_st021_fresh_rls_matrix.sql | ST-021: fresh-database authorization contract | 148 | anon, authenticated |
| 0020_onboarding_writers.sql | Onboarding writers: multi-store and 503A partner activation contract | 15 | authenticated |
| 0021_st027_invite_membership.sql | ST-027: invitation identity, delivery, acceptance, and membership contract | 80 | authenticated |
| 0022_st028_membership_context.sql | ST-028: multi-organization context and effective membership administration | 64 | authenticated |
| 0023_st029_membership_resolution.sql | ST-029: membership-native identity helpers, RLS, and cross-role context | 40 | authenticated |
| 0024_st030_totp_aal2.sql | ST-030: TOTP readiness, AAL2 network-admin enforcement, and audit boundary | 24 | authenticated |
| 0025_sprint_1_2_control_plane.sql | Sprint 1/2: control-plane isolation, environment guards, and portal scope | 28 | authenticated |
| 0026_launch_and_environment_path.sql | Launch finalization and the customer environment path | 16 | authenticated |
| 0027_brand_scope_and_theme.sql | Multi-brand operator scope and per-brand storefront theming | 12 | authenticated |
| 0028_brand_logo.sql | Brand logo: storage posture and the cross-brand boundary | 12 | authenticated |
| 0029_claim_provenance_and_formulary.sql | Claim provenance, the formulary refusal, and the publish gate | 22 | admin only |
| 0030_api_credentials.sql | Self-serve API credentials: the secret is never recoverable, and the resolver is never reachable by a tenant | 16 | admin only |
| 0031_gateway_delivery_engine.sql | The webhook delivery state machine | 21 | admin only |
| 0032_pharmacy_licensure_routing.sql | Pharmacy licensure is enforced at routing, and refusals are evidence | 15 | admin only |
| 0033_subscription_compliance.sql | Subscription billing, held to the complaint the FTC actually files | 20 | admin only |
| 0034_clinical_guardrails.sql | Contraindications stop a prescription, and a compounded one needs a determination that is actually about the patient | 14 | admin only |
| 0035_reliability_evidence.sql | A published number has to be a measured one | 16 | admin only |
| 0036_security_posture_and_analytics.sql | Posture read from the catalogue, and the revenue mix that screens an operator | 16 | admin only |
| 0037_analytics_surface_wrappers.sql | The sprint 13–20 analytics are reachable by the server and by nobody else | 13 | admin only |
| 0038_slo_measurement.sql | The collector derives observations and never invents them | 18 | admin only |
| 0039_multi_brand_at_scale.sql | Brand templates, honest batches, and the formulary ratchet | 44 | admin only |
| 0040_marketplace.sql | The three marketplaces, and the one thing they all have to get right | 57 | admin only |
| 0041_enterprise_readiness.sql | Enterprise readiness: what the SSO, BAA, SLA, and accreditation controls must refuse | 41 | admin only |
| 0042_pharmacy_hold_reason_constraint.sql | A held pharmacy carries a reason, and the constraint can actually say no | 7 | admin only |
| 0043_role_guard_null_safety.sql | A caller with no role is refused by the guards written to refuse them | 17 | authenticated |
| 0044_onboarding_formulary_selection.sql | The formulary selection an operator records before they sign | 44 | authenticated |
| 0045_funnel_and_refill_adherence.sql | The funnel refuses to round, and adherence refuses to comfort | 30 | admin only |
| 0046_enterprise_enforcement.sql | Enterprise enforcement: what the wired controls actually refuse | 21 | authenticated |
| 0047_launch_gate_enforcement.sql | The launch gate: what it derives, what it refuses, and what it records | 31 | authenticated |
| 0048_domain_tls_provisioning.sql | Certificate provisioning, and a live hostname a check cannot darken | 44 | authenticated |
| 0049_tenant_audit_export.sql | Tenant audit export: what it must refuse, and what it must never render as "no activity" | 16 | authenticated |
| 0050_append_only_grants.sql | An append-only table withholds the grants it is append-only about | 6 | admin only |
| 0051_configuration_gate_and_sso_revocation.sql | The readiness predicate is uniform, and a revoked membership stops enforcing | 10 | admin only |
| 0052_iam_capability_projection.sql | Fourteen roles the database called one, told apart | 40 | authenticated |
| 0053_iam_workflow_safe_mutations.sql | A command that cannot be gone around, and a grant that is actually gone | 31 | authenticated |
| 0054_iam_exact_role_cutover.sql | Exact-role cutover contract | 19 | admin only |
| 0055_identity_lifecycle_and_ownership.sql | TECH-IAM-007: environment-bound invitations, authority revalidation, two-party ownership transfer, and session/invitation invalidation | 30 | authenticated |
| 0056_governed_asset_uploads.sql | TECH-IAM-008: authorization-first quarantine, scan, finalize and cleanup | 29 | authenticated |
| 0057_hosted_auth_posture.sql | Hosted Auth signup abuse and admission posture | 7 | admin only |
| 0058_service_role_append_only_acl.sql | Service-role append-only ACL normalization | 6 | admin only |
| 0059_clinical_identity_and_credential_truth.sql | TECH-DATA-006/007: no fabricated identity or array-only licensure | 22 | authenticated |
| 0060_prescription_and_copy_tuple_truth.sql | TECH-DATA-002/005: prescription readiness is one exact clinical tuple | 21 | admin only |
| 0061_payment_subscription_and_financial_rls_truth.sql | TECH-DATA-003/004 + P0-RLS-01: exact financial tuples and scoped reads | 25 | authenticated |
| 0062_operational_task_state_machine.sql | TECH-DATA-009: overdue work is a durable, authorized operating loop | 29 | authenticated |
| 0063_evidence_chain_server_verification.sql | TECH-DATA-011: verification is recomputed and attested by the server | 24 | authenticated |
| 0064_durable_support_loop.sql | Sprint 3 support is one durable, idempotent operating loop from patient acceptance through workforce resolution | 32 | authenticated |
| 0065_gateway_worker_loop.sql | Sprint 3 gateway worker leases, settles, recovers, and opens owned exceptions | 25 | admin only |
| 0066_gateway_exact_audience.sql | Gateway metadata is exact-role, exact-tenant, and safe-column scoped | 16 | authenticated |
| 0067_operations_snapshot.sql | ST-024 / TECH-DATA-009: the operations projection is one bounded command, but remains at least as strict as the row policies it replaces | 11 | authenticated |
| 0068_participant_workspace_snapshots.sql | ST-024 / TECH-PERF-002: clinician and patient pages collapse their reads without weakening the exact participant tuple or the provider MFA boundary | 18 | authenticated |
| 0069_native_prescription_rail.sql | Native prescription rail: immutable signature, exact states, narrow browser writes | 44 | admin only |
| 0070_native_prescription_rail_compatibility.sql | Legacy synthetic fixtures coexist with strict native Rx tuples | 5 | admin only |
| 0071_real_launch_authorization.sql | Real-patient production authority is exact, independent, and re-derived | 34 | admin only |
| 0072_immutable_clinical_encounter.sql | Encounter notes are append-only drafts, one AAL2-signed record, and sealed addenda | 28 | admin only |
| 0073_prescription_clarification_roundtrip.sql | Pharmacy clarification responses are exact, AAL2-signed, durable, and delivered separately | 30 | admin only |
| 0074_prescription_supersession.sql | Signed prescriptions are corrected only through an exact, separately signed replacement | 25 | admin only |
| 0075_real_launch_operations_workspace.sql | The real-launch cockpit is minimum-necessary, AAL2-only, and scoped to the exact administrator, prescriber, or 503A partner assignment | 28 | authenticated |
| 0076_service_role_guarded_acl.sql | Hosted default privileges must not broaden the worker beyond its reviewed read-only gate and payload contract | 14 | admin only |
| 0077_cross_organization_clinical_record_ownership.sql | An independent medical-group membership can document care for a tenant-owned brand without changing which organization owns the resulting clinical record | 11 | authenticated |
| 0078_regulated_workforce_invitations.sql | Prescriber and pharmacy-partner invitation lifecycle | 23 | authenticated |
| 0079_patient_referral_invitations.sql | Invite-only patient enrollment: exact referral scope and fail-closed acceptance | 34 | authenticated |
| 0080_scoped_real_launch_authorization.sql | A real-launch authorization now carries an approved *set* of states, products, and prescribers instead of one scalar triple | 34 | admin only |
| 0081_prescriber_credentialing.sql | Credentialing a prescriber is the operational bottleneck of a multi-state programme: the work is "verify one licence" repeated per state | 28 | authenticated |
These are structural measurements, not a certification. A passing posture means the controls described above are in force in the deployed database; it does not mean an independent assessor has reviewed them. Where a third-party attestation exists we will link it here and say who performed it and when — an unattributed badge is not evidence.
Reliability is measured separately and published on the status page, including objectives we are currently missing. The compliance rulebook and formulary that gate what a brand may publish are readable without an account at the API reference.