The Question

We get asked this a lot. IdealVibe is a platform. VibeSQL is a database product family. CryptAply is key governance. What ties them together? What makes it "enterprise"?

Here's the honest answer: Enterprise Vibe means your software can prove what it did.

Not "we follow best practices." Not "we're SOC 2 compliant." Not a badge on a landing page. Actual, cryptographically verifiable proof that your data was handled correctly — who touched it, when, what happened to it, and what keys protected it.

Every product we build generates evidence. Not because a compliance framework told us to. Because if you can't prove it, it didn't happen.

The Problem with Compliance-First Thinking

Most enterprise software starts with a framework — PCI DSS, SOC 2, HIPAA, ISO 27001 — and works backward to check boxes. The result is software that passes audits but doesn't actually prove anything useful.

You get:

Encryption at rest because the checkbox says so, but no record of which key encrypted which data
Audit logs that exist but aren't tamper-evident — anyone with database access can edit them
Backup encryption with a single passphrase stored in a config file next to the backup
Replication over TLS, but every Kafka broker in the middle can read your plaintext cardholder data
Retention policies documented in a Word file, not enforced in code

The audit passes. The security posture is weak.

Security-First, Framework-Agnostic

Enterprise Vibe is the opposite approach. Start with what provably good security looks like, build it into the product, and let the compliance evidence fall out naturally.

Here's what that means in practice, across the products we're building:

Governed Storage: vsql-vault

vsql-vault is an opaque storage vault. It doesn't encrypt or decrypt — it stores pre-encrypted blobs and governs access to them.

What it proves:

Every access is logged with caller identity, operation, timestamp, and purpose
Access policies are enforced at the storage layer, not the application layer — if a caller isn't authorized, the vault rejects the request and logs the denial
Retention policies are mandatory — you literally cannot store data without first defining how long it lives and when it gets destroyed
When data is purged, vsql-vault generates purge proof — a signed record that the data was destroyed, when, and under which retention policy

This isn't PCI-specific. This is what governed storage looks like regardless of your framework. A SOC 2 auditor, a PCI QSA, or an ISO 27001 assessor all want the same thing: proof that data access is controlled, logged, and that data destruction is verifiable.

Key Governance: CryptAply

CryptAply is the key governance authority. It doesn't encrypt anything. It governs the keys that other services use for encryption.

The pattern: Services report their key status UP to CryptAply. CryptAply pushes directives DOWN — rotate this key, revoke that one, this algorithm is no longer compliant, your cryptoperiod expired.

What it proves:

Every encryption key in your ecosystem has a lifecycle: created, active, rotating, retired, revoked
Key rotation isn't a calendar reminder — it's an automated directive from the governance authority
If an algorithm becomes non-compliant (say, a new NIST advisory), CryptAply pushes a directive to every service using it
The key inventory is always current — not a spreadsheet updated quarterly

This pattern already exists in production at PayEz. The Encryption API and the Identity Provider both have CryptAply plugins. VibeSQL extends the same pattern to the open-source ecosystem.

Encrypted Backup: vsql-backup

vsql-backup encrypts database dumps inside the Cardholder Data Environment before they leave. The streaming pipeline — pg_dump → zstd → AES-256-GCM → upload — means plaintext never touches disk outside the running database.

What it proves:

Every backup has an envelope: a random Data Encryption Key (DEK) encrypted by a Key Encryption Key (KEK) held in your KMS
The backup manifest includes SHA-256 integrity hashes — you can verify a backup wasn't tampered with
Every restore is a governed event: who requested it, who approved it, when it happened, what was restored, and whether the integrity check passed
Crypto-shredding works: destroy the KEK version and every backup encrypted by it becomes mathematically unrecoverable. No physical destruction required. Provably gone.

For Point-in-Time Recovery, vsql-backup wraps pgBackRest (MIT license, battle-tested) and adds the governance layer on top — envelope encryption for WAL archives, dual-authorization restore gates, and compliance-grade restore audit reports.

Governed Replication: vsql-sync

This is the one that gets people's attention.

Every PostgreSQL replication tool encrypts the connection with TLS. vsql-sync encrypts the payload. Each change event is envelope-encrypted with a per-session DEK before it leaves the source node. Kafka brokers, message buses, network monitoring tools — they see ciphertext. They can't read it. They're structurally out of scope.

What it proves:

Every replication batch has a signed, Merkle-rooted, hash-chained audit record: source node, target node, LSN range, tables affected, which CryptAply key encrypted it
The audit chain is tamper-evident — modify any historical entry and the hash chain breaks for every subsequent entry
Selective column publication means you can exclude sensitive columns from a replica entirely. The replica physically cannot contain that data — it was never transmitted. A QSA (or any auditor) can verify this with the PCI scope reduction report that vsql-sync generates and signs.

Nobody else does this. BDR has CRDTs but no payload encryption. Debezium has CDC but no governance. pg_tde has TDE but decrypts on logical decode. No tool encrypts the actual replication stream payload.

What "Provable" Actually Means

When we say provable, we mean it literally:

Ed25519 signatures on audit trail entries, scope reports, backup manifests, and purge proofs. Not "we logged it." Cryptographically signed, tamper-evident, independently verifiable.

Merkle roots over replication batches and backup contents. Two nodes can independently verify they have the same data without comparing every row — the roots either match or they don't.

Hash chains on audit tables. Each entry contains the hash of the previous entry's signature. Like a blockchain's integrity model, without the blockchain. An append-only table with hash chaining provides the same tamper evidence.

Envelope encryption with KMS everywhere. Random DEK per operation, wrapped by a KEK that never leaves the KMS boundary. Key rotation means re-wrapping the DEK, not re-encrypting terabytes of data. Crypto-shredding means destroying the KEK — all data encrypted by it becomes unrecoverable.

CryptAply governance across the entire stack. One authority that knows every key, every algorithm, every cryptoperiod. One place to push a directive and have it enforced everywhere.

Framework Mapping Falls Out Naturally

When your products generate this kind of evidence, compliance mapping is a documentation exercise, not an engineering project:

Evidence	PCI DSS v4.0	SOC 2	ISO 27001	HIPAA
Signed audit trail with tamper detection	Req 10.2, 10.3	CC7.2, CC7.3	A.12.4	164.312(b)
Envelope encryption with KMS	Req 3.5, 3.6	CC6.1	A.10.1	164.312(a)(2)(iv)
Governed key rotation via CryptAply	Req 3.7.1	CC6.1	A.10.1	164.312(a)(2)(iv)
Retention enforcement + purge proof	Req 3.1, 9.4.6	CC6.5	A.8.10	164.530(j)
Selective replication (scope reduction)	Req 7.2	CC6.3	A.9.4	164.312(a)(1)
Encrypted backup with restore governance	Req 12.10.2	CC7.5	A.17.1	164.308(a)(7)
Crypto-shredding	Req 3.1	CC6.5	A.8.10	164.310(d)(2)(i)

Same engineering. Same evidence. Different column in the spreadsheet.

What We Ship

Everything is open source. Rust. PostgreSQL License. FROM scratch Docker images — minimal attack surface, no shell, no package manager, no OpenSSL.

Product	What It Does
vsql-vault	Governed opaque storage — access policies, retention enforcement, purge proof
vsql-cryptaply	Encryption with CryptAply key governance — pluggable providers, directive enforcement
vsql-backup	Encrypted backup pipeline — streaming encryption, envelope keys, PITR via pgBackRest
vsql-sync	Governed replication — payload encryption, PCI scope reduction, signed audit trail
CryptAply	The key governance authority — services report UP, CryptAply directs DOWN

Each product has been through a QSA-level specification review. The findings are public. The architecture is documented. The code is auditable.

Current Utility — We Run On This

This isn't theoretical. The Enterprise Vibe stack runs our own products today. Every product we sell to customers, we use ourselves first.

CryptAply Governs Every Key in Production

The PayEz Encryption API — which handles credit card encryption, JWT signing, token hashing, and PII tokenization — calls CryptAply on every key operation. When the Encryption API needs to sign a JWT, it asks CryptAply: "which key version is compliant right now?" CryptAply returns the active version and any grace-period versions. The Encryption API never decides on its own which key to use.

CryptAply publishes key rotation events over RabbitMQ. The Encryption API subscribes. When a key rotates, every service in the stack knows within seconds — not because someone updated a config file, but because the governance authority pushed a directive.

This same pattern governs five distinct key purposes in production today: bearer token signing, credit card encryption, check encryption, general-purpose encryption, and partner token signing. Five key lifecycles, one governance authority.

The Encryption API Is the Most-Called Internal Service

Every service that touches sensitive data calls the Encryption API:

Payment API encrypts and decrypts credit card numbers through it before processing charges via Paragon
Identity Provider signs and validates every JWT through it — bearer tokens, refresh tokens, partner tokens, recovery tokens
External IDP generates DPoP proofs, client assertions, and manages merchant credentials through it
Vibe Public API tokenizes and detokenizes PII stored in the Vibe database through it
Stripe merchant credentials for IdealResume billing are stored and retrieved through it

The Encryption API doesn't store keys itself. It asks CryptAply which keys are valid, uses them, and reports back. The key material lives in Azure Key Vault. CryptAply governs the lifecycle. The Encryption API does the crypto. Clean separation.

IdealVibe and IdealResume Run on the Vibe Stack

Both consumer-facing products — idealvibe.online and idealresume.online — authenticate through the PayEz IDP and store all their data through the Vibe Public API. User accounts, application state, subscription tiers, purchase history, AI-generated content — all of it flows through the same governed stack.

When a user buys credits on IdealResume, Stripe sends a webhook. The webhook handler calls the Vibe Public API to update the user's credit balance and subscription tier. That API call is authenticated through the IDP. If the user's data includes PII, it's tokenized through the Encryption API. If the Encryption API needs a key, it asks CryptAply.

One purchase event touches four internal products. None of them know about the others' implementation. They communicate through governed APIs with authenticated, auditable calls.

The Agent Mail System Runs on Vibe

Our internal development team uses AI agents — BAPert (business analysis), DotNetPert (backend), NextPert (frontend), QAPert (QA), and others. These agents communicate through Agent Mail, which is a feature built into the Vibe Public API.

Every agent message — specs, code reviews, PCI audit findings, deployment instructions — is stored in Vibe, authenticated through the IDP, and accessible through the same HMAC-signed API that customer data flows through. The SignalR hub for real-time agent notifications runs on the Vibe Public API.

We built a communication system for our development team on top of the same platform we sell to customers. If it's good enough for our PCI audit coordination, it's good enough for your data.

The Full Chain

Follow a single request through the stack:

User logs into idealvibe.online
  → PayEz External IDP validates credentials
    → IDP calls Encryption API to sign the JWT
      → Encryption API asks CryptAply: "which signing key is compliant?"
        → CryptAply returns active key version from Azure Key Vault
      → Encryption API signs the JWT
    → IDP returns signed token to user

User saves data in idealvibe.online
  → Vibe Public API receives the request
    → JWT validated against IDP's published JWKS
    → If data contains PII → Encryption API tokenizes it
      → Encryption API asks CryptAply for the current encryption key
    → Data stored in VibeSQL via VibeSQL Server
  → Response returned to user

Six internal products touched. Every call authenticated. Every key governed. Every operation auditable. In production. Today.

What This Means for You

When we say vsql-vault enforces retention policies, we're not guessing that it works — it's the same enforcement layer that governs our own customer data retention.

When we say CryptAply governs key rotation, we're not hoping the directives propagate correctly — they propagate to our own Encryption API every five minutes in production.

When we say the Vibe Public API handles authenticated, HMAC-signed requests at scale — our own development team's daily communication depends on it.

Enterprise Vibe isn't a feature we built for customers and hope works. It's the infrastructure we run our company on.

Enterprise Vibe

Enterprise doesn't mean expensive. It doesn't mean complex. It doesn't mean a sales call.

Enterprise means: when someone asks "prove it," you can.

Every access logged. Every key governed. Every backup encrypted. Every replication batch signed. Every purge proven. Every audit trail tamper-evident.

That's Enterprise Vibe.