Evidence and audit

The record, and why it holds

Every deploy, decision, comment, exception and administrative change is appended to a hash chain. It is append-only at the database level rather than by convention:

• the application has insert and select rights only, and no delete on any table;
• database triggers reject updates, deletes and truncation for every role, the table owner included;
• events are chained with SHA-256, so altering who approved something, or when, breaks verification;
• the chain head is periodically anchored, because a hash chain alone cannot detect its own tail being truncated.

Each organization has its own chain starting at sequence 1, so your evidence neither contains nor depends on anybody else's events. Administration is in the same chain as the deploys, so "who made this person an approver" is evidence of the same quality as "who approved this deploy".

Giving an auditor something to check

The Evidence screen does three things, and an auditor with a token can do all three directly:

• Verify the chain. It either verifies or it names the event that broke and why — the answer to a failed verification is the finding itself, not an error about the request.
• Report when the head was last anchored.
• Download date-ranged exports, as CSV and as JSON.

When the auditor samples individual changes rather than a date range, each request has its own Export PDF: the request, its review and its conversation in one file, numbered against the chain.

Each deploy carries a separation-of-duties verdict — compliant, automated, non-compliant or undecided — and the same four appear in the export, on the badge and in Insights, so the three cannot disagree.

On a schedule rather than by hand: the same records, and the same verification, are on the HTTP API, so a warehouse job or a compliance platform can pull them without anybody remembering to. An administrator creates a token with evidence:read.

Insights

For one app or all of them over a chosen period: how often it ships, who is doing the work, how long a decision takes. Everything on the screen is one read of that slice, so the tiles, the charts and the tables cannot disagree with each other.

It deliberately does not keep score. Deploy activity plots what Bubble says shipped against what was approved here — where the first bar is taller, something shipped that nobody agreed to, and that gap is the point of the chart. Time to decide is a median and a 90th percentile rather than a mean, because one request that sat over a long weekend should not describe everyone's experience. Raising and deciding are counted in separate columns and never added together: the whole control is that one person does not do both to the same request.

Public apps

An app can be made public, the way a repository can: its deploy record gets a read-only page anybody can open without signing in, at /organization-slug/bubble-app-id, the way a repository lives under its owner. It is for showing a customer, an auditor or the world how an app ships without inviting them into the console or sending a CSV every month. Every app is private until an owner or administrator opens it under Settings → Apps and chooses Make public, typing the app's Bubble id to confirm.

The page has three tabs, in BuildGate's own terms:

• Overview — the branch pair, the latest deploys, and How this app ships: a statement of the gate and the rules the app's rulesets switch on, generated from its settings so it cannot promise more than the gate does.
• Deploys — every deploy that shipped, by day.
• Approvals — every deploy request, open or closed.

Beside them is an About box with a description and a website, which an administrator writes in the same place. An organization with at least one public app also gets a page at /organization-slug listing them.

Private apps have the same page, for your own organization: signed in to the console, any member can open a private app's page (it is labelled Private), and the organization page lists private apps alongside public ones. To anybody else, a private app and an app that does not exist answer the same way, so the page cannot be used to find out what an organization governs. Making an app private again takes its page down at once — it is never cached. Both changes are recorded in the chain as app_updated, like every other change to an app.

For an auditor

The full control narrative — the control as designed, what to test, and the known limitations stated rather than hidden — is a document rather than a page here, because it is written to be handed to somebody: ask us for the current copy at [email protected]. It is kept with the code it describes, so a self-hosted install already has it in its own repository.

It is deliberately candid about what a browser extension can and cannot guarantee. An organization that also runs Vanta can push its apps and approved deploys into its own Vanta tenant hourly, so the Bubble app stops being the one system in a compliance program Vanta cannot see.