Platform Tools — Vigil by Continuis Labs

Atlas

Physical Ontology

A typed map of your physical world — every asset, every relationship, every engineering property — anchored to the live measurement streams that describe its behaviour.

⚛️ Why "Atlas"?

An atlas is a collection of maps that together describe the physical world at multiple scales and layers — terrain, hydrology, infrastructure. Vigil's Atlas does the same for your plant or facility: it maps every physical asset and its interconnections, creating the structured context that raw sensor numbers alone cannot provide.

EntityTypes — typed asset schemas

Platform-provided and organisation-defined schemas for physical asset classes. Each type carries a JSON Schema of engineering properties — rated power, bearing model, impeller diameter — that form a structured specification for instances of that class.

PhysicalEntities — asset instances

Specific, named assets in your facility — "Motor B-04", "Tank #12 (North Yard)" — each typed, carrying validated engineering properties, and linked to their sensor bindings. Entities survive device swaps: when hardware is replaced, the digital twin remains intact.

EntityLinks — topology graph

Typed directional relationships between assets: drives, feeds, mounted_on, controls, upstream, downstream. This graph lets Argus reason about propagation — if a pump fails, what does it feed? What controls it?

Argus integration

Every entity has an ai_context field — rich natural-language context that Argus reads before reasoning about the asset. Memories generated by Argus are indexed to the entity, persisting across device swaps and recalibration events.

System Entity Types

Centrifugal Pump

Induction Motor

Storage Tank

Gate / Control Valve

Compressor

PLC

VFD

Heat Exchanger

Pipeline

Fan / Blower

Conveyor

Smart Counter

Structural Element

Generator

Custom Asset

Example topology

// VFD drives Motor → Motor drives Pump → Pump feeds Tank
"vfd-01"  --drives-->  "motor-b04"
"motor-b04" --drives-->  "pump-p12"
"pump-p12"  --feeds--->  "tank-north"
"vib-binding" monitors "motor-b04"
         aspect: "drive-end bearing vibration"

Impulse

Action Framework

Typed, validated, audited commands that push physical devices into new states — with a human-in-the-loop approval step before anything reaches the wire.

⚛️ Why "Impulse"?

In classical mechanics, an impulse (J = F · Δt) is a force applied over a finite time interval that changes a system's momentum — it is the smallest unit of deliberate physical intervention. Vigil's Impulse does the same: a typed command pushed to a device that changes its operating state, with a measured, controlled effect.

ActionTypes — command schemas

Platform-level and organisation-level command definitions, each with a JSON Schema for parameters, safety flags (confirmation required, reversible), and a command type hint for the dispatch layer. System types include set-sample-rate, reboot-device, schedule-ota, set-actuator-output, and more.

State machine lifecycle

Every action instance moves through a defined lifecycle. Argus proposes; a human approves; the platform dispatches; the device executes. Each transition is timestamped and logged. No action can skip the approval step for confirmation-required types.

Argus proposals

Argus can propose an Impulse action as a structured JSON card during any conversation — including the action type, target asset, parameters, rationale, and confidence score. The proposal card is rendered in the chat UI with a single-click Approve button.

Derivation lineage

Every action instance is linked into the DerivationEdge graph — tracking which conversation, alert event, or investigation prompted the proposal, creating a complete audit trail from observation to intervention.

Action lifecycle

proposed

→

approved

→

executing

→

succeeded

→

dismissed

or

failed

System action types

Slug	Target	Confirm?
set-sample-rate	binding	No
set-threshold-alert	binding	No
set-actuator-output	binding	No
set-onboard-alert	binding	No
trigger-calibration	device	No
reboot-device	device	Yes
schedule-ota	device	Yes

Scope

Signal Explorer

An oscilloscope for your entire fleet. Select any combination of channels, align them on a shared time axis, and see what the physics is actually doing.

⚛️ Why "Scope"?

An oscilloscope is the physicist's and engineer's canonical instrument for visualising signals over time — it makes invisible electrical phenomena visible. Scope does the same at fleet scale: it makes the invisible behaviour of machines visible by placing any combination of signals on a shared, zoomable time axis.

Multi-channel signal selection

Select any combination of raw device bindings and Prism-derived fields from any site. Each channel is assigned a distinct colour and displayed on a shared, pan-and-zoom time axis. Rubber-band selection for bulk channel picking.

Independent y-axis scaling

Each channel carries its own unit and scale. Temperature and vibration can coexist on the same time window without clashing axes — the platform handles unit display and scale independently per channel.

Prism overlay

Derived Prism fields — kurtosis, RMS, crest factor, temperature delta, dominant frequency — are displayed alongside the raw signals that produced them. The relationship between raw waveform and derived indicator is immediately visible.

Flexible time ranges

Quick-select presets (1h, 6h, 24h, 7d, 30d, 90d) and a custom range picker. Scope queries TimescaleDB continuous aggregates for fast rendering of long time spans, falling back to raw samples for sub-minute windows.

Common use patterns

Bearing fault diagnosis

Overlay raw vibration (m/s²) with kurtosis and crest factor from a Prism field. K > 3 and CF > 6 spiking in the same window are a strong bearing defect signature.

Process efficiency tracking

Visualise heat exchanger inlet vs outlet temperature delta alongside flow rate to compute instantaneous duty and spot fouling trends over weeks.

Fleet comparison

Select the same channel type from ten motors simultaneously to compare vibration baseline across a fleet — outliers jump out without needing a statistical model.

Prism

Derived Field Engine

A declarative signal-processing pipeline that decomposes raw measurements into physics-meaningful quantities — just as a glass prism decomposes white light into its spectrum.

⚛️ Why "Prism"?

A glass prism refracts white light and separates it into its constituent wavelengths — revealing structure that was invisible in the combined signal. Vigil's Prism does the same with measurement streams: it applies mathematical transforms that reveal the physical phenomena hidden inside raw sensor values — bearing fault signatures, process inefficiencies, structural modes.

JSON pipeline DSL

A Prism field is defined as an ordered list of step dicts — inputs, transforms, and outputs. Pipelines are versioned, inspectable, and can be built programmatically via the REST API. Each step references named stream aliases, making complex derivations readable.

Statistical fault indicators

Rolling kurtosis (K > 3 signals impulsive bearing events), crest factor (CF > 6 indicates incipient gear or bearing faults), skewness (asymmetry for cavitation detection), and peak-to-peak (signal excursion amplitude) — all computed in real-time over configurable windows.

Spectral analysis

FFT magnitude spectrum, dominant frequency extraction in a user-defined band (for shaft speed and gear mesh tracking), RMS band energy (for known fault frequencies like BPFO/BPFI), and Hilbert envelope demodulation for bearing fault signature extraction from high-frequency vibration.

∫

Calculus operations

Cumulative trapezoidal integration (∫ X dt) and forward finite difference (dX/dt). Convert acceleration to velocity to displacement, or compute rates of change for control-loop diagnostics — all in the pipeline without custom code.

Pipeline step reference

Category	Steps
Input	input
Arithmetic	add, subtract, multiply, divide, scale, offset, negate, abs, sqrt, square, log
Vector	magnitude — ‖(X,Y,Z)‖ for 3-axis vibration resultant
Rolling window	rms, peak, mean, smooth, peak_to_peak
Calculus	integrate, differentiate
Statistical	kurtosis, skewness, crest_factor
Spectral	fft_magnitude, dominant_frequency, rms_band, envelope
Utility	clip

// Bearing fault index pipeline
[
  { "type": "input",
    "binding_id": "<vib-uuid>", "alias": "vib" },
  { "type": "kurtosis",
    "input": "vib", "window": 512, "out": "K" },
  { "type": "crest_factor",
    "input": "vib", "window": 512, "out": "CF" },
  { "type": "envelope",
    "input": "vib", "method": "hilbert", "out": "env" }
]

Forge

Probe Registry

The authoritative library of sensor and probe definitions built on the Physical Device Protocol. Submit a spec, fork an existing one, and flash it to hardware — giving every transducer a self-describing digital identity.

⚛️ Why "Forge"?

A forge is where raw metal is heated and shaped into a precise, functional tool — a process that transforms an unstructured material into something with a defined form and purpose. Forge does the same for probe identities: it takes the raw specification of a transducer and shapes it into a structured, machine-readable definition that can be stamped directly into hardware EEPROM.

Probe library

A searchable, versioned registry of sensor and probe definitions — accelerometers, pressure transducers, thermocouples, flow meters, pulse-output counters, and more. Star probes you use frequently. Fork any probe to create a variant for your application.

PDP — Physical Device Protocol

Vigil's self-describing probe standard. A PDP-compliant probe carries its identity, calibration, quantity type, unit, and sample rate in EEPROM — meaning the platform auto-configures a new binding when a probe is connected, without manual setup.

EEPROM flash wizard

Select a probe definition from the registry, connect a transducer over USB, and Forge writes the PDP EEPROM payload directly to the hardware. Real-time flash status is streamed back to the browser. No firmware toolchain required.

Fork and customise

Any probe definition can be forked into your organisation's namespace. Customise the calibration coefficients, unit overrides, or channel mappings for your specific transducer variant — without modifying the upstream definition.

PDP EEPROM payload structure

// What lives in every PDP-compliant probe EEPROM
{
  "pdp_version":    "1.0",
  "probe_slug":     "adxl345-3axis-v2",
  "probe_name":     "ADXL345 Triaxial Accelerometer",
  "manufacturer":   "Analog Devices",
  "quantity":       "acceleration",
  "unit":           "m/s²",
  "channels": [
    { "label": "X", "axis": "x" },
    { "label": "Y", "axis": "y" },
    { "label": "Z", "axis": "z" }
  ],
  "default_sample_rate_hz": 100,
  "calibration": {
    "offset_x": 0.002, "scale_x": 1.001
  }
}

Self-describing hardware Auto-provisioning Zero-config bindings Fork & star USB flash wizard

Canvas

Live Dashboard Builder

Drag-and-drop dashboard builder with 12+ widget types. Share live, read-only public links — for regulatory audits, client SLA views, or remote situational awareness.

12+ widget types

Time-series line charts, gauges, numeric stat cards, alert status indicators, device status grids, maps with site markers, image panels, embedded PDFs, and rich text — all configurable and resizable on a free-form canvas grid.

Public sharing

Any canvas can be published as a read-only public link — no login required. Live data updates in real time for external viewers. Password-protection optional. Useful for client-facing SLA dashboards, regulatory compliance views, and operational status pages.

Scheduled snapshot reports

Configure a cron schedule and Canvas will capture a snapshot of the dashboard at the defined interval, archive it, and optionally send it as a PDF report. Historical snapshots are browsable in the Logbook.

Prism-aware widgets

All chart widgets can bind to Prism-derived fields as well as raw device bindings. Build a canvas that shows bearing kurtosis next to raw vibration, or heat exchanger efficiency next to individual temperatures — without writing any code.

Widget catalogue

Time Series
Multi-channel line chart with zoom and pan

Stat Card
Latest value with delta and threshold colouring

Gauge
Radial gauge with configurable alert bands

Alert State
Live alert status — active, cleared, acknowledged

Map
Site and device markers with status colouring

Device Grid
Fleet status grid — online, offline, alerting

Image
Static or URL-linked image panel

Embed / PDF
Inline document or external URL iframe

Argus

AI Engine & Institutional Memory

The hundred-eyed guardian of your fleet — always watching, always learning, surfacing anomalies and proposing interventions in natural language grounded in the full context of your physical infrastructure.

⚛️ Why "Argus"?

In Greek mythology, Argus Panoptes ("the all-seeing") was a giant with a hundred eyes who never slept — always watching, never missing anything. Vigil's Argus AI is named for the same quality: it monitors every signal across your entire fleet simultaneously, remembers what it has learned about each asset, and never loses context between conversations.

Natural language interface

Ask questions about your fleet in plain language. Argus translates to structured queries against your measurement history, Atlas entities, alert events, and Prism-derived fields — returning precise, grounded answers with citations to the underlying data.

Circadian consolidation cycle

Every night, Argus runs a consolidation cycle over the day's alert events, measurement anomalies, and AI conversations — distilling episodic experiences into long-term structural memories. The consolidated knowledge is indexed per asset, site, and organisation, and informs every future conversation.

Impulse proposals

When Argus identifies an actionable condition — a sample rate too low to catch a developing fault, an actuator output that needs adjustment — it can propose a structured Impulse action directly in the conversation. The proposal card shows the action type, target, parameters, rationale, and confidence. A single click approves it.

Atlas-grounded reasoning

Argus reads the Atlas topology before reasoning about any asset. It knows that the motor drives a pump, that the pump feeds a tank, and that the VFD controls the motor — so when it detects a bearing fault signature, it can reason about downstream consequences, not just the raw signal.

Argus tools

Tool	What it does
get_physical_entities	List or search Atlas entities; filter by type, site, or keyword
get_entity_details	Full entity: typed properties, bindings, topology links, recent memories
link_device_to_entity	Associate a device binding with an Atlas entity and aspect label
propose_action	Create a typed Impulse proposal card with rationale and confidence
get_action_status	Poll an Impulse action instance for execution state
get_derivation_chain	Trace upstream / downstream lineage via DerivationEdge graph
query_measurements	Fetch time-series data for any binding, with aggregation
search_memories	Semantic search over consolidated Argus memories

Named after
physics.

Deploy your first
device in minutes.

Named afterphysics.

Deploy your firstdevice in minutes.

Named after
physics.

Deploy your first
device in minutes.