Business behavioural intelligence
One engine turns operational data into behaviour you can predict, explain and act on. It runs on your Mac.
A connected question normally needs a graph database, a vector store, a semantic layer, a feature store, a time series system and somewhere to run models. Each one is a separate contract, a separate copy of the data, and a separate place for the answer to go wrong. The joins between them become your problem.
Nexyron is one query surface, one transaction path, one storage layer. The graph is the mechanism, not a component.
Each of these fails in a warehouse because the answer lives in three places at once: what the subject did, where it sits in the organisation, and how long it has been that way. That is one behavioural query here.
Which of these assets fails before the next service window, and does moving the window actually prevent it?
Sensor and work-order history becomes a temporal stream per asset. The graph carries the site, the route, the part and the technician. A Lens scores failure risk; a policy estimates what a rescheduled visit is worth against the cost of making it.
Which accounts are behaving the way last year’s departures behaved, and has any intervention ever changed that?
Behaviour is the payment stream, the support history, the product events and the elapsed time since each, read together. Recorded interventions and their outcomes turn the second question from an opinion into an estimate grounded in what actually happened.
This order slipped four days. Which supplier, route and prior order share the cause?
Delay is a path problem before it is a statistics problem. The engine traces routes and shared bottlenecks across the order network in the same query as the numbers, so the explanation and the total come from one place.
Are these fourteen claims independent, or one network with three shared intermediaries?
The question is structural, and structure is what the engine is for. The engine’s network analysis exposes the shared actors, and meaning-based search over the claim documents finds the connections the identifiers do not show.
Is this site underperforming, or is it the cohort that site happens to serve?
The org tree is a graph, so a roll-up from site to district to division is a traversal rather than a join. Comparing like with like means holding the cohort constant, and the engine does that matching itself.
Most tools organise around a dashboard or a chat window. A dashboard freezes one shape of one question. A chat window forgets. A Lens is neither: it is a written contract between a business concept and an analytical purpose, and it is the thing that gets reused.
It states its subject and its intent, chooses its own indicators from what the data can actually support, declares the buckets it needs and refuses to run when the population is too thin to mean anything. When it finishes it leaves a report, a model artifact and a set of features that the next Lens can build on.
The engine
Competitors in this category describe outcomes and keep the mechanism private. The mechanism is the argument here, so it is on the page.
graph algorithms
centrality, community, flow, paths, similarity, structure
causal and decision procedures
uplift, propensity, doubly robust, off-policy, bandits
model procedures
scoring, calibration, ROC, gain, uncertainty, intervals
data styles, one query surface
graph, temporal, semantic, abstraction, model, decision
Streams are declared on the owner and carry indexed paths, rollups and wall-clock buckets. History, rollup, bucket aggregate and grouped bucket aggregate are procedures over the same graph, so a temporal answer and a structural answer are one query.
Node embeddings, edge embeddings, abstractions and abstraction artifacts share a single approximate-nearest-neighbour index and return one row shape. Retrieval adds bounded graph expansion, source references, score components, provenance and temporal hints.
Local ONNX and Core ML embedding providers run in-process. The macOS release converts the default model to Core ML at build time and ships the package as an application resource, so an installed app needs no Python and no external inference call.
Nexyron is not a Neo4j drop-in and does not pretend to be. Syntax carried from Neo4j, APOC, GDS or SQL fails deliberately, and every failure returns a diagnosis, the closest real symbols, the pages to read and a runnable example.
Committed work survives a crash or a power cut. Working sets larger than memory still run. Analysis is built to use the machine you already own rather than demand a bigger one, and when one machine is no longer enough the same engine grows across several and keeps answering when one of them fails.
HTTP, WebSocket and Bolt for the server. Embedded in your own process through Rust, Python, Node, C and WebAssembly. Connected to Claude, Codex and ChatGPT for the agent. Every route reaches the same connected model, so the answer is the same answer.
Open the app and the full analytical engine is running on your own computer. Your records, your documents and every answer built from them stay on hardware you own. Nothing is uploaded to be understood, nothing waits on someone else’s cloud, and the confidentiality of your business data is a property of the machine, not a promise in a vendor’s contract.
When one machine is no longer enough, the same engine grows into a resilient cluster inside your own data centre, run and governed by your own team.
Single-tenant, not a shared analytics cloud. The same build, the same interface, the same data model, with the operations handled.
Nexyron plugs straight into Claude, Codex and ChatGPT desktop. Your assistant reaches your business memory, your files, your saved reports and the behavioural analytics engine as tools it already knows how to use. No new interface to learn, and every answer comes back in a reliable, structured shape.
Access is asked for, never assumed. Choosing which business to open, writing changes and taking in new knowledge each require your confirmation, in the assistant you are talking to. And the connection works with the assistant your team runs today, without an upgrade project first.
The nearest thing to Nexyron is the ontology platform: a category built on the same conviction, that a model of how the business behaves has to exist before an answer can be trusted. We are building it from the other end.
Every governed system in this category depends on a semantic model authored in advance: an ontology, a modelling layer, a semantic view, a curated knowledge store. That authorship is the real cost, and it is paid before the first answer. Nexyron derives its abstractions from the records and the documents, then lets an operator correct them.
Uplift, propensity overlap, doubly-robust estimation, off-policy comparison and causal optimisation are procedures over the same graph the data lives in, called from the same query. Not a notebook next to the warehouse. Not a chart with a recommendation written underneath it by a language model.
The incumbent arrives as an implementation with a timeline and a team. Nexyron arrives as an app that starts a database, ingests your files and answers a question the same afternoon, on hardware you already own, with the option to become a cluster later.
Straight answers about the current state, so you know exactly what you are evaluating.
A working session on your machine with your files. If the answer is not in the data, Nexyron is built to say so rather than produce a confident number.