Nexus — Sovereign Process Orchestration

01 — Competitive Position

N8N and Make.com are trigger-action workflow tools. They wire API calls together. They have no concept of a data model, no rule engine, no entity classes, no property-level constraints. When a workflow gets complex, users work around the tool with code nodes and external databases. The tool becomes scaffolding for custom code.

Nexus is not a trigger-action tool. It is a graph-native sovereign process orchestration platform with a four-resolution data model at its core. The graph is the execution model. Every Nexus deployment can run fully on-premises with no cloud dependency and no data egress.

02 — The Four Scales

Every Nexus entity and process exists at one of four resolution levels. The canvas is aware of all four. A user can drill into any node and descend to the next level, or navigate up and see the workflow context. The entire system — from a high-level pipeline down to a single field validation constraint — is navigable without leaving the Nexus UI.

The breadcrumb always reads Workflow / Node / Class / Property / Rule. Every level is its own graph. At Macro, the graph is nodes and edges. At Micro, it is classes and relationships. At Nano, properties and their dependencies. At Pico, rules and their precedence chains. Esc or breadcrumb navigation returns to the parent level.

03 — ChameleonV2: RBAC-Governed Form Engine

ChameleonV2 is a first-class Nexus component, developed in parallel with the platform. It is not a generic form library — it is a schema-aware, RBAC-governed, deltaPrism-typed form rendering engine that is tightly coupled to the Nexus data model.

When a Form node in a pipeline is executed, ChameleonV2 receives the Micro-scale class definition, the active RBAC role of the submitting user, the flow-level styling configuration, and the deltaPrism business data type constraints for each property. It renders the appropriate form variant in real time. No custom form code is ever written.

Schema Pull from Form Node

The Form node configuration specifies a class reference (by org slug + class ID from the Nexus pipeline API). At runtime, ChameleonV2 fetches the class definition and renders fields in property order. Field types, labels, required flags, enum values, and validation messages are all derived from the Nano-scale property definitions. The form re-renders automatically when the underlying class definition changes — no manual form maintenance.

RBAC Control Layer

Each user has a role within their org (defined at Org/Team level, M-NEXUS-F1). ChameleonV2 applies RBAC rules at render time to produce a role-specific form variant:

deltaPrism Business Data Types

Every Nano-scale property carries a deltaPrism business data type (BDT) in addition to its primitive type. The BDT controls how ChameleonV2 renders and validates the field:

Flow-Level Styling

The Form node configuration includes a style_ref pointing to a style definition stored in the pipeline definition. ChameleonV2 reads this at render time and applies it as a CSS token override layer over the base theme. This means:

04 — deltaPrism: Data Platform

deltaPrism is not a passive store. It is the active data platform layer of Nexus. It operates in three modes simultaneously within any given pipeline, and its role expands as pipelines grow in complexity.

Mode 1: Warehouse & Storage Layer

The Store node in any pipeline writes validated entities to deltaPrism. Entities are typed by their Micro-scale class definition. Relationships between entities (worker → document, client → project, invoice → bank entry) are first-class edges in the graph. Any downstream node in the same or a different pipeline can query these entities by class, property value, or relationship traversal.

Mode 2: Ingestion & Egress

deltaPrism acts as a standalone data source when a pipeline does not begin with a form submission. An ingest node pulls data from a CSV file, a JSON API endpoint, a database table, or a scheduled batch source. deltaPrism normalises the incoming data against the target class schema, applies property type coercions, and makes the result available to the next pipeline node. On the egress side, a deltaPrism egress node pushes entity data to an external system — a government API, a CRM, an invoice system — in whatever format the downstream system requires.

Mode 3: GPU-Accelerated Mid-Pipeline Transformation

When a pipeline contains multiple transformation operations in sequence, deltaPrism can take over the transformation layer entirely. Instead of routing data through the Nexus rule engine for each step, the pipeline hands off the intermediate dataset to deltaPrism, which:

This is the mechanism that made EXP-4 viable: 21,327 entities validated and written at 21ms/entity using the bulk-concurrent adapter. The GPU transform mode extends this to arbitrary multi-step transformation chains — all processed without leaving deltaPrism.

Business Data Types

deltaPrism maintains the authoritative registry of business data types (BDTs) for the deployment. BDTs are named type definitions that extend primitive types with domain-specific constraints: allowed ranges, format masks, normalisation functions, and display renderers. When ChameleonV2 renders a form field, it fetches the BDT from deltaPrism and applies the constraints client-side. When the rule engine validates a submission, it checks the same BDT server-side. The constraint definition lives in one place and is consumed by both layers consistently.

05 — Technology Stack

06 — Use Cases

Three concrete deployments drive the product roadmap. Each is a real system, real data, real org. They are not hypothetical scenarios. Building Nexus means making each of these run end-to-end.

07 — Roadmap

Phase 1: Foundation (complete)

Phase 2: Canvas (backend complete, UI not started)

Phase 3: Execution (backend complete, canvas not started)

Phase 4: ChameleonV2 Full Integration

Use Case Sprints (Sprints 4–6)

08 — Platform Features

Pipeline Switcher

The top-level Nexus menu contains a Pipeline Profile Switcher: a dropdown that lists all saved pipeline profiles available to the active org. Selecting a profile loads its full graph into the canvas — including node configuration, class definitions, and style. Profiles are independently deployable, independently runnable, and independently observable. Switching between Nesto, ENDO Marcin, and ARC Invoice happens in one click with no page reload.

Real-Time Canvas Execution Visualisation

During any pipeline run the canvas updates live via SSE. Each node transitions through visual states:

Data packet animations travel along edges showing the live flow of data between nodes. Hovering a completed node shows: execution time, input entity count, output entity count, and a link to the run log entry for that node.

Run Tracking and Logging

Every pipeline run produces a structured, queryable log:

The log viewer is a panel accessible from the canvas. It shows the run log for the active pipeline, filterable by date range, status, and entity class. Full-text search across all log fields. Export to JSON or CSV. Each log entry links back to the canvas run replay.

Phase 5 Roadmap Milestones

09 — Autonomous Demo

Demo Mode: C (Autonomous Default + Interactive Flag)

Decision confirmed 2026-04-18. The demo runs in two modes:

Demo Infrastructure Requirements

Nesto Demo: UAE Worker Onboarding

Full lifecycle: worker created → documents uploaded → OCR extracted → validated → HR review → approved → government API notified

RBAC roles seeded: Worker (Submitter), HR Admin, HR Manager, Compliance Officer (view-only). Full run: ~45 seconds autonomous. See: NEXUS_USECASE_NESTO.html

ENDO Demo: Three AI Employee Pipelines

Three independently switchable pipelines, all deployable to the same org in one demo.

See: NEXUS_USECASE_ENDO.html

ARC Demo: Revenue & Client Pipeline

Three pipelines converted from ARC repo flows into Nexus nodes.

See: NEXUS_USECASE_ARC.html

Demo Phase Roadmap

10 — Open Decisions

These decisions gate specific development paths. All other work continues in parallel.