PULSE LIVE
SYNC 0s ago
EVENTS TODAY 0
RECONCILED 99.98%
00:00:00 UTC
Trust and security

Trust is a system. Not a promise.

Anyone can write that their data is secure and their numbers are accurate. Below is the actual standard the Pulse Ledger is built and graded against, including the ten rules that fail the build rather than generate a review comment.

Continuous integration enforced

The ten hard gates

These are not guidelines. Each one is enforced automatically, and a violation stops the deployment. The left column is the engineering rule. The right column is what it means for your money.

ID
The rule
What it means for you
P-2
No update or delete on ledger tables, revoked at the database role level
Your revenue history cannot be edited. Not by your team, not by ours. Corrections are new entries that reference the original, so the change is visible rather than invisible.
P-5
Conservation invariant enforced in Postgres
Every movement of money balances to zero across accounts, checked by the database itself. A transaction that would leave the books unbalanced is refused at write time.
P-9
Integer minor units only, no floating point, lint enforced
Money is counted in whole cents. There is no rounding drift accumulating quietly across a million transactions until your ledger and your bank disagree by an amount nobody can explain.
P-15
Idempotency key required on every write path
A retried webhook, a double click, or a processor that sends the same event twice cannot create a second sale. Same request returns the original result. A conflicting one is rejected outright.
P-23
Projections are disposable and rebuildable from the event log, tested on every merge
Every dashboard and report can be deleted and rebuilt from the raw event history, and must match. If a number is wrong we can prove it from first principles instead of guessing.
P-26
Three distinct timestamps on every entry
When it happened, when we learned about it, and which accounting period it belongs to are separate fields. Collapsing these is the single most common cause of revenue that shifts between reports.
P-29
No orphan entries, provenance required
Every entry traces to a processor transaction ID, a manual entry with a named approver, or a system rule. An entry with no origin cannot be written at all.
P-34
Gross and net decomposed into explicit legs
Processor fees, platform fees, taxes, refunds, chargebacks, and affiliate splits each get their own account and their own line. Net is never derived by subtracting an assumed percentage.
P-37
No downstream automation on unreconciled state
This is the one that matters most. No commission, no payout, no notification, no email or SMS send, and no approval fires on an entry that has not reconciled. It is what turns verified revenue from a marketing claim into a mechanism.
P-46
No destructive ledger migrations, ever
We cannot ship a change that destroys your history. Migrations are additive and reversible, and backfills are separate, resumable, and rate limited so a failure leaves the system valid.
Section five of the standard

Reconciliation is the product. The rest is table stakes.

P-30

Reconcile to the processor ledger, not the webhook stream

Webhooks drop, duplicate, and arrive out of order. They are hints. The balance transaction API is truth, so we poll it, store it raw, and reconcile against it.

P-31

Reconcile to the processor today, the bank next

Pulse reconciles against the processor record. The bank settlement leg — the third way — is designed and not yet fed by a live bank feed, so we say two way until it runs, because a reconciliation page that overstates its own coverage defeats its purpose.

P-32

Reconcile continuously, close daily

Not monthly. A break found 28 days late has already contaminated commission, EPSC, and every dashboard downstream of it.

P-33

Breaks are first class objects

Every break has an ID, an owner, an age, a dollar amount, and a status. Aged breaks escalate on their own. An untracked break is an unfixed break.

P-35

Payouts are modeled, not assumed

Money in transit lives in a real clearing account with a real balance. Cash collected is not cash received, and the gap between them is a number we can show you.

P-36

Suspense for anything unclassified

We never force an unknown into revenue to make a report balance. It goes to suspense, suspense is monitored, and an aged non zero balance raises an alert.

Section six

How correctness is proven rather than asserted

Application code validating itself is a user experience improvement. It is not a guarantee. Anything that must be true is enforced by the database and verified by jobs that run whether anyone is looking or not.

P-38

Invariants live in the database

Check constraints, unique constraints, foreign keys, and triggers. If it must be true, Postgres enforces it, not a code path someone can forget to call.

P-39

Continuous invariant checking

Trial balance equals zero. Cached balances match computed balances. No orphan entries. No sequence gaps. Runs on a schedule and alerts on drift, so we find the break before you do.

P-40

Tamper evidence by hash chaining

Each entry carries a hash of the previous entry plus its own canonical payload. Silent mutation becomes detectable, which is what makes immutable a verifiable claim rather than a policy.

P-41

Property based testing on the core

Thousands of randomly generated valid transaction sequences, with every invariant asserted after each one. Example based tests only find the bugs someone already imagined.

P-43

Every surfaced number has a lineage query

Any figure on any dashboard, report, or invoice expands to the exact entries that compose it. One click, no exceptions.

P-44

Sanity bounds on every metric

Upper bound, lower bound, and expected rate of change are declared per metric. Anything outside its bounds alerts before it ever reaches a screen.

Data protection

Your credentials and your customers

Envelope encryption

Credentials are envelope encrypted: a per tenant data key, wrapped by a master key, with the tenant bound into the encryption context so one partner's key cannot decrypt another partner's record. The managed key service backend is built and not yet the default, so today the wrapping key is held in the environment rather than by a KMS.

Least privilege at the database role

The application role holds insert and select on ledger tables and nothing else. Corrections route through a dedicated procedure with approval. The dangerous operation is impossible rather than merely forbidden.

Audit trail for ledger entries

Every ledger entry carries who wrote it, which system it came from, when it happened, when we learned about it, and the period it belongs to. Amendments and corrections additionally carry a stated reason and a named approver. Request ID and IP are captured on the approval workflow, not yet on every journal write.

Recovery is a drill, not a hope

Point in time restore is a documented quarterly drill with an append only log of every run — including, honestly, a log that starts empty. A backup that has never been restored is a hypothesis; each rehearsal on the record is what turns it into a fact.

Tenant isolation

Partner organizations are isolated at the data layer with per tenant encryption context. No aggregate we publish, including the live figures on this site, can be decomposed back to a single partner.

Period close and freeze

Once an accounting period closes, entries dated to it are rejected. Corrections post to the current open period with a reference back. Historical reporting stays stable enough to put in front of a client.

Sub processors

Who touches your data

We use a small number of infrastructure providers to deliver the service. This list is maintained and we give notice before adding a new one that processes customer data.

Amazon Web Services · encryption and key managementRailway · application hostingTiDB Cloud · primary application databaseSupabase · ledger databaseClerk · authenticationTwilio · voice and SMSSendblue · iMessageAnthropic · AI call review and assistant
Reporting a problem

Responsible disclosure

If you believe you have found a security vulnerability, email security@scalewithdata.ai with enough detail to reproduce it. We will acknowledge within two business days and keep you updated until it is resolved.

Please do not run automated scanning against production, access data that is not yours, or degrade service for other customers while testing. We will not pursue action against researchers who follow those rules and report in good faith.

On certifications

We are not going to claim a certification we do not hold. If a formal audit report is a requirement for your organization, raise it on the call and we will tell you plainly where we are in that process and what we can provide in the meantime.

Bring your engineer to the demo.

We will open the ledger schema, show you a live reconciliation run, and trace one dollar from ad click to verified commission. Technical questions welcome.