Solutions · Data & Engineering
No black boxes and no lock-in on your fan data. Sfere is an API-first platform, composable with your warehouse — with connectors, a self-managed warehouse, SDKs, and a complete API CLI — that you run in-Kingdom, on-premise, or on any cloud, governed at the source.
$ sfere apply -f pipeline.yaml
✓ schema ticket.scan v12 · 3 match rules compiled
✓ routes: wh_main, crm · delivery at-least-once
config v47 applied · rolled out in-Kingdom · your cloud
$ sfere inspect profile P-101
identifiers: email + loyalty_no · events: 4 · consent: granted
$
apply · diff · inspect · rollback — the CLI mirrors the full API surface, so every change is reviewable in a pull request.
How an event moves through the platform
One backend handles the full event lifecycle, and every stage is inspectable rather than a step you take on faith. Ten taped events ride the line below — two are malformed, most are duplicates. Press run, then open any station: the line holds while you read the rules it executes.
run · pause · step · inspect
line held · press run
station held open · the line pauses while you read the rules
Events land through connectors, get normalized by a transform, and are checked against a schema before anything is stored. Malformed payloads bounce out with the exact field that failed — watch the reject tray under gate 01 while the line runs.
schema ticket.scan · v12
required: [event_id, user_id, occurred_at]
fields:
user_id: string # null → reject
occurred_at: rfc3339
on_error: reject · field-level detailstation held open · the line pauses while you read the rules
Identifiers you define merge events into profiles by rules you control, with priorities that decide contested merges. No model, no probability score — duplicates collapse into the profile your rules select, in the open, and every merge is logged.
match_rules: # deterministic
- { id: r1, key: email, priority: 100 }
- { id: r2, key: device_id, priority: 60 }
- { id: r3, key: loyalty_no, priority: 40 }
merge_limit: 5
conflict: highest_priority_wins
audit: every merge loggedstation held open · the line pauses while you read the rules
Warehouse tables map to the same identity graph, so batch history and live signal share one model. Historical data joins in-place — no copy, no extra ETL hop — and profiles pick up a + hist tag as they pass gate 03.
tables:
orders: { join: user_id, as: order_history }
loyalty_members: { join: loyalty_no, as: loyalty_state }
mode: in_place # zero-copy · no extra ETL hopstation held open · the line pauses while you read the rules
Enabled pipelines forward events to destinations you control, with delivery history and queue health queryable end to end. Toggle every destination off above and events queue visibly instead of vanishing — re-enable one and the queue drains.
destinations:
- { id: wh_main, type: warehouse, status: enabled }
- { id: crm, type: http, status: enabled, retry: backoff(3) }
- { id: ads, type: http, status: paused }
delivery: at_least_once · history queryable
queue: visible · drainableWhat data teams get from Sfere
The capabilities other teams consume as products are exposed to you as an API, a CLI, and infrastructure you own.
A connector framework normalizes web, app, streaming, and back-office events against typed schemas, so malformed payloads get rejected with field-level detail instead of poisoning the warehouse.
POST /v1/eventstyped schema · 422 with error.fields[]Rule-based matching stitches events, warehouse rows, and profiles on identifiers you define, with priority and merge limits you set, not a black-box model you can't audit.
match_rules[].prioritymerge_limit: 5 · every merge loggedMap tables in your columnar analytical warehouse to the same identity graph that handles live events. Historical data joins in-place, without a copy or an extra ETL hop.
JOIN orders ON user_idcopy: 0 · etl_hops: 0Every capability sits behind a REST API and SDKs, and a CLI mirrors the full API surface, so configuration is reviewable, versionable, and works with CI/CD.
$ sfere apply -f pipeline.yamldiff → pull request → CIConsent, access, and residency are enforced where the data lives, and every config object carries version history and soft delete, so a bad change is reverted, not mourned.
config v14 · soft_delete: trueconsent · access · residencyRun in-Kingdom, on-premise, or on your own cloud, on your keys and your infrastructure, with no data egress you didn't authorize.
deploy: in-Kingdom | on-prem | your cloudkeys: yours · egress: authorized onlyYour infrastructure, your rules
Sfere runs where you do. Consent, residency, and access are enforced at the data layer rather than bolted on after activation, and because configuration lives behind an API and a CLI, your pipeline is reviewable in a pull request instead of a vendor console.
typical cdp
Their cloud
sfere
Your deployment
Walk the API surface, the deployment model, and the identity-resolution rules with our team, and pressure-test where your fan data actually lives.