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.
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.
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.
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.
Illustration of a role template. Names are examples.
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.
Guardian access is resolved in the database. Where there is no valid seat or grant, Reef does not show the record.
A guardian can hold a full-action seat or a strictly view-only seat in the household. Full access remains subject to permission.
A guardian outside the household can be given access to one child without a second bill and without visibility of the household ledger.
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.
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.
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.
Several protections are policy decisions rather than fixed behaviour, so each organization can match them to how it operates.
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:
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.
See how Reef can fit your programs, locations, staff, and families.