The platform
Each application does one part of the work — and hands its evidence to the next. Use them together, or one at a time.
Platform overviewSee how the loop runs
DjiniousEngineeringOrchestration
DjiniousLabModelling & simulation
DjiniousWorkshopSystem integration
DjiniousSafeCertifiable code
DjiniousWorld3D replicas
DjiniousMapAgent GIS
DjiniousCCOperations & SCADA
DjiniousDataKnowledge base
DjiniousWorkflowAgent automation
DjiniousWorkflowAgent automationDjiniousWorkflow runs your operations as graphs: 330 nodes covering branches, loops, joins and human approval; databases, brokers, files and SaaS APIs; and models, where a model is the right tool. Every run is a document you can open — which node ran, what it produced, who approved it, and what it left behind.
DjiniousWorkflow
What it is
Most automation tools are a trigger, a list of steps and a log file. That is enough until the day a step fails halfway, a batch needs a person’s signature, or somebody asks what the number on the dashboard was actually computed from. DjiniousWorkflow is built around those three questions rather than around the happy path.
Fan a list out into one event per item, gather the results back, run two paths at once and join them, call another graph and wait for its answer. The structure is on the canvas, so the shape of the work is the first thing a new colleague sees.
branches · loops · joins · sub-workflowsFlow control, data shaping, dataframe verbs, sandboxed JavaScript, HTTP and GraphQL, LLM prompts and agents, entity CRUD — and connectors: SQL and document databases, object stores and files, brokers, notifications, and a long tail of SaaS APIs.
19 tools · one file eachA run draws itself: each node shows its state on the canvas as it executes, the log explains what happened, and a node’s output opens full-page — sortable, filterable, chartable, exportable. Open a finished run a week later and the widgets are still there.
live, node by nodeA graph can stop and wait for a decision. The pending approval is a row, not a held thread, so a run can sit on it for days across restarts and answer on whichever replica the person happens to reach. Rejection is a first-class path, not an error.
approvals are database rowsA views:* node writes into a saved page that outlives the run — a table, a chart, a metric, a map. Republishing replaces the data wherever the page has been arranged to put it, and every number on it traces back to a run you can open.
views · panels by keyGraphs live in projects with the resources they share: data, documents, files and links. A run can write a record into your own ontology, file a spreadsheet in the object store, or leave a link — each stamped with the run that produced it.
where the output goesInside the product
Every capture below is the running product.
01 · Build
Drag a node from the catalog, wire it, and set its parameters in the inspector. Every parameter accepts an expression, so a value can come from the payload, the run context, the loop counter or another node — and a node that needs a credential names one rather than holding it.
DjiniousWorkflow
02 · Run
Fire it by hand, on a cron schedule, from an inbound webhook, from the REST API, from another graph, or from an agent over MCP. Every route ends in the same queue, and every run records which one it was.
DjiniousWorkflow
03 · Watch
The run monitor draws the graph as it executes: a spinner while a node works, a check with its repetition count, a red mark carrying the failure message. Nodes that publish a widget draw it in place, and the log dock explains the rest. The run monitor and the editor are the same component with a different question in front of it: an operator watching a failure and an author fixing it should be looking at the same picture.
DjiniousWorkflow
04 · Publish
A graph that only logs is a graph nobody reads. These publish: a page of panels, a record in your own ontology, a file in the project, a notification, a webhook out. Each one is addressed by name, so the next run replaces it rather than piling up beside it.
DjiniousWorkflow
05 · The explorer
The glance you take while a run is going is not the look you take when the glance raised a question. Any node’s output opens full-page — sortable, filterable by column, searchable, chartable, profileable, exportable to CSV — and it works on the plain sql:query node nobody decorated, because it reads the task’s own result when there is no published widget.
DjiniousWorkflow
06 · The node builder
Some of what a deployment automates is specific to that deployment: an internal REST service, a GraphQL endpoint behind your VPN, one SQL statement everybody keeps rewriting. Building those into a product would be wrong, and asking for a pull request to get them is worse. So the app builds them: describe the call, name its parameters, test it against the real endpoint, and it lands in the catalog.
DjiniousWorkflow
AI & agents
A language model is very good at reading prose and poor at being audited. So in this product it reads the ticket, drafts the sentence, or explains the table — and the queue, the threshold, the tolerance and the approval stay in nodes a colleague can open and change. Both halves are on the same canvas, which is what makes the split visible instead of theoretical.
ai:prompt returns text. ai:extract returns JSON matching a schema you wrote, and retries once with the parse error fed back. ai:classify returns exactly one of your labels. ai:agent runs a tool-calling loop with a mission, an allow-list and a step ceiling. Each is a node like any other — timeout, retry policy, error branch.
In the graphs that ship with the product, the totals, the variances and the scores are computed by nodes. The model is handed the result and asked to write the sentence beside it. When a figure and a paragraph disagree, you can tell which one was measured — and the paragraph is the one that changes.
The showcase’s classifier falls back to a keyword rule set; its commentary node falls back to a plainly-worded sentence and the page is still built. An automation that stops when an inference endpoint has a bad afternoon is not an automation you put in front of customers, and the graph is where that decision belongs.
Point it at a vendor or at a model you run. Anything OpenAI-compatible works, which includes vLLM, SGLang, LM Studio and llama.cpp on your own hardware — so a deployment that cannot send text to a third party can still use every AI node.
The in-app assistant is a tool-calling agent with the platform’s own surface in front of it: list the catalog, author a workflow, run it, read its logs, query entities, resolve an approval. It is a client of the same REST API you are, under the same role checks — and its tool calls are visible as they happen, arguments and results included: a trace, not a summary.
A coding assistant, a scheduled analyst or your own tooling can list the catalog, create a workflow, run it, watch it, read the logs and answer an approval. The tool list is generated from the same catalog the palette reads, so a node built in this deployment appears in the agent’s tool list immediately — an agent’s abilities and a person’s stay in step by construction.
DjiniousWorkflow
Capabilities
DjiniousWorkflow is one Bun API over SurrealDB with a React client on top: an engine, a node catalog, a place for the graphs to live, and three ways in that do not involve a browser — what builds, what fires, what executes, what a graph reaches, and what it leaves behind.
A workflow is a set of tasks, each calling one function from the catalog, with the edges living in the nodes’ own inputs and outputs. That makes a graph one self-contained document you can export, diff in a pull request, and import somewhere else — not a database of rows that only mean something inside one installation.
Flow control (23), data shaping (15), dataframe verbs (20), transforms (19), sandboxed JavaScript (2), HTTP (6), AI (4), entity CRUD (6), artifacts (4), run widgets (10), pages (7), notifications (2) — and the connectors: SQL (40), document and key-value stores (25), analytics and search (22), brokers (11), files and object storage (30), push and mail (37), SaaS APIs (47).
A parameter declares its type, its help text, whether it is required, and when it is even relevant — an HTTP node hides the body on a GET. A credential parameter offers the credentials of that kind and nothing else. Every parameter also accepts an expression, so a value can come from the payload, the run context or the loop counter.
The header says whether the graph is runnable and, when it is not, which node and which edge is the problem. A draft is allowed to be incomplete — you save as you build — but a run refuses an invalid definition rather than discovering it three nodes in.
A schedule is a row with a cron expression, an optional timezone and a next-run time. Occurrences are claimed atomically, so with four replicas running exactly one of them fires each occurrence — the ordinary case, not a race to be avoided.
A trigger mints its own token and answers at its own URL. The body becomes the run’s input, and the trigger can name the task to enter, so one graph can serve several sources without a router node in front of it.
A single call starts a run; scoped API tokens (djwf_…) mean a script or a CI job can do it without a user session. A graph can also start another — fire-and-forget, or call-and-wait for its result.
Some runs should start when a person presses a button, and a run can also park mid-flight on a ui:trigger node and continue when somebody presses one on the canvas. The wait is a row like any other, so the press can land on any replica.
Every piece of run state — the queue of what to do next, a join’s partial arrivals, a suspended approval, a repeating timer — is a row in the database. A process contributes a worker loop and nothing else, so scaling out is running more replicas and a node that dies has its work picked up by the others.
For each turns an array into one event per item, and Collect accumulates them back. Each arrival is its own row rather than an append to a shared array, which is what keeps a forty-way fan-out from contending with itself, and what lets a gather survive the worker that started it.
A node can retry with exponential backoff. When the attempts are spent the payload leaves by the error branch — carrying the failure message and the payload that failed — so the graph handles it instead of the run dying. With no error branch wired, the workflow’s own setting decides between failing the run and letting the other branches finish.
An approval, an inbound signal, a delay of six hours, an interval that fires every ten minutes: none of them occupies a worker. They are rows with a time or a status on them, which is why a run can sit on a decision for days across restarts.
PostgreSQL, MySQL, MariaDB, SQLite, CockroachDB, Timescale, QuestDB, Supabase, Redshift, Yugabyte; MongoDB, CouchDB, Redis and friends; ClickHouse, Elasticsearch, OpenSearch, Meilisearch, Typesense, Qdrant, InfluxDB, Prometheus, BigQuery. Query, select, insert, upsert, update, delete, transaction — plus the introspection nodes that list and describe tables.
CSV, XML, YAML, JSONL, Excel and ZIP as pure format nodes with no network at all; S3, FTP and SFTP as location nodes that move bytes; Kafka, RabbitMQ, MQTT and NATS for the queues. Consume nodes are bounded and say so.
A connector node names a credential; the credential holds the value, sealed with AES-256-GCM, and no endpoint returns it. The same graph runs against staging and production by pointing at a different credential of the same name.
Build it in the app: an HTTP call, a GraphQL query, a SQL statement, a script, or another graph wrapped as a single step. It lands in the same catalog as the built-ins, so the palette, the reference page, the MCP tool list and the assistant all pick it up immediately — with no fork and no deploy.
A views:* node writes a table, a chart, a metric, some markdown or a map into a saved page. Panels are addressed by key, so republishing replaces the data wherever the page has been arranged to put it and keeps the title and size a person chose. A workflow is the only writer of panel data — the REST surface enforces it.
Entity types are defined at runtime — fields, a status machine, an icon — and a graph writes records into them. Every record carries the id of the run that produced it, so a figure on a page traces back to the execution that computed it.
A project holds artifacts: data, documents, images, video and links. Where the bytes go is the platform’s decision, not the caller’s — small payloads stay in the database, real files go to the S3-compatible object store, and a URL is stored as a reference rather than a copy.
In-app notifications, outbound webhooks, email over SMTP, and the push and messaging connectors for everything else. A graph that finishes quietly is a graph nobody trusts twice.
Graphs live in a project with the resources they share, and a graph reaches its project’s resources by name — so the same graph cloned into another project reads that project’s copy of ‘the source list’. Every workflow belongs to exactly one project; there is no unfiled state to tidy up later.
Entity types are configured, not coded: fields with types, a status machine with its transitions, an icon and a colour. A graph writes records into them, and the record carries the run that wrote it — which is how a figure on a dashboard is traced back to an execution.
A workflow exports as one JSON document and imports into another deployment. That is what makes a graph reviewable in a pull request, and what makes ‘promote this from staging’ a file rather than a migration.
Everything the UI does is an API call, and the UI is one client among several. Scoped tokens (djwf_…) let a script, a CI job or another service author, run and inspect a workflow without a user session.
An MCP server answers in the same process: list the catalog, create a workflow, run it, read its logs, resolve an approval, query entities. An agent with that endpoint can build and operate automation without a browser — and the tools it sees are generated from the same catalog the palette reads.
The platform contract other Djinious apps and djinious-atoms drive this one through: a versioned operation registry, a /capabilities document, and an OpenAPI snapshot committed to the repo with a unit test that fails on drift — because a consumer’s CI is written against that file.
Admin, user and viewer. A viewer sees workflows, runs and logs and can change none of them — including that a custom node exists without seeing its implementation, and never a credential’s value. The checks live next to the route handlers, not only in the UI.
Trust
The queue of what to do next, a join’s partial arrivals, a suspended approval, a repeating timer — every one of them is a row in the database. A process contributes a worker loop and nothing else. Everything here follows from that, including the parts that are inconvenient — so the limits are stated too.
A worker claims an event with a lease. If it finishes, the event is completed and its consequences are queued before the claim is released — so there is never a moment where the queue looks empty while work is still in flight. If the worker dies, the lease expires and another worker picks the event up. Delivery is at-least-once, and the engine says so plainly rather than implying exactly-once.
claim · lease · reclaimThe obvious implementation of a fan-in appends to an array on one record. That record becomes a contention point, and under a forty-way fan-out the losers of each write conflict lose their items silently. Here each arrival is its own row at its own id, and completion is claimed by taking the rows: exactly one worker gets them, the rest stand down.
one row per arrival, never an arrayBranches of a join arrive on different workers at the same instant, by design. The arrival that completes it is decided by a conditional claim rather than by a read-and-check, because a read-and-check is the same race one layer up. This is where the engine has been wrong before, and both bugs are pinned by tests that run ten branches finishing together, five times over.
count, then claimAn approval, an inbound signal, a delay, an interval: each is a row with a status or a time on it. No worker is parked, no thread is held, no memory is pinned. A run can wait days for a person and survive every replica restarting in the meantime — and the answer can land on whichever replica the person happens to reach.
wf_wait · wf_timerEvery replica runs the same loop against the same database. There is no coordinator to elect and no shard to assign: they compete for events, and the claim decides. A schedule’s occurrence is claimed the same way, so four replicas do not mean four runs at 07:00.
shared queue, no leaderA connector node names a credential; the credential holds the value, sealed, and no endpoint returns it — not to the UI, not to the API, not to an agent. That is what lets the same graph be exported, reviewed in a pull request and imported into another deployment without a secret travelling with it.
AES-256-GCM at restA run keeps the graph as it was when it started, its per-task status, repetition count, last result and error, its event ledger, and its log with the published widgets replayed into it. Records a graph wrote carry the run id, and artifacts carry the run that filed them — so the figure on a published page is traceable to the execution that produced it.
the run recordRoles are checked next to the route handlers, mirrored in the UI, never only in the UI. Scoped djwf_ tokens for scripts, CI and agents are minted and revoked per consumer, and an allow-list (WORKFLOW_HTTP_ALLOWLIST) bounds where a graph may call, when you want one.
admin · user · viewer · djwf_A node that dies between doing its work and recording it will run again. Idempotency is therefore the author’s job where it matters, and the catalog’s connector nodes are written to make it easy — upserts rather than inserts, named artifacts rather than appended ones.
stated, not hiddenThroughput is bounded by SurrealDB, because every event, arrival, wait and timer is a write. That is a deliberate trade: the failure modes it removes are worth more than the ceiling it imposes for the work this engine is for. It is not the right engine for a million events a second.
stated, not hiddenA JavaScript node runs in a Bun worker with a timeout, which contains a mistake and an infinite loop. It is not a security boundary against a hostile author, and the deployment’s own controls — who may write a graph — are what stand in that place. Local file nodes are confined to a configured root, and disabled rather than unrestricted when that root is unset.
stated, not hiddenIn the digital thread
DjiniousWorkflow does its part of the engineering loop and passes its evidence along — and it works just as well on its own.
Receives
DjiniousEngineeringSystem Ledger state and the results of its tool connectors — FreeCAD, KiCad, Onshape, Gmsh, OpenModelica, Blender — run as durable jobs that a graph polls.DjiniousEngineeringRuns started, watched and read back through Provider Interface v1 — the contract other Djinious apps and djinious-atoms drive this one through.DjiniousWorkflowAgent automationDelivers
DjiniousEngineeringResults landed in the System Ledger through the typed ledger nodes a graph uses on every engineering run.DjiniousLabCalls to its capabilities, made from a graph through the djinious-atoms federated catalog — one dispatch path and one credential for every Djinious app.DjiniousWorkshopCalls to its capabilities, made from a graph through the djinious-atoms federated catalog — one dispatch path and one credential for every Djinious app.DjiniousSafeCalls to its capabilities, made from a graph through the djinious-atoms federated catalog — one dispatch path and one credential for every Djinious app.DjiniousWorldCalls to its capabilities, made from a graph through the djinious-atoms federated catalog — one dispatch path and one credential for every Djinious app.DjiniousMapCalls to its capabilities, made from a graph through the djinious-atoms federated catalog — one dispatch path and one credential for every Djinious app.DjiniousDataCalls to its capabilities, made from a graph through the djinious-atoms federated catalog — one dispatch path and one credential for every Djinious app.DjiniousCCCalls to its capabilities, made from a graph through the djinious-atoms federated catalog — one dispatch path and one credential for every Djinious app.On its own it is a complete automation engine: 330 nodes reaching databases, brokers, files, SaaS APIs and models, with its run state, approvals and schedules in its own database. Six departmental showcase projects ship with it and run without any other Djinious application.
Use cases
6 worked cases.
Revenue operationsRevenue operationsInbound leads scored and routed in seconds, the pipeline swept every night, and a revenue page that rebuilds itself before the Monday meeting.DjiniousWorkflow
Customer supportCustomer supportA model reads every ticket, rules do the routing, the clock is watched every quarter hour, and Friday’s digest writes itself.DjiniousWorkflow
Site reliabilitySite reliabilityEndpoints probed in parallel, incidents opened by the failure itself, and nothing reaching a public status page without a person approving the words.DjiniousWorkflowFinance operationsFinance operationsInvoices matched one child run each, exceptions explained rather than listed, and nothing above the delegated limit released without a signature.DjiniousWorkflow
Supply chainSupply chainDemand joined to stock in SQL, the reorder policy in one readable node, suppliers graded on what they actually delivered, and every cold-chain excursion on a map.DjiniousWorkflow
People operationsPeople operationsA fortnight of small tasks with a start date, and three months of check-ins — none of it holding a process open between its moments.DjiniousWorkflowBook a demo
Ninety minutes against your own work, not a scripted tour. We build it in front of you, run it, and break a node on purpose — because how a graph fails is the part you are actually buying.
Along the thread
DjiniousEngineeringOrchestrationThe AI systems engineer: it takes the assignment and carries the whole project through a traceable System Ledger.
DjiniousLabModelling & simulationMulti-domain system models, digital replicas and a mathematical toolbox, driven by AI.
DjiniousWorkshopSystem integrationComponents wired into a complete system and closed through GPU physics in NVIDIA Isaac Sim.
DjiniousSafeCertifiable codeLean 4 specifications and kernel-checked proofs turned into panic-free embedded Rust, up to SIL 4.
Djinious
