Security and access

Access designed around real roles, relationships, and locations.

Reef combines interface controls with database-enforced policies so a hidden button is never the only thing protecting data.

This page describes how access actually works in Reef. It is written for the person at your organization who has to sign off on a new system - an owner, an operations lead, or an IT reviewer.

Two ideas run through everything below. The first is that permission is enforced twice: in the interface a person uses, and again in the database that answers their query. The second is that when Reef cannot find a valid reason to show a record, it does not show it.

Protect access in the database, not only the interface.

Hiding a button is a usability decision. It is not an access control. Reef treats the database policy as the control, and the interface as the courtesy.

Pillar one

Tenant separation

Every record in Reef belongs to an organization, and database policies prevent one organization from reading another’s data. In technical terms, Reef applies Postgres Row Level Security throughout the database.

That separation belongs to the data itself rather than to any particular screen, so it holds for every way into the platform.

  • Organization scope on every record
  • Separation enforced in the data, not the screen
  • Policies evaluated per query, not per screen
Pillar two

Role and action permissions

Approximately 30 permissions cover operational areas such as roster, billing, documents, schedules, incidents, timesheets, settings, and integrations. Organizations assign them through role templates and can then override individual users where a person does not fit the template.

This is what lets a front-desk lead approve enrollments without seeing the finance dashboard, or a head coach record pass-offs without gaining access to timesheets.

Role template · assistant coach
Roster - assigned groups Tiered scope ✓ Allowed
Attendance Own classes ✓ Allowed
Billing No permission ✕ Denied
Timesheet approval No permission ✕ Denied

Illustration of a role template. Names are examples.

Pillar three

Data scope

Location assignment gates data. Permissions gate actions. The two are separate controls, and an organization sets them independently.

Staff and athletes can be assigned to one location or to many. Location-restricted access is enforced in the database, while organization-wide records stay visible to the staff who need them. Assigned-group tiers narrow roster and attendance access further, so a coach can be limited to the athletes they actually work with.

  • Global location scope across operational screens
  • Primary and multi-location assignment for staff and athletes
  • Assigned-group-only roster and attendance tiers
  • Database-enforced location restriction
  • Organization-wide records remain visible
Pillar four

Family access

Guardian access is resolved in the database. Where there is no valid seat or grant, Reef does not show the record.

Household seats

A guardian can hold a full-action seat or a strictly view-only seat in the household. Full access remains subject to permission.

Child-specific grants

A guardian outside the household can be given access to one child without a second bill and without visibility of the household ledger.

Per-child exceptions

Access can be blocked or downgraded for one child without changing access to the others.

Reef models access, not legal status. It does not verify custody arrangements automatically, and it does not attempt to encode any jurisdiction’s family law. Organizations set the access that matches the arrangement they have been told about.

Pillar five

Payment integrity

The price is calculated by Reef, not the browser, and it is checked again at confirmation - so the amount a family is charged is the amount Reef calculated.

Payment state comes from Stripe webhooks. A success screen is a user-interface event; the webhook is the record. During enrollment, Reef authorizes the charge, claims the seat, and only then captures - cancelling the authorization if the class filled during checkout, and refunding automatically if a later step fails.

Stripe webhooks - not the success screen - determine payment state.

Payments are processed by Stripe. Each organization onboards to its own Stripe Connect Express account and receives its own payouts. Reef is not a bank, a merchant of record, or a payment processor.

A parent is never charged for a seat they didn’t get.

Authorize, claim the seat, capture. If the seat is gone, the authorization is cancelled instead of captured.

Pillar six

AI boundaries

The staff assistant only receives the tools the current user is allowed to use, and its reads execute under that user’s database policies. If someone cannot open a record in the interface, asking the assistant for it does not produce a different answer.

Be clear about what that boundary is and is not. It is a permission boundary - it governs what the assistant is able to reach. It is not a claim that a language model is always correct. Staff review what the assistant produces, and the actions it can take are limited to the supported set.

The AI assistant cannot bypass a user’s permissions.

Tools are permission-scoped at the tool level, and reads run with the calling user’s access.

See what the assistant can do

Configurable

Controls your organization sets

Several protections are policy decisions rather than fixed behaviour, so each organization can match them to how it operates.

  • Per-location geofences for time-clock punches, with authorized override
  • Approval requirements for unscheduled punches and payroll
  • A sensitive-document tier with restricted access
  • Staff-only notes kept separate from family-visible information
  • Role templates plus per-user permission overrides
  • Required forms that gate enrollment completion
Being precise

What we do not claim

This page describes architecture we can point at in the product. It is not a compliance statement, and it should not be read as one.

Bangai Labs does not currently make claims about, and nothing on this website should be taken as asserting, any of the following:

  • SOC 2
  • HIPAA
  • PCI certification by Reef
  • FERPA
  • GDPR compliance
  • COPPA compliance
  • Encryption specifics
  • Data residency
  • Backup arrangements
  • RTO or RPO targets
  • Service level agreements
  • Penetration testing
  • Breach response commitments
  • Uptime figures

About this website

The marketing site you are reading is deliberately self-contained. It loads no third-party scripts, no third-party fonts, no advertising tags, and no session-replay or fingerprinting tools. Fonts and images are served from this domain. That keeps the attack surface small and means visiting these pages does not hand your browsing to anyone else.

The Reef application is assessed separately from this website. See privacy for the status of published policies.

Bring every role into the same current.

See how Reef can fit your programs, locations, staff, and families.