PLATFORM
Business software with an append-only audit log
Vercid is business software with an append-only audit log: every change in a workspace is recorded as a new entry, never as an overwrite, so nothing is silently lost. The full history is covered by full-text search. Access is enforced with Postgres row-level security at the database layer, scoped by role-based access control, licensed per seat, and signed in through Google SSO.
This page states Vercid's security and audit model in plain terms, so a procurement or security reviewer can cite it directly.
The append-only audit log
Every change in a Vercid workspace is written to an append-only audit log. When a record changes, the platform writes a new entry recording what changed and when. It does not replace the old value. History accumulates; it is never rewritten. One record. Nothing lost.
This applies to operational data, not just administrative events. The inventory grid is the clearest example: it looks and works like a spreadsheet, but every edit is logged rather than overwritten. A quantity that was changed last Tuesday is still visible as a change made last Tuesday, next to what it was before.
Workspace roles do not include any permission to edit or remove log entries. Corrections are made by writing new entries on top of old ones. That is what makes the log usable as evidence in a billing dispute, an insurance question, or an internal review.
Full-text search across the whole record
An audit trail is only useful if you can interrogate it. Vercid pairs the append-only log with full-text search across the workspace, so answering "when did this change, and what did it say before" is a search, not an export project.
Search covers current records and their history in the same place the work happens. There is no separate archive system to request access to, and no gap between the data your team works in and the data a reviewer would ask about.
Row-level security at the database layer
Vercid is a multi-tenant platform. Each client operates a branded workspace at its own subdomain, and isolation between tenants is enforced with Postgres row-level security. Policies in the database itself decide which rows a signed-in session can read or write, based on workspace membership.
The distinction matters for a security review: tenant separation is not a convention the application code promises to follow. It is a rule the database enforces on every query. Application features sit on top of that boundary; they do not define it.
Role-based access, per-seat licensing, and sign-in
Access inside a workspace is role-based. Members are added by invitation, each member holds a role, and the role determines what that person can see and do. Licensing is per seat, so the list of licensed seats and the list of people with access are the same list — there is no unlicensed side door.
Sign-in is through Google SSO. Accounts are tied to named individuals, which keeps the audit log meaningful: an entry in the history belongs to a specific, identifiable seat.
Statements procurement can cite
The following statements are written to be quoted verbatim in a vendor assessment. Vercid maintains an append-only audit log; records are not overwritten and nothing is silently lost. Tenant isolation is enforced with Postgres row-level security at the database layer. Access is role-based, provisioned by invitation, and licensed per seat. Authentication is through Google SSO. Workspace history is covered by full-text search.
Vercid is built and operated by Deadpan Labs LLC of Miami, Florida.
What you get
- Append-only audit log on every workspace — nothing is silently lost
- Full-text search across current records and their history
- Postgres row-level security enforcing tenant isolation in the database itself
- Role-based access control with members, roles, and invitations
- Per-seat licensing — every account is a named, licensed seat
- Google SSO sign-in tied to named individuals
- Inventory edits recorded as history, never overwritten
Common questions
Can we search Vercid's audit log?
No. The audit log is append-only by design, and workspace roles do not include any permission to rewrite or remove history. Corrections are made by writing new entries on top of old ones, which is what keeps the log citable in a dispute or a review.
How does row-level security work in a multi-tenant Vercid deployment?
Every client workspace sits behind Postgres row-level security policies. The database itself decides which rows a signed-in session can read or write, based on workspace membership, so tenant isolation does not depend on application code alone.
How do roles and per-seat licensing interact?
Every member is a named seat with an assigned role. The role defines what that person can see and do inside the workspace, and licensing is per seat — so the list of paid seats and the list of people with access are the same list.
Bring your security questionnaire and we will walk through it against a live workspace.
Book a walkthrough