Trust
How the record holds, and where it stops.
Auditably exists to make a disclosure defensible, so a page that overstated its own guarantees would be self-defeating. Everything below was checked against the live database on 13 August 2026. Where something is not in place, it says so.
The audit trail
Append-only is a database grant, not a setting.
The activity log is protected by what the database will accept, not by
application code that could be bypassed or a flag an administrator could switch off. These
are the actual privileges on
public.activity_log:
| Role | Read | Append | Modify | Delete row | Empty table | What it is |
|---|---|---|---|---|---|---|
| anon | yes | no | no | no | no | The key published in our browser code. Any visitor holds it. |
| authenticated | yes | no | no | no | no | A signed-in customer. Cannot write to the log at all. |
| service_role | yes | yes | no | no | no | Our own application key. It can add entries. It cannot alter or remove one. |
| postgres | yes | yes | yes | yes | yes | The database owner. Read the section below. |
You can confirm the middle rows yourself: the proof page sends real UPDATE, DELETE and INSERT statements and prints the database's refusal, including the SQLSTATE.
One change we made because of this page
Writing this, we checked the grants rather than trusting our own documentation, and found
service_role still held
TRUNCATE. It could not have altered or deleted any individual entry, but it could have
emptied the table, which is not what we say here. Nothing in the product used it. It was
revoked on 13 August 2026 and the revocation is recorded as a database migration so it cannot
quietly come back.
The boundary
What a database owner can do.
The postgres role owns the database and can do anything to
it, including modifying or deleting log entries. That is true of every Postgres database in
existence, ours included, and any vendor implying otherwise is describing their application
layer, not their database.
So the honest statement of the guarantee is this. The append-only log removes an entire class of quiet change: a user editing a figure after approval, an application bug overwriting history, a compromised browser key planting an entry. It does not remove the operator from your threat model, and no software sold to you as a service can.
If your assurance provider needs a record outside operator control, the answer is an external attestation or a customer-held export taken on a schedule, not a stronger promise from us.
Evidence handling
Hashed on the way in.
Every uploaded file has a SHA-256 digest computed at upload and stored alongside it, with the filename, the user who filed it, a timestamp and the figure it supports. The digest is recomputed when the file leaves in an assurance export, so a reviewer can confirm the document they are reading is the document that was filed.
Verified in the schema: every evidence record currently stored carries a 64-character hash, which is SHA-256 in hexadecimal.
Tenant isolation
Row-level security on every table.
All fifteen tables in the application schema have row-level security enabled, so a query carrying one organisation's credentials cannot return another organisation's rows. Isolation is enforced by the database on every query, not by a filter the application has to remember to apply.
Four of those tables hold no customer records at all: they back the anonymous readiness diagnostic and the rate limiter for the public proof page. They have row-level security enabled with no permissive policy, which denies access by default.
Subprocessors
Who else holds anything.
Our database and evidence storage are currently hosted in the ap-northeast-1 region (Tokyo). That is where the data sits today. It is not a contractual commitment to keep it there, and we do not offer a choice of region. If your procurement requires a named jurisdiction, ask before you buy instead of after.
Stated plainly
What we do not have.
SOC 2: in progress, not certified
We are working toward SOC 2 and we are not certified. There is no report to send you, and any date we gave would be a guess. If your procurement requires a completed SOC 2 today, we do not meet that bar and you should know now.
Role separation: built, not yet in use
The data model carries organisation membership, and preparer, reviewer and approver are recorded against each disclosure version. Distinct permission levels per role, including a read-only auditor login, are not yet enforced in the product. We are at design-partner stage and no customer organisation is running them, so claiming a working role model here would be describing an intention.
No uptime commitment
We do not publish an availability target or an incident response time, because we do not operate a formal on-call rota and a number we could not honour would be worth less than this sentence.
Reporting a problem
Security contact.
If you find a vulnerability, email supportauditably.co@gmail.com with enough detail to reproduce it. We will confirm receipt, and we will not pursue anyone who reports a genuine issue in good faith and does not access or alter another customer's data while finding it.
We do not run a paid bounty. We will credit you if you want the credit.
Check it yourself
Do not take our word.
The proof page runs real statements against the live database and prints what comes back. It is open, needs no account, and the rejection is not simulated.
Test the log →Data flow
Where your data actually goes.
You sign in against our authentication provider and your browser holds a session token. Every write goes to a Cloudflare Worker, which is the only component with database write access; your browser never writes to the database directly. The Worker validates the token, checks your role, writes the row, and appends an entry to the activity log.
Evidence files go to object storage alongside the database, hashed with SHA-256 on the way in. Reads come back through row-level security scoped to your organisation. Nothing about your figures or evidence passes through a third-party analytics or marketing system.
Two features on Pro send text to a model provider, and they do not work the same way. AI drafting runs on your own API key, from your browser, directly to the provider. The key is held in your browser for that session only, never written to storage and never sent to us, and neither is the text you send. We are not a party to that call.
Instructed changes also run on your own key, but the request does pass through our server, because a proposed change has to be checked against your data and your role before it can be offered to you at all. The key is sent with that one request, used once, and never written to disk or to the database. Both features share the same session-held key, so you are asked for it once per session and never again after you close the tab. What reaches the provider is the sentence you typed plus a catalogue of the cycle: paragraph references, disclosure titles and statuses, field names, current values and units, and evidence file names. The evidence files themselves are never sent.
No customer data is used to train models, by us or on our behalf. We do not fine-tune on your figures, your narratives or your instructions, and we do not retain the text of a request after it has been answered. The call is made under your own provider account, on your key, so the provider's own retention and training terms are the ones you have already agreed with them.
Subprocessors
Everyone who touches anything.
Managed Postgres and object storage. The application
database, authentication, and every uploaded evidence file.
Cloudflare: static hosting, DNS, the Worker that performs all writes,
and page analytics. The analytics beacon records page views, not customer records.
Paddle: merchant of record for subscriptions. Payment details never
reach our systems.
Resend: transactional email: diagnostic results, invitations, and
replies.
Google Fonts and public script CDNs: serve fonts and two libraries to
your browser. They receive your IP address as a consequence of your browser requesting a file,
and nothing else.
That is the complete list. Retention periods for each category of data are set out in the privacy notice rather than repeated here, so the two cannot drift apart.
Encryption, backup, access
Three questions with short answers.
In transit: TLS on every connection, to the site, the app, the Worker and the database. There is no unencrypted path.
At rest: the database and object storage are encrypted at rest by our managed hosting provider, in the ap-northeast-1 region (Tokyo). That is their control operating on our behalf, not one we implement ourselves, and we describe it that way deliberately.
Backups: our hosting provider takes automated database backups on a daily cycle. We have not yet performed a documented restore test, so we cannot quote a proven recovery time.
Access: production database access is held by one person, the founder. The service key that bypasses row-level security lives in Worker secrets and is not present in any client, any repository, or any deployed page. There is no support team with a login to your data, because there is no support team.
Incidents and disclosure
What happens when something goes wrong.
If we become aware of a breach affecting your data we will notify you and the relevant authorities in line with applicable law. That commitment is in the privacy notice.
What we do not yet have is a documented, tested incident response plan with named roles and rehearsed timings. At design-partner stage the response is one person acting immediately, which is fast but is not a process you can audit. If your procurement requires a documented plan, we do not meet that bar today.
Found a vulnerability? Report it to supportauditably.co@gmail.com with "security" in the subject. We will acknowledge within two working days. We will credit you if you want the credit.
Data processing agreement: we do not publish a standard DPA yet. One is available on request and we will sign a reasonable one you provide.