This page is on the public orientation site — static HTML, no live link to your MEL instance. Status and API checks below apply when mel serve is running on your host.

Main surfaces in MEL

Status and diagnostics

Check readiness posture, transport visibility, and host-level checks via status endpoints and `mel doctor`.

Incidents and evidence

Incident queue, timeline context, proofpacks, and action history tie outcomes to persisted records.

Transports and messages

Observe ingest path health, stale/degraded conditions, dead letters, and replay context.

Control lifecycle

Submission, approval, dispatch, execution result, and audit state are separate for trust and attribution.

Semantic labels you should trust

  • Live: recent persisted ingest evidence exists.
  • Stale: evidence exists but is old for runtime confidence.
  • Historical/imported: context for analysis, not direct proof of current runtime.
  • Partial/degraded/unknown: known gaps, missing context, or unsupported conditions are explicit.

Common first questions

  • “Is MEL routing RF traffic?” → No. MEL is not the mesh routing stack.
  • “Why is doctor warning?” → On first run, missing active transports is normal and intentionally visible.
  • “Why does a map or panel look incomplete?” → Treat missing data as degraded/unknown, then inspect status, diagnostics, and transport logs.

Troubleshooting entrypoints

Ten-minute orientation checklist

  1. Read Quick start and run commands exactly once end-to-end.
  2. Confirm you can open the embedded console at 127.0.0.1:8080.
  3. Validate that degraded or unknown states are explicit when transports are not connected.
  4. Before deeper evaluation, review support matrix and limitations.