surface
Operator console
The product UI ships inside ./bin/mel serve (React + Vite from frontend/), not on this marketing surface.
MeshEdgeLayer · local-first · evidence-first
Incident intelligence for operators who need honest runtime truth.
MEL is a self-hostable operator OS for mesh and edge environments: persisted evidence, attributable control, and explicit degraded states — without collapse to “all green.”
- For field operators who own their stack
- Self-hosted binary; no mandatory cloud plane
- CLI and embedded console — this site is orientation only
Signal state semantics
MEL exposes these states across incident, transport, and node surfaces — never hidden behind a generic health indicator.
OBSERVED
Deterministic evidence from connected ingest
INFERRED
Bounded heuristic — labeled non-canonical
STALE
Evidence present but freshness expired
DEGRADED
Partial, unknown, or conflicting posture
States are derived from ingest evidence and configuration — not from UI defaults or assumed connectivity. Unsupported paths remain labeled unsupported.
What MEL is
A concise commitment before you invest time in build and deploy.
runtime
CLI-first binary
Init, doctor, serve, and demo paths are the spine. No mandatory hosted control plane for base viability.
accountability
Evidence and audit
Ingest records, timelines, proofpack-style exports, and control-path attribution stay first-class.
What MEL is not
- Not a mesh RF routing stack or proof of coverage unless your persisted evidence supports it.
- Not a generic dashboard that hides missing data behind a green badge.
- Not canonical truth from assistive inference — deterministic layers win when they disagree.
- Not a hosted SaaS — your data stays in the process you control.
Console emphasis
The embedded UI surfaces these categories. Depth lives in the running process, not this site.
workflow
Incidents and queue
State-centered incident workflow with rationale, replayable evidence context, and control lifecycle.
transport
Diagnostics
Readiness, stale signals, dead letters, and doctor output surfaced with bounded semantics.
export
Proofpacks and bundles
Triage-oriented exports and handoff flows — evidence containers, not narrative substitutes.
posture
Local runtime
Single binary serves API and embedded UI. Optional services stay optional and labeled.
Truth hierarchy
MEL's evidence model is explicit about where truth comes from and which layer wins conflicts.
- ①Runtime evidencecanonical
Typed deterministic records from ingest, state transitions, and audit events. Always wins conflicts.
- ②Bounded calculatorsdeterministic
Heuristics and calculators with explicit, documented inputs and bounded uncertainty.
- ③Assistive inferencelabeled
AI or heuristic assistance — always labeled non-canonical when present. Never overrides ① or ②.
- ④Narrative and UI copyfollows
Must not contradict layers above. MEL enforces this at the product level.
Full detail: Architecture overview · Architecture truth
Component map
High-level runtime structure. Contributors: see ARCHITECTURE_MAP.md in docs.
entry point
CLI / Daemon
cmd/mel — init, doctor, serve, demo, operator commands.
persistence
SQLite Store
Local operational database. Bounded claims require freshness awareness.
transport
Ingest Workers
Serial/TCP/MQTT paths persist evidence. Unsupported paths stay labeled.
surface
Embedded Console
React+Vite UI embedded in the binary. Served by mel serve, not this site.
Ingest posture matrix
Claim only what configuration and ingest workers actually persist. Unsupported paths stay labeled unsupported in UI and docs.
| Path | Posture |
|---|---|
| Direct serial / TCP | Supported — bounded by what the worker connected and stored. |
| MQTT | Supported — broker disconnects and partial ingest must remain visible. |
| BLE / HTTP ingest | Unsupported — do not imply partial product support. |
Full matrix: support-matrix.md · claims vs reality
Operator-truth doctrine
Evidence before narrative
Runtime records and audit events are canonical. Commentary follows evidence — never the reverse.
Explicit degraded states
Partial, stale, imported, and unknown states stay visible instead of being collapsed to "healthy."
Trusted control lifecycle
Submission, approval, dispatch, execution, and audit are separate states with attribution at each step.
Local-first posture
MEL remains useful without mandatory cloud dependencies. No hidden telemetry defaults.
Launch path
One path from first read to real operation.
Understand what MEL is
This page + Help / orientation. Read site vs console vs docs if the surfaces feel confusing.
Try MEL locally
Quick start with deterministic commands. Fixture mode available — no radio hardware required.
Understand operational boundaries
Support matrix and claims vs reality before deploying.
Contribute or extend
Contribution guide — issues, PRs, doc improvements, and operator feedback welcome.
Operate for real
Operations runbook for field deployment and incident workflow.
Clone and run
Full commands and caveats in Quick start. This block is the minimal spine.
shell — mel bootstrap
make build ./bin/mel init --config .tmp/mel.json chmod 600 .tmp/mel.json ./bin/mel doctor --config .tmp/mel.json ./bin/mel serve --config .tmp/mel.json
This public site does not connect to your MEL instance. Operator truth lives in the process you serve locally (or on your host), not here.
Why MEL exists
Incident response fails when stale data looks live, when intent and execution blur, and when exports omit context. MEL pushes the opposite: explicit freshness, lifecycle separation, and wording tied to evidence — not marketing comfort.
It is not the only tool for mesh operations. It is a narrow, strict tool for operators who want evidence-first language, governable control, and a runtime that admits gaps instead of hiding them.