Security
Where we stand today, stated plainly.
DeltaLedger is early-stage. This page describes what's actually true right now — not a compliance posture we haven't earned yet. No certifications are claimed here because none currently exist.
Current architecture
DeltaLedger is a Next.js application backed by a single PostgreSQL database (via Drizzle ORM). Every page reads live data through Server Components; every write goes through a typed Server Action into a repository layer — there is no client-side data store and no browser-held state that bypasses that path. Every consequential Server Action independently re-verifies the caller's identity, role, and workspace membership against the database — nothing about authorization is inferred from what the browser sends.
Current deployment
The application runs on Vercel, connecting to Postgres over the network via a single connection string — no local files, no server-held secrets outside standard environment variables. The same codebase runs identically in local development, CI, and production.
Current data model
DeltaLedger is workspace-isolated: every organization's engineering changes, BOMs, purchase orders, mappings, exposure calculations, and evidence live in workspace-scoped records that other workspaces cannot read or write. The public interactive demo uses a fictional company (Nova Robotics) and fictional data only, and runs read-only — no real customer data is processed by the current deployment.
Access control
Sign-in is via Google or Microsoft, and workspace access is invitation-only — there is no open sign-up that grants access to any workspace's data. Within a workspace, access is role-based (engineer, buyer, supply chain manager, finance, part-data owner, admin, and a read-only auditor role), and every membership and role change is itself an attributed, audited action.
Auditability
Calculations, decisions, and evidence are append-only with explicit supersession rather than silent overwrites, so a workspace's history remains reconstructable. Administrative actions are recorded in a platform-level audit trail.
Current limitations
DeltaLedger has not undergone a third-party security audit or penetration test, and holds no compliance certifications — none are claimed here. Google and Microsoft sign-in are verified in production, but customer-specific Microsoft tenant-consent requirements may still need coordination during pilot onboarding. There is no formal, per-customer data-handling agreement yet; that would be established before any pilot involving real customer data.
Security roadmap
Before any pilot involving real customer data: a documented data-handling agreement specific to that engagement and — as the customer relationship warrants — third-party review. Encryption at rest and in transit is already standard on the current hosting and database providers; formally documenting controls, retention, incident response, and customer-specific identity requirements is part of that same step.
Questions about how DeltaLedger would handle your data specifically? Reach out directly.