Glass Box

Security & data governance

Verifiable by design.

Glass Box was built for an audience that cannot afford to take security claims on trust. Every control below is enforced at the data layer or the workflow layer — not the application layer. The application is the last line of defence, not the first.

01

Row-level access control at the database

Every table in Glass Box carries a tenant_id and is scoped by Row-Level Security policies inside Postgres. When a logged-in LP queries the database, the database itself filters the rows before the application sees them. An LP physically cannot retrieve another LP's commitments, NAV snapshots, capital activity, watchlist transitions, or AI narratives. A GP cannot retrieve data from a different tenant. This is enforced regardless of any bug in the application code.

02

Role-based write protection

Reads are scoped by RLS. Writes are gated by named role checks. Voting on a decision requires the IC voter flag. Approving an LP publication requires compliance privileges. Overriding a credit rating requires CRO authority. Stage advancement at gates requires named partner approval. Every privileged action audits the actor and the action.

03

Append-only audit trail

The stage_log table is immutable at the database trigger level — no row can be updated or deleted once written, even by a superuser. Every meaningful action across deals, decisions, risks, ratings, and publications writes to entity_change with the before/after JSONB, the actor, and the reason. The audit trail is the natural by-product of using the system, not a separate compliance step.

04

AI under human approval

Every AI-drafted memo, narrative, and LP publication is reviewed by a named GP team member before any LP sees it. The compliance step before LP publication is a hard gate, not a suggestion. AI outputs carry source citations. The variance narrative engine cites the bridge components and KPI deltas it used. The credit rating engine reproduces the methodology document's worked examples to four decimal places.

05

Explicit LP visibility

LP visibility is a property of the publication, not an emergent consequence of layout. Every LP-facing item moves through a four-stage workflow: internal draft → AI-generated → needs review → compliance review → approved → published. Audience targeting is explicit: all LPs, LP advisory committee only, specific LP, or GP archive. Redactions applied during the AI rewrite are logged.

06

Hosting & data residency

Glass Box runs on Supabase Postgres (London, eu-west-2 region) for institutional UK data residency, and Vercel for application hosting. SOC 2 Type II and ISO 27001 certifications are available on the enterprise infrastructure tier. Production deployments run with daily encrypted backups, custom SMTP for branded auth emails, and audit logs that survive infrastructure incidents.

07

Independent methodology review

The Carnegie Credit Assessment Methodology was authored by the Chief Risk Officer at Point Break Partners. The TypeScript implementation is regression-tested against the methodology document's worked examples. Findings from the independent implementation — including arithmetic discrepancies — are surfaced to the author for review, not silenced. The principle is: every methodology question has a verifiable answer.

Due diligence

Detailed due-diligence questionnaires for institutional LPs and investment consultants are available on request, including the Standard Information Gathering questionnaire (SIG), the Cloud Security Alliance CAIQ, and our internal data-residency & sub-processor register.

Request a DD pack
Glass Box