Your events, your rules. Across your AI agents, applications, teams, workflows, platforms and partners.
Select business events by their fields, text and meaning. Deliver matches to the applications, agents and people that need them, through your configured destinations.
Illustrative example: shipment SHP-1042 has region EU, a delay of 180 minutes and a position about 7 km from the Milan hub. Sources: shipments from a Kafka topic, inventory from an SQL database, support from Elasticsearch, access from Google Pub/Sub, billing from AWS S3 and orders from an HTTPS API. Every rule on the Shipments source is checked at once, and two match. Rule 1, doc.region == "EU" && doc.delay_minutes > 120, sends custom JSON to the business application through a Kafka topic and to the operations team through ntfy push. Rule 2, geo.distance(doc.position, [45.46, 9.19], 50000), sends a copy to the AI assistant through an SSE stream. Each copy arrives as the original JSON and is reshaped for its outlet before it is sent: the application receives shipment, region and delay; the operations team receives the shipment and a message; the AI assistant receives the shipment ID and a context object. The workflow runner, analytics platform and logistics partner are not linked to these rules. Other examples use language detection, meaning, word proximity, fuzzy and text matching; some match one rule, some two.
Route by what the event says, not where it was published.
Topics are chosen by the system that produces an event, long before anyone knows who needs it. Field filters can compare a value, but not read a support ticket or a shipment note. Streaming lets each team describe the events it needs in one rule, and delivers only those.
| Can your team… | Topics and queues | Field filters | Noozle Streaming |
|---|---|---|---|
| …reach a destination the producer did not plan for? | Usually a new topic, or a change in the producer | Yes, with a filter per consumer | Yes, with a rule per destination |
| …select by the words in free text? | Usually filtered later, in consumer code | Prefix, suffix or wildcard on one field | Yes: words, phrases, typos and meaning |
| …combine any conditions with and/or? | Through topic naming | Within the filter format’s limits | Yes, any expression across fields |
| …select by place or language? | Usually in consumer code | Usually in consumer code | Yes, written into the rule |
| …see why an event was delivered? | The topic it was published to | Usually not recorded | Yes, a trace with the rule revision |
A category comparison. Individual products differ, and topics or simple filters are often the right tool for fixed routes.
Rules that read the whole event.
Combine fields with words, meaning, places and language in one expression. Streaming uses Gate’s policy language, so a rule your team learns once works for AI requests and business events alike.
{
"ticket": "TKT-3016",
"priority": "high",
"customer": { "tier": "gold" },
"subject": "Spedizione bloccata",
"text": "Il pacco è fermo a Bologna
da tre giorni: chiedo un rimborso.",
"position": [44.4949, 11.3426]
}
Fields and logic
doc.priority == "high" a value && doc.customer?.tier in ["gold", "platinum"] a nested list
Match · delivered to the priority support queue
Compare values, check lists and ranges, reach into nested fields and combine everything with and, or and not.
Words
near(doc.text, "pacco", "fermo", 2) words close together && fuzzy(doc.text, "rimborso", 1) one typo allowed
Match · delivered to logistics escalations
Find words near each other, tolerate typos such as “rimborzo”, match every form of a word, names and regular expressions.
Meaning
about(doc.text, "late delivery", 0.8) your threshold
Match · delivered to the customer care agent
The topic is written in English and the ticket in Italian. The rule selects by meaning, with a threshold you set.
Places
geo.distance(doc.position,
[44.4949, 11.3426], 30000) within 30 km of Bologna
Match · delivered to the Bologna hub team
Test positions in the event against a point and radius, or an area you draw as a polygon.
Language
detect_language(doc.text) == "it" the text’s language
Match · delivered to the Italian support team
Route each ticket to the team that reads its language, and combine it with any other condition.
Add every rule you need. The stream keeps its pace.
Streaming indexes your rules by what they look for, so each event is checked only against the few that could apply. Skipping is safe: the index follows each rule’s and/or logic and passes over it only when the event lacks the prerequisites of every way it could match. It never hides a match.
- Every rulefor every outlet, as your teams add them
- Indexedby the words, values and places each rule needs
- A few candidatesfor this event, chosen by the index
- Full evaluationdecides each match, exactly as written
From your sources to the right outlets.
Use the same policy language to select business events by their fields, text and meaning. Send matching events to the teams and systems that need them, with a delivery format for each destination.
Source integrations to discuss for your pilot. The current source API supports HTTP polling; the other source connections listed below require integration work agreed for the pilot.
- Sources
- KafkaAMQPPulsarNATS JetStreamGoogle Pub/SubAWS SQSHTTP webhooks
- Outlets
- KafkaAMQPPulsarNATS JetStreamGoogle Pub/SubAWS SQSAWS SNSHTTP streamsSSEPush alerts
Sources
Your topics, queues and webhooks.
Your rules
Combine fields, text patterns, language and meaning to select relevant events.
Outlets
Deliver matching events as they are, or select and rename fields for each destination.
A delayed shipment reaches the operations queue
Illustrative example. The source event supplies the status and region; the policy checks those fields.
Event
{
"shipment_id": "SHP-1042",
"status": "delayed",
"region": "EU"
}Policy
doc.status == "delayed" &&
doc.region == "EU"Match: deliver this event to the configured Kafka outlet, topic operations.shipments. The receiving system handles the follow-up.
Business exceptions
Send failed-payment or delayed-shipment updates to an operations queue, using status, customer tier and region from each event.
Team-specific feeds
Give each team the updates it needs. Select by region, product or business unit, then choose which fields to include in its feed.
Data-quality review
Flag missing business fields or inconsistent values in JSON records, and deliver the matches to a review queue.
Ticket routing
Route ticket data by topic and language, combined with priority and customer attributes already in the event.
Operations alerts
Send events reporting critical errors or exceeded thresholds to an operations queue or push alerts.
Analytics and AI feeds
Select relevant records and fields for your existing analytics, search or AI ingestion pipeline. Deliver them through a topic or queue.
Tell us which events you want to route and where they should go. Start a pilot with Noozle Streaming.
Start a Streaming pilotGive your AI agents the events they need, and only those.
An agent works best with relevant context and nothing else. Select events by meaning, keep only the fields the agent should see, and deliver them through an HTTP stream, a WebSocket or a queue it already reads. The same rules decide what each agent receives, so you can review them like any other policy.
-
1 · Select
By meaning
about(doc.note, "late delivery", 0.8)Only events about a late delivery reach the agent, however they are worded.
-
2 · Trim
To the context it needs
root.shipment_id = this.document.shipment_id root.context.hub = this.document.hub root.context.delay_minutes = this.document.delay_minutes
A mapping for this outlet keeps three fields. Everything else stays in your systems.
-
3 · Deliver
On a channel it reads
{"shipment_id": "SHP-1042", "context": {"hub": "Milan", "delay_minutes": 180}}Through an HTTP stream, a WebSocket or a queue the agent already consumes.
Illustrative example. Field names depend on your events.
Each outlet gets what it needs. Nothing more is kept.
- Your original event, unchangedwithout a mapping, each outlet receives the exact bytes your source sent.
- A format for each outleta saved mapping reshapes the event for one destination. It runs isolated and cannot change where the event goes.
- Only the routes you approvedevery delivery is checked against your rule and outlet links before any mapping or transport runs.
- One failing outlet never holds back the othersevery other matching destination is still attempted, and the failure is recorded for that outlet.
- Duplicates you can recogniseeach delivery carries an idempotency key and a correlation ID, so receivers can drop repeats.
- No copy in our databaseevents pass through for delivery and are never written to Noozle’s database or local files.
See why an event matched, and which revision decided.
MATCH q:212 rev 4 · event SHP-1042
Late deliveries for priority customers
AND ✓ field doc.priority == "high" matched OR ✓ semantic about(late delivery) score 0.8634 / 0.8000 » geo distance ≤ 30 km skipped after ancestor short-circuit
Delivered to 2 outlets · q:212 rev 4
- Revisions that mean somethinga rule’s revision changes only when its expression changes. Renaming or pausing it keeps the revision.
- Live, for a limited timestart a trace session on a rule and follow its decisions as events arrive.
- Evidence for each conditionwhich conditions ran, each score against its threshold, and what was skipped.
Each recipient sees only the fields it needs.
Decide per outlet which fields leave your systems, so analytics never receives a customer’s email and a partner never sees an amount. Events are never written to Noozle’s database, and the EU cloud runs on European infrastructure. These are technical controls you can show your DPO, applied to every delivery.
| Recipient | order | customer | email | amount | region |
|---|---|---|---|---|---|
| Analytics | Sent | Removed | Removed | Sent | Sent |
| Support | Sent | Sent | Sent | Removed | Removed |
| Partner | Sent | Removed | Removed | Removed | Sent |
Illustrative example. Each outlet’s mapping selects its fields; the original event is unchanged in your systems.
Start in our EU cloud. Run on-premise when you are ready.
Use the same policy language to route events in either deployment.
EU cloud
Made and hosted in EuropeStart your Streaming pilot.
- Operated by Noozle on EU-owned infrastructure
- Connect your sources and outlets
- Test rules against your business events
On-premise
Run in your own infrastructure.
- In your data centre or private cloud
- Connect to your internal topics and queues
- Your team operates the deployment
What Streaming does today, in beta.
We run pilots with teams who route real business events, and extend Streaming around what they need.
Rules
The policy language shared with Gate: fields, words, meaning, places and language.
Sources and outlets
HTTP polling sources today, other connections through pilot integration. Delivery to the outlets listed on this page.
Delivery
Original events or a format per outlet, with failures isolated per destination.
Evidence
Rule revisions and live traces for every rule.
Designed and built in Europe, on open and inspectable foundations.
Noozle is an Italian company, and your data stays under EU law, wherever your teams work. The team that wrote the policy language, the matching engine and the delivery runtime is the team you talk to. Need a new source or outlet? Tell us: we extend the product around what customers need.
Made
and hosted
in Europe
- Built on open foundationsrules run on the open-source Expr language, and transports on Bento, an open-source stream processor.
Start with the events you need to route.
Tell us your sources, rules and destinations.
Start a Streaming pilotContacts. Talk to us about Noozle.
Evaluating Noozle Gate or Noozle Streaming? Tell us which product you're interested in and what you need it to do. We're happy to answer questions about capabilities, integrations and deployment options.
Message received. Thank you for contacting Noozle. We’ll reply to your email address.