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
DjiniousDataKnowledge baseDjiniousData ingests the files, connectors and streams you already have, models them as your domain instead of ours, and keeps every dashboard tile, alert and AI answer attached to the records it was computed from. Click a finding and you land on the evidence.
DjiniousData
What it is
Most data stacks are four products stitched together: something that loads, something that models, something that charts, and something that finally lets an AI near it. Each keeps its own copy of who may see what, and the lineage dies at every seam. DjiniousData is one API-first control plane, and every capability exists as an endpoint before it exists as a screen.
CSV, Excel, PDF, DOCX, JSON and Markdown from the document store; external systems through connector plugins; video and live camera through the vision pipeline. Everything lands as a knowledge object carrying its own provenance, and an object whose provenance does not validate is refused rather than stored.
files · connectors · plugins · streamsEntity and relation types are defined through the UI or the API and stored in the database — not declared in a schema file and shipped in a release. An organization can layer its own fields, labels and status workflow over a shared base type without forking it.
entity types · relation types · per-org overlaysEntities, keywords, topics, sentiment and language are extracted by a deterministic offline enricher that needs no model and no network. An LLM improves the result when one is configured; it is never the thing standing between your data and being usable.
deterministic, with the LLM as an accelerantRecords that describe the same thing are clustered by blocking and pairwise scoring. Above 0.85 the platform merges; between 0.7 and 0.85 it holds the pair as a candidate for a human, and records the analyst’s decision so the next run honours it.
identifier 1.0 · exact name 0.85 · fuzzy 0.7Resolved entities are related into a navigable graph whose edges carry the objects they were derived from. Traversal is ACL-scoped before it returns a neighbour, so the graph cannot become the path around the permissions.
edges with evidence, not just arrowsWidgets query the underlying objects directly, so a tile is always current and always traceable. Alert rules watch an aggregate of a field per group and fire on a threshold. Reports cite the rows behind each section.
aggregates over records, computed on readInside the product
Every capture below is the running product.
01 · Ingest
Point the platform at a folder of documents, a connector or a camera. Each row, page or run becomes a knowledge object: parsed, normalised, deduplicated on a content hash, permission-mapped, enriched, embedded and persisted — with the source system, the source object id and the ingestion time recorded on the way past.
DjiniousData
02 · Model
Describe your domain as entity types and relation types — fields, labels, icons, a status workflow — and the platform builds the CRUD, the list views, the detail pages, the search facets and the agent tools around them. No migration, no deploy, no code.
DjiniousData
03 · Resolve
Cluster the records that describe the same real thing, relate the clusters into a graph, and keep the evidence on the edge. Every entity is also related to the organization that owns it, as a derived relation the platform synthesises rather than a stored edge you have to remember to write.
DjiniousData
04 · Signals
Analysis produces signals — anomalies, patterns, weak signals — each with a subject, a method, a confidence and references to the knowledge objects it was computed from. Severity is derived from confidence rather than assigned, so two findings at the same confidence cannot be ranked differently by whoever wrote them.
DjiniousData
05 · From finding to action
An alert without a case is a notification somebody eventually stops reading. The platform’s path runs the other way: the rule fires, the signal explains what was measured and what it implies, the case collects the evidence and assigns an owner, and the report is what leaves the building.
DjiniousData
06 · Reports
Structured reports whose sections are typed — narrative, entities, signals — and whose citations point at records rather than at other prose. A report is generated from the platform’s state, and can be generated from a case, keeping the link back to it. PDF and Excel export read the same records the screen is reading.
DjiniousData
AI & agents
The assistant is not a wrapper that reads your screen. It calls the same REST API you do, as the principal you are, in the organization you are in — so there is no second permission model to keep in step with the first, and nothing it can reach that you could not.
Read tools run freely; the tools that create, update, delete or relate anything stop and render an approve/reject card in the conversation. You see the exact call and its arguments before it happens.
Tools are gated server-side by the caller’s role. A viewer’s assistant is not told to behave; it is handed a smaller catalogue. There is no instruction to jailbreak, because the write tools were never in the conversation to begin with.
When the assistant reports on system health, a vision run or a set of entities, it renders the same React component the rest of the app uses for that data. You are looking at the platform’s view of the record, not at the model’s paraphrase of it.
The agent can pause mid-task for free text, a choice, or a password. A sensitive answer is stashed server-side and reaches the model only as a reference — so a credential can be used by a tool without ever entering the transcript.
Agents outside the app reach the platform through a Model Context Protocol server that threads the API key’s principal into the same handlers the HTTP routes call. Per-token scopes — read, write, admin, ai — are bounded by the owner’s own role, and only the SHA-256 hash of a token is stored.
Pointed at what has been ingested, the agent infers entity types, their fields and the relations between them, and writes the result as a proposal record. Accepting one creates the types through the same API a person would use; nothing changes on a model’s own authority.
DjiniousData
Capabilities
DjiniousData is one Bun process — HTTP, WebSocket and background jobs — over SurrealDB for records, graph, vectors and full text, and TimescaleDB for time series, with a React client on top.
Upload into persistent folders, select what you want, and ingest. CSV, XLS/XLSX, PDF, DOCX, JSON, Markdown and plain text are parsed in-process — PDF and DOCX without an external binary — and each tabular row becomes its own knowledge object.
External systems arrive through connector instances, each stamping its own source name so a dashboard can filter to exactly one feed. Connectors carry a sync interval, and a recurring scheduler job syncs the ones whose interval has elapsed.
Seven stages, in order: parse, normalize, deduplicate, permission-map, enrich, embed, persist. Each is a pure function of the envelope it is handed, which is why the same chain runs for a file upload, a connector sync and a fixture seed.
Every object records its source system, its source object id, its original URI, its ingestion time and its pipeline version. An object that fails provenance validation raises a terminal error instead of being stored — and a derived object with no parent references fails too.
A unique index on (source, external id) plus a content hash. Re-ingesting an unchanged row touches its update time and nothing else; a changed row is updated in place. Two writers racing for the same key converge on one record rather than two.
Numeric columns are also written to a TimescaleDB metrics table on the same load, so a threshold rule and a trend chart read the same ingest rather than a second, drifting copy of it.
Entity types and relation types are rows, created through the UI or the API. Fields, labels, plurals, icons and a status workflow are all data. There is no generated code and no migration between defining a type and using it.
All entity reads and writes go through one set of endpoints under /api/entities, driven by the type definition. A new type gets its list view, detail page, search facets and agent tools without a line being written for it.
An overlay keyed by (type, organization) layers extra fields, labels and workflow states over a shared base type, resolved for the caller’s own organization. One tenant’s extension does not become every tenant’s schema.
Every entity carries a derived relation to the organization that owns it. It is synthesised from the ownership field rather than stored as an edge, so it cannot fall out of step with the record, and it is read-only in the graph explorer.
The assistant can read what has been ingested and propose an ontology for it — types, fields, relations. The proposal is a record you review and accept or reject; it is never applied on the model’s own authority.
A shared identifier scores 1.0, an exact normalised name 0.85, a fuzzy name 0.7. The matchers are pure functions with no model behind them, so the same two records score the same today and next quarter.
Blocking, pairwise scoring, then union-find. Pairs at or above 0.85 are merged automatically; a fuzzy 0.7 stays a candidate. That gap is deliberate — it is where a person belongs.
When an analyst confirms or rejects a candidate the decision is stored, and the next resolution run honours it. Re-running the pipeline does not re-litigate a judgement someone already made.
Materialized graph edges keep references to the objects they were derived from, so an edge answers “why do you think these are related” with rows rather than with confidence.
Neighbour lookups filter by the caller’s permissions before returning, not after. A graph that filtered afterwards would still have told you the node existed.
Metric, breakdown, trend and map widgets query the knowledge objects directly, with a facet, a filter, a metric field and an aggregation. There is no materialized dashboard table to refresh, and therefore none to be stale.
The latest position per group, plotted on the same map component the rest of the app uses. It is fed by the ordinary ingest, so a fleet appears on a dashboard because its telemetry was loaded, not because a mapping feature was bought.
A rule watches a max, min, average or count of a whitelisted field over one source, grouped — per locomotive, per site, per device — and fires when it crosses a threshold. Rules are owner-scoped and evaluate against what that owner can see.
A dashboard is a named record scoped to an organization and a workspace. Publishing one is how a team gets the same view, rather than everyone rebuilding it from the same widget catalogue.
Change streams from the database fan out through a WebSocket hub, so a page reflects a write from another session without a poll loop underneath it.
An object-detection pipeline runs over a stored document, a public URL or a live stream, and its results materialize three ways: metrics for charting and alerting, a knowledge object for search, and optionally an entity per tracked object.
A tracker collapses hundreds of boxes of one parked truck into one track, because the number that belongs on a dashboard is “one truck”, not “nine hundred detections”.
Tracking assumes consecutive sampled frames overlap. On 1080p60 footage of a single walking worker, a stride of 30 reported 13 distinct people and a stride of 5 reported 2. Detection counts are unaffected; only the unique-object count degrades. Keep the sampled interval under ~0.2 s when that number matters.
Cameras are private-network by nature, so a stream source is refused unless its prefix is on the operator’s allow-list. Public URLs are checked against the same guard the platform uses for webhooks.
The worker posts detections back incrementally, which is what makes a live camera watchable and what preserves the work when a long run dies halfway.
Analysis produces signals — anomalies, patterns, weak signals — each with a subject, a method, a confidence and references to the objects behind it. Severity is derived from confidence rather than chosen.
A case collects signals, notes and evidence items into one thread with an owner and a priority, so a finding becomes work rather than a card that scrolls away.
Structured reports with typed sections and citations back to the source objects. A report is generated from the platform’s own state, so a figure in a report and the tile it came from cannot disagree.
Scripts with schedules and webhooks, versioned, with run logs. They call the platform’s own API, which means an automation is subject to the same permissions as the person who wrote it.
PDF and Excel export from the same records the screen is reading, plus a documented REST surface for everything else. The API is not a subset of the UI; the UI is a consumer of the API.
Users, credentials, sessions, organizations, workspaces and memberships; the ontology and its overlays; knowledge objects with their embeddings and full-text index; resolved entities and graph edges; dashboards, alert rules, signals, investigations and reports; the audit log and the job queue.
The metrics hypertable — the numeric series pulled out of ingested rows and posted by the vision worker, where a time-bucketed query over millions of points is the whole job.
One store for records means the graph, the vector search and the full-text search all see the same rows with the same permissions, with no synchronisation between them. Time series is the one workload that genuinely wants a different engine, so it gets one — and nothing else does.
Two connections, two failure modes, and metrics that can be behind the records they were derived from. The ingest writes both from the same pass so the window is small, but it is not zero and it is not hidden.
Trust
Multi-tenancy is usually a review problem: every new query is one missed filter away from a leak, and the defence is that somebody would have caught it. DjiniousData narrows the boundary in one place per record family, enforces it in the handlers every route shares, and records what happened whether or not anyone is watching.
The record families that belong to a customer — knowledge objects, resolved entities, documents, dashboards, alert rules, signals, cases, reports — are enumerated in a single module. Adding a table that should be scoped is a one-line change there rather than an audit of every handler that might touch it.
WORKSPACED_TABLESA caller may ask to see less. Naming an organization other than their own does not widen the result: a tenant user is bound server-side to their own organization regardless of what they pass.
?organization=An admin with no organization is a cross-tenant super-user; an admin with one is scoped to it. An organization admin cannot mint a global admin, move a user between organizations, or edit the shared base ontology.
isGlobalAdmin · isOrgAdminThe MCP server threads the API key’s principal into the same handlers the REST routes use. There is no agent-shaped path around the checks, and a token’s reach is bounded by the role of the user who minted it.
MCP dispatchEvery mutation is recorded as it happens — who, what action, which record, and from where — by the middleware every route passes through. Entity, ontology, connector, token and alert-rule changes all land in the same log, and a retention job sweeps expired events and dead sessions on a schedule.
auditArgon2id credentials, verified against a shared identity database so a single account works across every Djinious application, and sessions as a JWT signed with HMAC-SHA256. Roles are admin, user and viewer; server-side checks live next to the handlers, and the UI mirrors them but is never the enforcement.
Argon2id · JWTRecords and time series live in two stores, so a metrics query can be momentarily behind the records it was derived from. Connector-driven ingestion runs outside a request context and does not stamp organization on the objects it writes; a deployment that ingests per-customer scopes them explicitly.
stated limitsIn the digital thread
DjiniousData does its part of the engineering loop and passes its evidence along — and it works just as well on its own.
Receives
Starts from your own sources and systems.
DjiniousDataKnowledge baseDelivers
DjiniousEngineeringThe data an assignment depends on, ingested with provenance, modelled as the project’s own domain and served as governed, searchable knowledge — with findings and reports that open onto their evidence.DjiniousWorkflowRecords, search and findings over the documented REST surface and the MCP server, scoped exactly as the calling token is.DjiniousData is a complete, API-first data platform on its own: bring the files, connectors and streams you already have, and it ingests, models, resolves and watches them without any other part of the suite.
Use cases
4 worked cases.
Rail fleet telematicsCondition monitoring for a vehicle fleetTurn a device feed into a fleet you can ask questions about, and a maintenance plan you can defend.DjiniousDataDocument intelligenceMaking a document archive answerableA shared drive nobody can query becomes a searchable, cited corpus without a migration project.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.DjiniousDataBook a demo
Bring the export nobody trusts. Ninety minutes against your own data, not ours. We will ingest it in front of you and read the result as it comes — including the rows the platform refuses to merge, and why it holds them back.
Along the thread
Djinious
