What we do, and what we have not done.

Bolvido is a shared-schema, multi-tenant system. Isolation is enforced by PostgreSQL row-level security, enabled and forced on every tenant-owned table, with a policy bound to the current tenant. The application connects as a non-superuser role that is itself subject to those policies.

The consequence is the one that matters: a query that forgets its tenant returns no rows rather than someone else's. The rule is not "remember the WHERE clause". The rule is enforced beneath the query.

The few operations that must read across tenants — authentication, before a tenant is even known — run through explicitly reviewed SECURITY DEFINER functions with a pinned search path, revoked from PUBLIC and granted only to the application role.

Evidence is append-only, enforced by database privilege: the application role holds SELECT and INSERT on the evidence table and nothing else. There is no code path to update or delete a piece of evidence, because the database would refuse it.

Every item is hashed with SHA-256 at capture and stored with its provenance: who captured it, when, on which job, for which requirement. A correction is a new item, never an overwrite. Proof you can edit is not proof.

Passwords are hashed with bcrypt. Sessions are HS256 bearer tokens whose subject is an external identifier, never an internal database id.

The password is verified before any account-state check, so the login endpoint cannot be used to enumerate which email addresses exist or which accounts are disabled. Every failure returns the same response.

Access is re-evaluated on every authenticated request, not at token issue. Deactivating a person or revoking their login takes effect on their next request rather than at token expiry.

Login is an optional capability of a person, granted explicitly. Most field workers never have one and are still assigned work.

• Dashboard access is limited to owners and managers. A worker authenticates for the mobile app and is refused at every office route.
• Execution authority belongs to a job's accepted Lead, and only the Lead: they start it, complete it, and sign it.
• Evidence capture requires a live assignment on that job. An unassigned user — including an owner — is refused.
• Nobody verifies their own work. The actor who performs a job never judges it.

Every job state change, every evidence item with its hash and its capturer, every verdict with the reason it was reached. Assignments are revoked rather than deleted, so the record of who was accountable when the work was performed cannot be rewritten by a later change.

Bolvido acts as a data processor on behalf of its customers. The personal data it handles is exactly what field verification requires: worker names, optional contact details, photographs captured during a job, one-time location proof, and signatures.

Location is captured once, at the site, for a job whose workflow asked for it. There is no background location, no route history, and no fleet view — not as a setting we leave off, but as a capability that does not exist in the product.

A Data Processing Agreement is available on request for customers who need one under GDPR Article 28. Write to [email protected]. We will publish a standard DPA and a sub-processor list before our first EU deployment.

Email [email protected]. Tell us what you found and how to reproduce it. We will acknowledge within two working days and keep you informed until it is fixed.

Please do not test against another company's data. If you need an account to reproduce something, ask and we will give you one.