How Vuo works

Business operations first. Transport mechanics second.

Vuo distinguishes technical health from business health. A Flow can have no exceptions, no failed Work Items, and a perfectly healthy Runtime — yet still be Critical because something expected by the business did not happen.

Vuo models an integration as a Flow and every durable execution as a
Work Item. SQL Server remains the authoritative state that operators, developers and automation can inspect.

01

Observe or schedule

A Flow discovers a source artifact or reaches a scheduled business execution. Logical identity prevents the same work from being created repeatedly.

02

Claim durably

A worker atomically claims eligible work with a short SQL transaction and a renewable lease. External I/O never happens inside that claim transaction.

03

Process with evidence

Custom C# processors work through named sub-steps and report structured failures. Input artifacts are hashable, reproducible and preservable for investigation.

04

Deliver safely

Vuo stages output, writes a temporary destination, verifies it and performs the final rename. A retry resumes from the latest safe milestone instead of blindly starting over.

05

Wait when business completion waits

Some work is delivered but not finished. Vuo can remain in Awaiting Acknowledgement until downstream evidence confirms completion.

06

Explain what happened

Work history, attempts, processor steps, failures, artifacts and operator actions create an investigation trail without requiring log archaeology.

State you can inspect

A small lifecycle with durable milestones.

States describe what the Work Item is waiting for. Phases and processor steps explain what it is doing inside that state.

PendingEligible durable work
ProcessingLeased by one runtime
RetryPendingWaiting for a durable retry time
AwaitingAcknowledgementDelivered; business completion still pending
CompletedTerminal success
Failed / QuarantinedRequires explanation or intervention
Architecture

Design non-goals

Vuo is deliberately not designed as a universal integration platform. Some capabilities are outside its intended scope so that the core system can remain predictable, inspectable, and operationally understandable.

Vuo is not intended to become:

  • A Kafka replacement or general distributed event-stream platform
  • A general-purpose enterprise service bus
  • A visual ETL or low-code transformation designer
  • A BPM or general-purpose workflow engine
  • An API gateway
  • A Kubernetes orchestration platform
  • A generic remote-command execution system
  • A requirement to hide SQL Server behind opaque infrastructure.

Why these boundaries matter

Vuo concentrates on a smaller set of problems: durable Work Items, explicit state transitions, safe retry and recovery, artifact provenance, business-level monitoring, custom C# processing, and operational visibility that a competent developer or DBA can understand without specialized platform knowledge.

Vuo does not hide operational truth

SQL Server is intentionally part of Vuo's operational model. Durable state should be understandable and inspectable rather than hidden behind an opaque broker or proprietary persistence layer.

Likewise, custom processors should not manage Work Item lifecycle, implement their own retry scheduler, delete source artifacts, or directly manipulate Vuo's database. Vuo owns orchestration and reliability; processor code owns business transformation.

No broker required

Designed for conventional Windows infrastructure.

Modern .NET, SQL Server, Windows services, local or network storage, and an eventual ASP.NET Core Console. No Kubernetes or separate message broker is required just to make integration work durable.

Request technical preview