02 — Enterprise Features

Features that make BitVault sellable to security/compliance-conscious organizations — and that are technically deep, not checkbox theater. Several reuse the flagship primitives (01).

E1 — BYOK / HYOK (customer-managed keys)

Let a customer bring their own KMS key (BYOK) or hold it in their own HSM so it never reaches us (HYOK) — BitVault encrypts with a key the customer controls and can revoke (a “kill switch” for their data).

Design: extends envelope encryption (ADR-0014) — the tenant’s KEK is their KMS key; we hold only wrapped DEKs. Revoke the KEK → all their data is cryptographically inaccessible immediately.
HYOK is the stricter variant: unwrap happens via the customer’s external KMS endpoint.


Why it matters	A hard requirement for regulated/enterprise buyers; “you can revoke our access to your data” is a powerful trust + sales lever.
Complexity	L — multi-KMS abstraction, per-tenant key topology, revocation semantics, and the availability coupling to an external KMS.
Dependencies	ADR-0014 (envelope), E2E §4, secrets (platform/09).
Resume impact	High. Key hierarchies, multi-KMS, and revocation design = real security engineering.

E2 — Tamper-evident audit log (transparency log)

An append-only, cryptographically verifiable audit log: customers (and auditors) can prove no entries were removed or altered — Certificate-Transparency for your file activity.

flowchart LR
    classDef e fill:#fde68a,stroke:#b45309,color:#111827;
    classDef d fill:#bbf7d0,stroke:#15803d,color:#111827;
    ev["every action → audit entry"]:::e --> log["append-only Merkle tree log"]:::e
    log --> root["signed tree head (periodic, published)"]:::d
    root --> incl["inclusion proof: 'entry E is in the log'"]:::d
    root --> cons["consistency proof: 'log only grew, nothing edited'"]:::d

Reuses the Merkle machinery of verifiable storage §6; the audit sink (events/08) feeds the log.


Why it matters	Audit logs are only trustworthy if they can’t be quietly edited. Tamper-evidence is a compliance and forensics differentiator most products lack.
Complexity	M–L — Merkle log + inclusion/consistency proofs + signed tree heads; the data structures are well-defined (RFC 6962).
Dependencies	Event/audit pipeline (08), Merkle/BLAKE3 (storage/04).
Resume impact	High. Verifiable log structures (à la Trillian/CT) are a recognizable, deep credential.

E3 — Data Loss Prevention (DLP)

Detect and act on sensitive content (PII, secrets, card numbers) on upload — classify, then enforce policy: block, quarantine, redact, or alert.

Design: classification runs as an event-driven Function (Functions §2, plugins §1); the verdict feeds the policy engine (07) which enforces the action. DLP = plugins + events + policy composed.


Why it matters	A top enterprise ask; showcases the platform’s composability (three flagships solving one real problem).
Complexity	M on top of Functions+policy (the primitives do the heavy lifting); classification accuracy is the long tail.
Dependencies	Functions (06), policy (07), events (08).
Resume impact	Medium-high. Demonstrates composing platform primitives into a governance capability.

E4 — Data residency & sovereignty

Guarantee (and prove) that a tenant’s data lives only in approved regions/jurisdictions.

Design: placement is already policy-driven and residency is a hard constraint (ADR-0020); this exposes it as a tenant policy (07) + a continuous conformance proof (a job that asserts no object violates residency) + verifiable evidence (§6 verifiable).


Why it matters	GDPR/sovereignty is a gating requirement for EU/regulated customers; provable residency beats claimed residency.
Complexity	M — placement exists; the work is policy surface + conformance auditing + evidence.
Dependencies	Placement (ADR-0020), policy (07).
Resume impact	Medium-high. Compliance-by-construction + continuous verification is mature platform thinking.

E5 — SSO + SCIM provisioning

Enterprise IdP login (OIDC/SAML) plus SCIM for automated user/group lifecycle — joiners/movers/leavers provisioned and de-provisioned automatically.


Why it matters	Table stakes for enterprise, but SCIM (auto-deprovisioning) is the part most clones skip — and a real integration challenge.
Complexity	M — OIDC/SAML is M; SCIM 2.0 (the provisioning protocol + reconciliation) is the depth.
Dependencies	Identity (ADR-0010).
Resume impact	Medium. Recognizable enterprise-integration competence (SCIM especially).

E6 — Legal hold & eDiscovery

Place litigation holds that freeze matching content (override retention/deletion), and search/export for discovery.

Design: WORM/object-lock (storage/07) + a hold policy (07) that GC and lifecycle must respect (storage/11); export packages with verifiable receipts (§6).


Why it matters	Required in regulated/legal contexts; ties retention, WORM, search, and verifiability together.
Complexity	M — mostly composition of existing retention/WORM/search primitives.
Dependencies	Versioning/WORM (storage/07), search (ADR-0009), policy (07).
Resume impact	Medium. Compliance-feature composition; less novel than E1/E2.

Priorities within enterprise

Build E1 (BYOK) and E2 (tamper-evident audit) first — highest depth + resume + differentiation. E4/E5 are high product value at moderate cost. E3/E6 fall out once the flagships exist.