Product-backed trust for rights, release, and finance workflows.
SplitGraf focuses on permission clarity, audit visibility, proof surfaces, and verification so teams can inspect what a release or settlement is actually based on.
We do not invent security badges or unsupported compliance claims. The trust page explains what the product actually does: structured access, auditable transitions, proof generation, and inspectable verification surfaces.
The trust model is built into the operating record.
Verification-first records.
Every record in SplitGraf is born verifiable. Proof manifests, audit ledgers, and public verification paths are the default state of every operation.
Operating chain continuity.
Catalog, agreement, release, revenue, and settlement records connect to each other through immutable references. The chain holds even when systems beyond SplitGraf are involved.
Neutral by design.
SplitGraf owns no catalog, publishing arm, distribution business, or rights inventory. The product is positioned as a neutral verification layer.
The history stays continuous and traceable.
The proof exists whether or not anyone ever asks for it. When someone does ask, an artist, a counterparty, an auditor, or an acquirer, the answer is already in the system.
Append-only history.
Every record is append-only. Versions are preserved. Nothing gets silently overwritten.
Preserved agreement versions.
When a split changes, the previous version stays, so teams can see what was agreed at each point in time.
Ambiguity routes to review.
When revenue matching is ambiguous, rows route to review rather than getting silently guessed at.
Statements trace back to source records.
When a statement is generated, the chain back to source CSV, asset match, split snapshot, and agreement is part of the record.
Key proof surfaces tied to the record.
The goal is not more paperwork. The goal is to make it easier to see what was approved, delivered, reviewed, and finalized.
Agreement proof
Inspect what was formalized, who participated, and what the derivative or release flow is based on.
Release package evidence
Review the metadata and files that were used to generate the release handoff package.
Settlement proof
Tie statement or batch outputs back to imported reporting and the party context already attached to the record.
Verification pages
Give downstream reviewers a cleaner way to inspect the surfaces the workflow generated.
Proof, permissions, and verification stay close to the operational work.
Permissioning that maps to the workflow
Access and next steps change as the record progresses, so participants only see the work and actions appropriate to their stage.
Audit visibility instead of guesswork
The important steps that shape release, settlement, and proof outcomes stay traceable inside the workspace.
Proof surfaces tied to real operations
Agreement proof, release package evidence, settlement proof, and verification pages exist to support actual downstream review.
Operational traceability
Catalog, releases, and finance teams can explain how a release or statement got here without stitching together a separate paper trail.
Security posture should be concrete, not performative.
SplitGraf describes the controls and processors that are part of the current product posture. Primary database residency is EU-first through Supabase Frankfurt; application hosting, settlement processing, and email currently include US regions while EU migration work remains committed for end-2026.
EU database
Primary application data is stored in Supabase Frankfurt for the EU-first data posture.
US application hosting
The application currently runs on Vercel us-east-1 while EU region migration work remains committed for end-2026.
US settlement processing
Revenue reconciliation and settlement processing currently run in Render us-west (Oregon). Signed bundle data and the persisted settlement record are stored in Supabase Frankfurt after processing completes.
US email delivery
Transactional email currently uses Resend us-east-1.
Roadmap without overclaiming
SOC 2 is on the roadmap for end-2026. SplitGraf does not claim certifications it does not yet hold.
Named infrastructure partners, not vague assurances.
This page reflects shipped infrastructure and current roadmap commitments only. It does not claim certifications or controls that are not yet held or shipped.
Supabase
Database, authentication, storage, and row-level security foundation. Primary database region: Frankfurt.
Vercel
Application hosting and deployment. Current application region: us-east-1.
Render
Reconciliation-engine hosting for settlement processing. Current processing region: us-west (Oregon). Signed and persisted settlement data remains in Supabase Frankfurt.
Resend
Transactional email delivery. Current email region: us-east-1.
Stripe
Payments, subscriptions, invoicing, and billing workflows.
How trust appears inside the workflows.
Collaboration Releases
Split versions are preserved, upload approval history remains attached, and the release handoff carries agreement, credits, and split state with it.
Settlements
Matching is deterministic, ambiguous rows route to review, and the split snapshot applied is the one active at the time revenue was earned.
Public verification
Proof manifests and verification pages let downstream reviewers inspect what the workflow generated without exposing unrelated internal context.
The verification path is a workflow output.
Every operation in SplitGraf produces a record. Every record can be hashed into a proof manifest. Every proof manifest can be publicly verifiable through a verification path.
Verify a real settlement bundle yourself
SplitGraf settlement bundles are cryptographically signed using an RSA-4096 key held in AWS KMS and signed with RSASSA-PSS using SHA-512. The public verification key is published at a stable URL. Any auditor, counterparty, or customer can independently verify a settlement bundle using standard tooling, without authentication and without trusting SplitGraf to perform the verification.
Public signing key
https://splitgraf.com/.well-known/keys/signing-2026.pemVerify a production settlement bundle
curl -O https://splitgraf.com/.well-known/keys/signing-2026.pem
curl -o bundle.zip \
"https://splitgraf.com/api/monetization/settlements/7c56f9f9-9417-49f3-a7fa-0c6c1887cf1f/bundle"
unzip bundle.zip -d bundle/
openssl dgst -sha512 \
-sigopt rsa_padding_mode:pss \
-sigopt rsa_pss_saltlen:-1 \
-verify signing-2026.pem \
-signature bundle/bundle.sig \
bundle/bundle_manifest.jsonVerified OKContents of the downloaded bundle
Verification reproduces using standard OpenSSL tooling and does not require SplitGraf-specific software. The same verification reproduces with Python's cryptography library, Node.js crypto module, or any RSA-PSS-capable cryptographic toolchain.
Signing details
- Algorithm
- RSASSA-PSS with SHA-512
- Key type
- RSA-4096
- Signing infrastructure
- AWS KMS, eu-central-1 (Frankfurt)
- Public verification key format
- PEM
- Key rotation
- annual, manual; versioned URL pattern (`signing-YYYY.pem`)
See how proof, permissions, and verification show up in the live workflow.
That is often more useful than a generic security pitch, especially for release and finance teams trying to understand downstream confidence.