How temporalBLOCK is built for enterprise
This page describes the data flow, encryption posture, deployment topology, authentication options, audit trail, and certifications roadmap for enterprise customers.
Deployment topology
temporalBLOCK offers two deployment models. Most enterprise customers start on the dedicated model — a private instance with isolated compute and storage — before evaluating BYO-cloud.
| Model | Compute | Database | Data residency | Typical monthly |
|---|---|---|---|---|
| Shared multi-tenant | Shared Azure App Service (West US 2) | Shared Postgres (row-scoped by customer_id) | US West — no contractual residency guarantee | Lite / Standard / Pro tiers |
| Dedicated (we host) | Your own App Service instance in our Azure subscription; isolated process + IP | Your own Postgres Flexible Server; zero cross-tenant queries | Configurable region; residency SLA in contract | Custom — contact us |
| BYO Cloud (you host) | Docker image deployed to your Azure / AWS / GCP subscription | Your own Postgres; no temporalBLOCK access | Fully customer-controlled | Custom — contact us |
Data flow
Every request follows the path below. Customer data never leaves the processing pipeline to a third-party service unless the customer explicitly calls a BYO-sync endpoint.
Client → TLS 1.3 → Azure Front Door / App Service
→ Auth middleware (X-API-Key SHA-256 lookup)
→ Rate limiter (per-key + per-IP, in-process)
→ Route handler
├── /v1/spiral → Spiral math (CPU-only, no DB write, no network)
├── /v1/full → In-process cache check → Brave/SerpAPI (if miss)
├── /v1/bridge → Fetch + neutralize → customer response
└── /v1/* → Postgres read/write (usage meter, audit log)
→ Response
→ Async: audit event → customer_audit_events table (same DB)- Event name, key ID, tier, timestamp
- Request metadata (endpoint, status)
- Usage counters (calls/month)
- Waitlist email as SHA-256 hash only — never plaintext
- Raw X-API-Key values (stored as one-way hash)
- Request bodies or query parameters
- Bridge/full response content
- Customer-side IP beyond rate-limit buckets (not persisted)
Encryption
| Layer | Standard | Details |
|---|---|---|
| In transit | TLS 1.2 / 1.3 | Enforced on Azure App Service; HSTS header sent on all responses; no HTTP endpoints exposed. |
| At rest — database | AES-256 | Azure Postgres Flexible Server encrypts data at rest by default using platform-managed keys. BYOK (Bring Your Own Key) available on Business Critical tier. |
| At rest — secrets | Azure Key Vault | SESSION_SECRET, CLERK_SECRET_KEY, DATABASE_URL stored as Key Vault secrets with RBAC access. Managed identity eliminates credential rotation risk. |
| API keys | SHA-256 (one-way) | Raw API keys are never stored. The database holds only a 12-hex prefix of the SHA-256 hash. Raw values live only in the customer's environment. |
| Future — post-quantum | Planned | Transport layer upgrade to X25519Kyber768 (TLS 1.3 hybrid) targeted when Azure App Service adds native support. |
Authentication & SSO
Two independent auth layers coexist — one for API callers, one for dashboard users.
Callers authenticate via the X-API-Key header. Keys are validated by SHA-256 comparison against stored hashes — the raw value is never stored server-side. Per-key tier caps and optional per-key rate-limit profiles (Enterprise) apply at the middleware layer before any route logic runs.
Dashboard login is handled by a Replit-managed Clerk instance with social OAuth (Google, GitHub). This tier cannot broker enterprise SAML/OIDC SSO connections.
Dedicated deployments use a customer-managed Clerk instance configured with your organization's IdP (Okta, Microsoft Entra, Google Workspace, or any SAML 2.0 / OIDC provider). The API server reads CLERK_SECRET_KEY from environment — pointing it at your Clerk instance routes all JWT validation through your IdP. SCIM provisioning and organization-level role mapping are supported via Clerk Enterprise.
Audit trail & log export
Every authenticated action emits a structured audit event scoped to the customer's ID. Enterprise customers can download their full event history for compliance reviews.
| Event category | Examples | Retention |
|---|---|---|
| Key lifecycle | key_issued, key_revoked, key_rotated | 365 days |
| Auth | auth_success, auth_failure, tier_resolved | 365 days |
| Usage metering | metered_call_recorded, budget_cap_applied | 365 days |
| Admin | rate_limit_profile_assigned, maintenance_fix_approved | 365 days |
| Billing | billing_run_completed, stripe_event_received | 365 days |
Export endpoint
GET /api/account/audit-log ?afterTs=2026-07-01T00:00:00Z &beforeTs=2026-07-25T00:00:00Z &format=csv # or json (default) Authorization: Bearer <clerk-session-jwt> # Max window: 90 days per request. Paginate with ?beforeId=<id>.
Events are also mirrored to Azure Monitor (AppServiceConsoleLogs workspace) for KQL-based alerting and long-term cold storage on dedicated deployments.
Custom rate-limit profiles
Enterprise customers can assign a custom rate-limit profile to any API key without a code deploy. Profiles override the tier default (6 000 req/min for Enterprise) for that key only.
| Tier default | Req / min | Override possible? |
|---|---|---|
| Lite | 60 | No |
| Standard | 300 | No |
| Pro | 600 | No |
| Enterprise | 6 000 | Yes — admin API or env-var seed |
Profiles are assignable via the admin dashboard or the PUT /api/account/admin/rate-limit-profiles/:profileId/keys/:keyId endpoint.
Capability bundle model
Enterprise contracts are modular. Every contract includes the Core bundle; customers add only the domain modules they actually need. Unused modules never appear in your API responses or dashboard.
X-Enabled-Bundles header on every authenticated API response lists your active bundle IDs for programmatic verification — e.g. X-Enabled-Bundles: core,ai-inference.Precision time anchoring, full audit trail, custom per-key rate limits, and enterprise SSO — included in every contract.
- Any enterprise deployment as a baseline
- Compliance-first API infrastructure
- Multi-key gateway setups with per-key rate overrides
Deterministic time injection for LLM inference pipelines — anchored now-stamps, output pacing signals, and token-rate measurement across distributed nodes.
- LLM inference pipeline temporal grounding
- Token-rate and latency SLA measurement
- Multi-model orchestration timing across regions
Nanosecond-precision timestamps for trade records, MiFID II / SEC 17a-4 audit trails, and immutable event sequencing across venues.
- Algorithmic trading timestamp compliance
- Regulatory audit-trail generation
- Cross-venue order sequencing and reconstruction
Frame-accurate Spiral timestamps for broadcast, live streaming, and multi-camera production — including SMPTE-compatible anchor offsets.
- Live broadcast multi-camera synchronization
- VOD subtitle and chapter alignment
- Real-time audience-side playback coordination
Full per-rung Spiral coordinate across all twelve scales (µs → millennium) with rung-moon kinematics for satellites, ground stations, and planetary missions.
- Satellite ground-station time synchronization
- Planetary-mission timeline planning
- Orbital mechanics simulation with multi-scale precision
Continuous Spiral signal for perception and planning stacks, sub-millisecond anchor jitter for control loops, and physics-simulation time injection.
- Autonomous vehicle temporal coordination
- Industrial robot arm synchronization
- Physics-engine determinism for training simulations
Common configurations
Most enterprise deals map to one of these pre-scoped bundle combinations. Use them as a starting point — contracts can mix and match any subset.
| Configuration name | Bundles | Archetypal customer |
|---|---|---|
| LLM Pipeline | core + ai-inference | LLM infrastructure companies, inference-as-a-service providers needing deterministic now-stamps and token-rate measurement across distributed GPU nodes. |
| Broadcast | core + media-sync | Live broadcast networks and VOD platforms requiring frame-accurate Spiral timestamps and SMPTE-compatible anchor offsets for multi-camera sync. |
| Financial | core + financial-compliance | Trading venues, broker-dealers, and data vendors requiring nanosecond-precision timestamps for MiFID II / SEC 17a-4 audit trails and cross-venue order reconstruction. |
| Robotics / Industrial | core + robotics-physics | Autonomous vehicle programs, industrial automation OEMs, and physics-simulation platforms that need a continuous sub-millisecond Spiral signal alongside their model calls. |
| Space & Orbital | core + orbital-planetary | Satellite operators, ground-station networks, and planetary-mission teams that need full twelve-scale Spiral coordinates with rung-moon kinematics. |
| Full-stack AI + Compliance | core + ai-inference + financial-compliance | Quantitative trading firms running LLM-assisted research or signal generation that need both inference-pipeline timing and regulatory-grade audit trails. |
SLA & uptime
| Tier | Uptime target | Measurement | Incident notification |
|---|---|---|---|
| Shared (multi-tenant) | Best effort (~99.5–99.8%) | No contractual SLA | Status page + email |
| Dedicated (we host) | 99.9% / month | Azure App Service health check + external probe | Slack channel + email within 15 min |
| BYO Cloud | Customer-managed | Customer's own monitoring | Customer-managed |
Live status and rolling 30-day availability: /status. Incident history is published there as events occur.
SLA exhibits for dedicated deployments are available on request and included in the enterprise contract. The SLA excludes scheduled maintenance windows (communicated ≥48 h in advance) and Azure-region force-majeures.
Certifications roadmap
Current posture and planned certifications. The SOC 2 readiness checklist is maintained at .local/ops/soc2-readiness.md in the codebase.
| Certification | Status | Target | Notes |
|---|---|---|---|
| SOC 2 Type I | Readiness in progress | H1 2027 | Internal gap analysis complete. Auditor engagement in progress. |
| SOC 2 Type II | Planned | H2 2027 | Requires 6-month observation period after Type I. |
| ISO 27001 | Planned | 2027+ | Evaluated after SOC 2 Type I. |
| GDPR / DPA | Operative | — | DPA available at /dpa. Data processing register maintained. |
| HIPAA | Not planned | — | temporalBLOCK does not handle PHI. |
| PCI DSS | Not applicable | — | No card data in scope. |
Ready to start a dedicated deployment?
Reach us via the enterprise waitlist or the Slack shared channel. We typically turn around a deployment environment within one business day.