Streaming / observability
Real-time data stream analysis
Every event — a log line, a bid request, a sensor trace — is fingerprinted as it arrives and scored against everything the stream has already absorbed. Genuinely novel shapes stand out immediately — no regex library to maintain, no index to rebuild, and no query bill that grows with retention.
- Dedupe and cluster at ingest, before storage costs accrue
- A novelty score per line, against a rolling picture of the stream
- Constant memory per stream — the running summary never grows
Example use cases
- Log lines and traces. Dedupe, cluster and score at ingest, beside the log platform rather than in place of it; genuinely novel shapes stand out with no regex library to maintain and no query bill that grows with retention.
- RTB ad filtering. A bid request is a set of fields — geo, device, publisher, hour. Fingerprint the whole request once and score it inside the auction window, at the edge, with no feature store in the path: hundreds of thousands of events per second per node through the shipped scorer, well inside a 10 ms budget.
- Online defect analytics. Absorb sensor traces from known-good runs into a golden fingerprint per station; every new unit is then one comparison, drift shows as rising distance well before it shows as scrap, and it is small enough to run on the line controller.
How is this different from a Bloom filter?
A Bloom filter answers one question — have I seen this exact item before? — in constant space, and it answers it very well. It has no notion of almost: change one byte of a log line and it is a brand-new item. Engrammatic keeps the constant-space property but makes the answer graded, so a line that is nearly like a million others scores low and a line that is unlike anything scores high. Use a Bloom filter for exact membership; use this when "new-ish" is the thing you care about.
Does it replace our log platform?
No — it sits beside it. Hydrolix, Splunk, Datadog and friends store, index and let you query. We score at ingest so that far less has to be queried later. The integration is a tap on the stream, not a migration.
Why not just a threshold or a count-min sketch?
For a single field, use them — a threshold on a 5xx rate is simpler, cheaper and better, and a sketch is excellent for heavy hitters. The gap they leave is a combination that is individually unremarkable: this user, from this region, on this endpoint, at this hour. Scoring combinations is what one fingerprint per event buys you.
Request a briefing
Watch it work. Three short films, narrated and subtitled, recorded on the Stream Console exactly as it ships: a sample file to a validated job, that job to a clean stream, and the same job to an accountable stream with receipts you can bill.
1 · Create a job and validate it
4:18Start here. A new workspace picks a template and a bundled sample, builds an encoder, compares it with four simple baselines on held-out data, seals the winner, attaches it to a job and validates it through the real batch API. It ends on the evidence page and billing.
2 · Connect a clean stream (Mode A)
4:10A validated job becomes a live filter. Choose an operating point from the run's operating-points table, issue one key, run three commands, and watch the scorer flag events at line rate while keeping nothing. Each control is highlighted on screen as it is used.
3 · Connect an accountable stream (Mode B)
4:07The same job, connected so that every event the scorer scores is receipted back as an exact count. Name the stream, set how often it sends a receipt, issue one key and run the same three commands; then see the stream under Live streams, close it, and watch the tally and Billing reflect exactly the events the receipts carried.