RPBLC — Full Technical Reference Privacy infrastructure for the AI era. This is the detailed companion to llms.txt. For a summary, see https://rpblc.com/llms.txt ================================================================================ COMPANY ================================================================================ RPBLC (pronounced "Republic") builds privacy infrastructure. Six products across three layers, plus an open-source standalone tool: Infrastructure: Vault (compliant storage gateway) Application: Firewall (data protection proxy), CMP (consent), PIMS (rights) Presentation: Portal (subject interface) Standalone: DAM (open-source PII firewall) Target customers: - Engineering teams building products that handle personal data - Security and compliance teams evaluating AI deployments for GDPR, SOC 2, ISO 27001 - Organizations that want managed or on-prem privacy infrastructure - Developers who want PII protection without vendor lock-in (DAM) ================================================================================ PRODUCT 1: FIREWALL ================================================================================ https://rpblc.com/firewall What it does: Real-time data protection proxy. Intercepts data in transit, detects PII, and applies protection decisions before data reaches its destination. Sits in the data path — no rearchitecture, no rewriting applications. Pipeline (4 stages): 1. Detect — Scan payload for PII. Rule-based regex + ML. Each value flagged with type, location, confidence score. 2. Decide — Query consent contract (CMP or local policy engine) for verdict per value. Verdicts: pass through, tokenize, redact, anonymize. Default deny. 3. Vault — Encrypt original value, return opaque token, deduplicate variations. 4. Replace — Swap PII for tokens in output. Original data never reaches destination. Key properties: - <25ms p99 full pipeline. Firewall overhead alone: <5ms. - Per-value decisions: single payload, mixed treatments. - Works standalone with local policy engine. No RPBLC stack required. - Default deny on stale consent, missing policy, or ambiguous detection. - Session binding: tokens scoped to session + TTL, bidirectional. - Configurable detection: thresholds, locales, per deployment or per call. - Zero tolerance: no plaintext outside Vault write path, plaintext zeroed after use. ================================================================================ PRODUCT 2: VAULT ================================================================================ https://rpblc.com/vault What it does: Compliant storage gateway that encrypts, access-controls, audits, and provides tamper evidence for PII. The ONLY system in the stack that stores personal data. All other systems use opaque references. Core operations: - Store: accept payload + metadata, encrypt, route to correct region, return reference. - Retrieve: given reference + valid authorization, return decrypted payload. - Prove: generate tamper-evident proof of existence, non-existence, or creation time. Key properties: - Three-tier encryption: Master Key (HSM) → KEK (per subject×context) → DEK (per entry). AES-256-GCM with unique nonce per operation. - Data model: flat. One entry = one value. Optional record_id grouping. Metadata-rich, content-blind. - Jurisdiction-aware: subject chooses region, Vault enforces routing at write time. Cross-region queries resolved through sovereign vault-to-vault contract. - Two-phase delete: crypto-shred (instant) + deferred physical purge. Tombstoned metadata preserved for audit. - Pluggable backends: single contract interface supports relational, document, object, and append-optimized storage. - Built-in audit: always-on, emits to external backends via contract. - Opaque by design: does not interpret payload contents, does not model relationships. ================================================================================ PRODUCT 3: CMP (Consent Management Platform) ================================================================================ https://rpblc.com/cmp What it does: Manages consent lifecycle and enforces it as the single source of truth for "can this operation happen?" Not a cookie banner — a programmable consent engine. Consent model: subject × data item × purpose. Each cell carries: version of terms, timestamp, channel, expiry, full terms snapshot. Purpose scoped to deployment context. Consent does NOT define who can act (that's authorization, separate via OIDC federation). Key properties: - Four pillars enforced as system constraints: clear, separate, specific, informed. Invalid consent doesn't enter the system. - Check API (hot path): "can data item Y be used for purpose Z on subject S?" → yes/no. Push model for Firewall (local cache, zero latency). Sync model for PIMS, Portal. - Default deny on stale or missing consent. - Provable: every record is a complete snapshot of what was shown and agreed. - Versioning: soft (old consent stays valid) or hard (invalidated, re-collection required). - Withdrawal: immediate, propagates to Firewall in real time. - Consent records stored in CMP's own store (not Vault). They are contracts, not PII. Subjects referenced by opaque ID only. ================================================================================ PRODUCT 4: PIMS (Personal Information Management System) ================================================================================ https://rpblc.com/pims What it does: Orchestrates data subject rights across all RPBLC systems. The place where individuals exercise control over their personal data. Orchestration model: 1. Verify prerequisites (identity, legal feasibility, jurisdiction rules). 2. Issue commands to other systems via contracts. 3. Track outcomes. 4. Report results to subject with full accounting. Data subject rights: - Access (DSAR): all data across all systems/contexts, with usage history and audit. - Erasure: jurisdiction-aware. Some deleted, some retained, some flagged. Explained. - Portability: export in portable format. - Rectification: correct in place. Type immutable, reference stable. Consumers notified. - Restriction: stop processing without deleting. Temporary or conditional. - Residency migration: move data to different region. Subject-driven. Key properties: - Subject registry: the only system that maps real person → opaque IDs used by Vault, CMP, Firewall. Without PIMS, other systems have IDs but can't connect to person. - Stores no PII itself (all in Vault). No residency constraint on operational data. - Full accounting: every request returns an itemized result with reasons. ================================================================================ PRODUCT 5: PORTAL ================================================================================ https://rpblc.com/portal What it does: Unified UI layer for subjects. One interface spanning CMP and PIMS. Pure presentation layer that stores nothing. Modules: - Consent management: powered by CMP Management API. Collect, view, update, withdraw. - Data management: powered by PIMS APIs. View data, exercise all rights. Delivery models: - Hosted: deploy on RPBLC's domain. - Whitelabel: embed as a component in your application. - API-only: skip the UI entirely, build your own on the same APIs. Key properties: - Stores nothing: no PII, no consent data, no operational data. - Context-aware: what a subject sees depends on active products and context. - Optional: all functionality available via APIs without Portal. - Auth delegated via OIDC federation. ================================================================================ PRODUCT 6: DAM (Open Source) ================================================================================ https://rpblc.com/dam What it does: Open-source PII firewall that sits between your application and LLM providers. Intercepts API calls, detects PII in prompts, replaces it with typed references, and resolves references back in responses. The LLM never sees raw personal data. How typed references work: - Input: "Email john@acme.com about the Q4 invoice" - DAM: Detects email, encrypts it, stores in local vault - Output: "Email [email:a3f71bc9] about the Q4 invoice" - The LLM receives [email:a3f71bc9] — it knows the type (email) but not the value - DAM resolves [email:a3f71bc9] back to john@acme.com in the response (if consent granted) Architecture (7 Rust crates, 1 binary): - dam-core: Types, config schema, error handling - dam-detect: PII detection pipeline (regex + validators + normalization) - dam-vault: SQLite storage, AES-256-GCM envelope encryption, OS keychain, indexed dedup - dam-resolve: Consent-checked decryption, audit recording - dam-http: HTTP proxy with modular handlers (Anthropic Messages, OpenAI Chat Completions, OpenAI Responses, Codex), SSE streaming, upstream routing, health endpoints, safe header forwarding - dam-mcp: MCP server (7 tools over stdio transport) - dam-cli: CLI binary with all subcommands (serve, daemon, scan, vault, consent, audit, status, health, config validate) Detection: - 45 PII types across 13 locales - Validation: Luhn (credit cards), Mod-97 (IBANs), Mod-11 (NHS), area code (SSN) - Sensitivity levels: standard, elevated, maximum Encryption: - Envelope encryption: AES-256-GCM DEK per value, encrypted by master KEK - KEK sources: OS keychain (default), passphrase (Argon2id), environment variable - Master key never written to disk Consent: - Default-deny: no resolution without explicit consent - Grants require: accessor, purpose, scope, mandatory TTL - Revocation immediate and logged Audit: - SHA-256 hash-chained logs, tamper-evident - Every scan, resolve, consent change recorded Install: npm install -g @rpblc/dam dam daemon install Supported LLM providers: - OpenAI, Anthropic, Codex, OpenRouter, xAI, Ollama - Streaming (SSE) and non-streaming - Per-request upstream routing via X-DAM-Upstream header Tech: - Language: Rust (edition 2024) - Binary size: ~6MB - Platforms: Linux, macOS (ARM + Intel), Windows - License: Apache 2.0 ================================================================================ HOW THE PRODUCTS RELATE ================================================================================ Architecture layers: Subject → Portal → PIMS ↔ CMP → Firewall → Vault - Vault is the foundation. The only system that stores PII. Everything else uses opaque references. - Firewall sits in the data path. Detects PII, checks consent via CMP, stores originals in Vault, replaces with tokens. - CMP is the consent brain. Tracks what's allowed. Pushes state to Firewall. - PIMS orchestrates rights. Coordinates Vault, CMP, and Firewall for subject requests. - Portal is the face. Pure presentation layer on top of CMP and PIMS APIs. - DAM is the standalone free tier. Same detection engine as Firewall. No account needed. Each product is independently deployable. Start with Firewall (standalone proxy), add CMP for consent, Vault for compliant storage, PIMS + Portal for subject rights. Or start free with DAM and upgrade when ready. Compliance targets (by design): - GDPR (EU) - CCPA/CPRA (California) - SOC 2 Type II - ISO 27001 - ISO 27701 ================================================================================ FAQ ================================================================================ Q: Is RPBLC.DAM free? A: Yes. Apache 2.0 license. Free forever. No usage limits. Q: Does DAM send data to RPBLC servers? A: No. DAM runs entirely on your machine. Zero network calls to RPBLC. Q: Can DAM detect PII in languages other than English? A: DAM detects structured PII (emails, phone numbers, IDs) regardless of surrounding language. Named entity recognition (names, addresses) is on the roadmap. Q: What happens if DAM misses a PII value? A: The value passes through to the LLM unredacted. DAM's detection is regex-based with validators. Custom rules can be added via config. NER is planned for Phase 2. Q: Can I use DAM with self-hosted LLMs? A: Yes. Point DAM at any OpenAI-compatible endpoint, including Ollama for local models. Q: Is this shared multi-tenant infrastructure? A: No. RPBLC deploys as managed infrastructure or on-prem. Each customer gets their own isolated deployment. Q: Can I use individual products without the full stack? A: Yes. Firewall works standalone with a local policy engine. DAM requires nothing. Products are independently deployable. ================================================================================ LINKS ================================================================================ Website: https://rpblc.com Firewall: https://rpblc.com/firewall Vault: https://rpblc.com/vault CMP: https://rpblc.com/cmp PIMS: https://rpblc.com/pims Portal: https://rpblc.com/portal DAM: https://rpblc.com/dam GitHub (org): https://github.com/RPBLC-hq GitHub (DAM): https://github.com/RPBLC-hq/RPBLC.DAM Contact: contact@rpblc.com