Djinious
Customer support
A model reads every ticket, rules do the routing, the clock is watched every quarter hour, and Friday’s digest writes itself.
DjiniousWorkflow
Webhook · classification · SLA clock
The ticket arrives on a webhook. A model classifies it — billing, bug, how-to, churn risk — and everything after that decision is ordinary graph: priority from the plan and the category, a queue, an SLA, a record, a page for whoever has to answer it.
The classifier’s error branch is a keyword rule set, because a triage queue that stops when an inference endpoint has a bad afternoon is not a triage queue you put in front of customers. Every record says which of the two labelled it.
How the graphs run
Inbound webhook
With its own token, per trigger.
ai:classify with a retry
And a rule-based fallback on its error branch.
A switch with four outputs
The SLA each queue carries is stated in the node.
Every fifteen minutes
What is late, what is about to be, and whose queue it is in.
On the canvas
ai:classify · flow:switch · entities:create · notify:* · Schedules
It ships with the product
This project ships with DjiniousWorkflow. One command seeds it, another runs every graph in it, and the captures here came out of those runs.
Where a graph leans on a fixture rather than a live system, it reads the fixture where your deployment would read a database — swap the node at the top and the rest of the graph does not change. The engine work — the fan-out, the gather, the approval, the publish — is the product’s own.
Keep exploring
Related use cases
DjiniousDataMaster dataOne customer view from four systems that disagreeCluster the records that describe the same organization, and keep the ones you are not sure about out of the merge.DjiniousDataSite monitoringCounting what a camera sees, not what it detectsObject detection over photos, footage and live streams, materialised as metrics you can alert on.DjiniousData