Six interconnected capability layers — all API-first, all self-service, and all built to the engineering standards that regulated industries and large-scale operations actually require.
Ledger Engine
Financial-grade integrity. Not just a running total.
The VariaOS ledger is append-only and immutable. Every accrual, conversion, redemption, expiry, and adjustment creates a LedgerEntry row — no entry is ever updated or deleted, and balance is derived from a snapshot, not a mutable field. Why it matters: points are a financial liability, and a running total silently loses or double-counts under retries, refunds, and concurrency. An append-only ledger makes every balance provable from history — for your finance team that's an audit that passes instead of a reconstruction; for the platform it's the guarantee the naive build can't retrofit.
Append-only LedgerEntry model — no mutable balance fields
Atomic LedgerTransaction grouping — all-or-nothing across entries
PENDING / COMMITTED / FAILED state machine with full transition history
Snapshot-based balance queries — consistent under concurrent writes
Points calculated to whole units, always rounded down — the house never over-awards
Order cancellation and refund with proportional void
Typed store credit with expiry lots, consumed first-expiring-first-out (FEFO)
Credit issuance & adjustment APIs — permission-gated, with audited reasons
Credit redemption reversals with configurable reversal window
In the product — AcmeRetail demo tenant, synthetic data · click any screenshot to enlarge
The operations view — the live dashboard, fed straight from the append-only ledger: members, recent activity, tier distribution, and the ledger-integrity check.The finance view — ASC 606-framed liability by credit kind, aging by time-to-expiry, and the breakage pipeline. The CFO's answer to “what do we owe?”Credit lifecycle, per customer — every grant opens a typed lot with a policy-resolved expiry; drawdowns consume soonest-expiring first (FEFO), every action audited.Per-kind expiry policies — promotional and goodwill on rolling windows, and refund credit can never expire: the platform forbids it.
Rules Engine
Write rules in English. Run them in 50ms.
A purpose-built DSL powered by an ANTLR4 grammar with a sandboxed evaluator. Tenants write, version, and test rules without engineering support — and without risking the ledger.
Shipped live in the private beta today · Roadmap planned — not yet built · Keyword technical detail — shares its card's status; anything not built carries its own Roadmap chip
📝
Human-Readable DSL
Accrual logic in a purpose-built language that reads like the business rule it implements — authored, tested, and activated by loyalty programme managers themselves. For your team that means promotions ship in hours, not engineering sprints; for the platform it means rule changes are governed data, not code deployments, so a pricing change can never destabilise the engine.
ShippedANTLR4 GrammarVersion-Controlled
🧱
Sandboxed Evaluation
Every rule runs on a sandboxed IR evaluator with no access to the filesystem, network, or other tenants' data — isolation by construction, not by policy. You get the freedom to let non-engineers write live logic without opening a security hole; the platform gets a hard guarantee that the worst a bad rule can be is a wrong number, never an exploit. A Wasmtime hardware-isolated tier is on the roadmap for Scale/Enterprise.
ShippedSandboxed IR EvaluatorWasmtime (Roadmap)
⏱️
50ms Hard Evaluation Timeout
No rule can block order ingestion: a static complexity budget (10,000 units) is enforced when a rule is saved, so anything that could blow the 50ms evaluation window is rejected before it ever runs live. Your checkout-adjacent latency is protected from the rules layer by design — and no tenant can accidentally (or deliberately) stall the pipeline for anyone.
Shipped50ms WallComplexity Budget
🧪
Dry-Run Simulation
Test a rule against real order data with zero ledger writes: inspect the evaluation trace, see exactly which conditions matched, and preview the points outcome before going live. Rule changes stop being a leap of faith — programme managers catch a mispriced promotion before members do, and finance signs off on earn-rate changes with evidence instead of estimates.
ShippedNo Ledger WritesEvaluation Trace
🎲
A/B Traffic Splitting
Split live order traffic between two rule sets with deterministic HMAC assignment — the same customer always lands in the same variant, so the experiment is clean. Run a controlled test on your earn rate, measure the outcome through the reporting API, and promote the winner without a deploy. Programme economics stop being set-and-guess: the earn rate becomes an experiment you can defend to finance.
ShippedDeterministic HMACGrowth+ tier
📋
Rule Versioning & Audit History
Every rule-set change is versioned and attributed in the audit trail, and any previous version is a one-click rollback. When finance or an auditor asks why April's earn rate changed, the answer is a record, not a memory — and a bad change is a revert, not an incident.
ShippedFull HistoryRollback
In the product — AcmeRetail demo tenant, synthetic data · click any screenshot to enlarge
A live rule set — the DSL source, its version, the traffic split, and the complexity budget it consumed (18 of 10,000), with validate and simulate one click away.The Retail Starter bundle — a complete programme (tiered accrual, Bronze/Silver/Gold ladder, points→credit conversion) applied as an editable, inactive draft.A campaign multiplier — 10× Flash Sale over a date window with day-of-week targeting, layered on the active rule set without touching its DSL.
Reporting
GraphQL. Because your dashboards shouldn't run on polling.
In a market of predominantly REST-only reporting, VariaOS ships a full GraphQL API with real-time WebSocket subscriptions. For your team that means live dashboards and member-facing balances that update the moment a transaction commits — no polling loops, no stale caches, and you fetch exactly the fields you need. For the platform it means one governed read surface — paginated, cost-capped by design, scoped tokens for embedded use — instead of a sprawl of bespoke report endpoints.
Full GraphQL API at /graphql/v1 — Hot Chocolate server
DataLoader — eliminates N+1 query patterns across nested resolvers
Cursor-based pagination on all collection types
Real-time WebSocket subscriptions for live dashboards
rulePerformance query with up to 12-month lookback
A/B rule-set performance comparison via the reporting API
Separate sandbox GraphQL endpoint with introspection — coming soon
Reporting data retention: 12 months (Starter) → 84 months (Scale)
query.graphql
subscriptionLiveTransactions {
onLedgerCommitted {
# tenant comes from your authenticated credential
eventType
customerId
pointsDelta
newPointsBalance
creditDelta
newCreditBalance
tierId
tierRank
occurredAt
}
}
# — credential rides in the graphql-ws connection_init payload# — pushed the moment each transaction commits
Data Warehouse — Roadmap
Your loyalty data. In your warehouse. On the roadmap.
On the enterprise roadmap: native CDC feeds that push loyalty data directly into your warehouse of choice — with PII governance, DPA workflow, and application-level encryption built in. No third-party tooling. Today, historical loyalty data moves in and out through the auditable order-data import API with reconciliation reporting.
❄️ Snowflake
📊 Google BigQuery
🔷 Azure Synapse / Fabric
🔴 Amazon Redshift
≤5 Minute Latency
Planned: CDC-based feeds targeting end-to-end latency under 5 minutes on Growth and above — so your BI team analyses loyalty next to every other business domain, minutes after it happens, without building an ETL pipeline.
PII Exclusion Lists
Planned: configure which customer PII fields are excluded from warehouse feeds, with a DPA confirmation workflow at no additional charge — warehouse analytics without expanding your PII footprint, governance decided once and enforced on every feed.
Backfill API
Planned for the Scale and Enterprise tiers: export full historical loyalty data across any date range — useful for bootstrapping a new connector or recovering from a failed sync.
6 CDC Feed Subjects
Customers, transactions, orders, rule evaluations, tier history, and webhook deliveries — planned as individual CDC feed subjects on Scale and Enterprise.
Envelope-Encrypted Exports
Planned: application-level AES-256 DEK per export file, tenant KEK stored in Azure Key Vault — encryption at the application layer, independent of storage-level encryption.
Data Residency Selection
Planned: US, EU, and APAC region selection, with EU data residency (GDPR DPA + Standard Contractual Clauses) included from Growth at no additional charge. The private beta runs in US Azure regions today — stated plainly, here and in every partner agreement.
Security & Compliance
GDPR compliance as an engineering discipline.
Security at VariaOS is not a feature layer added on top — it is built into the data model, the event bus, and the key management architecture from the ground up.
🔑 Per-Customer DEK/KEK Envelope Encryption
Every customer's PII fields are encrypted with a unique AES-256 Data Encryption Key (DEK), itself encrypted under a per-tenant Key Encryption Key (KEK) stored in Azure Key Vault. Compromise of one DEK cannot affect any other customer record — blast radius is the security story: one key exposes one customer, never a table.
🔥 Cryptographic Erasure (GDPR Article 17)
To satisfy a right-to-erasure request, the customer's DEK is destroyed in Azure Key Vault. All encrypted PII fields become permanently irrecoverable — without touching the immutable ledger. The audit trail survives; the personal data does not. You never have to choose between satisfying the regulator and satisfying the auditor.
🚫 PII-Free Event Bus
Negative tests in CI prove that no personal data reaches the event bus — verification in the pipeline, not reviewer vigilance. An event schema registry with publish-time validation is on the roadmap. Everything downstream — webhooks, analytics, integrations — inherits a bus that simply has nothing to leak.
🪝 HMAC-Signed Webhook Delivery
All webhook deliveries are signed with a timestamp-bound HMAC-SHA256 signature. SSRF protection prevents webhook endpoints from targeting internal network addresses. Secrets rotate with a configurable grace period to prevent delivery interruption. Your systems can trust what they receive: forged or replayed deliveries fail cryptographically, not procedurally. An in-portal delivery dashboard tracks every webhook and connector delivery — PII-free, with dead-letter replay.
🔐 Argon2id API Key Hashing
API keys are stored as Argon2id hashes — the OWASP-recommended memory-hard algorithm that resists GPU and ASIC brute-force attacks. Raw keys are shown once at creation and never stored in plaintext — a database breach yields no usable credentials, even to us.
🛡️ Super Admin FIDO2 + 4-Eyes Approval (Roadmap)
Planned hardening: FIDO2 hardware-key authentication and dual-operator approval for Super Admin operations (tenant provisioning, role escalation, key management).
📋 Write-Once Audit Log
All tenant-scoped administrative actions are written to an immutable audit log with default-deny PII redaction and CSV/JSON export. Records cannot be deleted by tenant administrators, and retention is configurable per tenant (30-day floor, 365-day default) with automated purge. When a security review asks who did what and when, the export is the answer.
🔗 mTLS Service Mesh (Roadmap)
On the scale-out roadmap: mutual TLS between services via a service mesh. Today the platform runs as a consolidated deployment on Azure Container Apps, and all external traffic — API, portal, and webhooks — is TLS-only.
In the product — AcmeRetail demo tenant, synthetic data · click any screenshot to enlarge
The audit viewer — read-only and PII-redacted, filterable by actor, method, status, and entity, with bounded CSV/JSON export. Note the 403: denials are captured too.
Integrations
Built to connect to the platforms your team already runs on.
Integration is where loyalty projects live or die, so every source follows one canonical path — normalise via field mapping, evaluate, record — and ingestion is idempotent by order id, so retries and webhook redeliveries can never double-count. Statuses below are honest: private-beta connectors are built and tested, enabled per tenant during onboarding.
🛍️ Salesforce Commerce Cloud (cartridge · certification in progress)
🔐 Okta · Google Workspace · Ping (OIDC; SAML on request)
🔑 Auth0
📨 Azure Service Bus
🗂️ Apache Kafka (roadmap · Scale+)
📡 OpenTelemetry (traces, metrics, logs)
🤖 AI agents via MCP (private beta · per-tenant, read-scoped)
The OpenAPI 3.1 spec is published at /openapi/v1.json — generate typed clients for TypeScript, Python, Java, or C# with standard OpenAPI tooling.
In the product — AcmeRetail demo tenant, synthetic data · click any screenshot to enlarge
The in-portal API explorer — every endpoint with parameters and response codes, and the OpenAPI 3.1 spec one download away.The in-portal docs — key concepts, quickstart, connectors, and per-feature guides, searchable and shipped with the product (they also power the in-app assistant).
See every feature in a live sandbox.
Self-serve sandbox provisioning is rolling out — join the waitlist for an invite. Full API access, sample data pre-loaded, DSL simulator enabled, and a separate GraphQL endpoint with introspection on.
