MESkit public website

Architecture

MESkit uses a four-layer architecture that keeps operations typed, auditable, and reusable across interfaces. The same tool layer powers UI interactions, agent tool-use, and future MQTT ingestion paths.

Last updated: March 7, 2026

Summary

Design principle: one operation path, multiple interfaces.

Summary

UI clicks and natural-language commands both resolve to typed tool functions. Those functions validate inputs and execute against Supabase-backed ISA-95 tables. Intelligence layer logic and transport layers remain composable around that stable core.

Four-layer design

Current stack plus planned device transport.

┌──────────────────────────────────────────────────────────┐ │ Frontend (Next.js App Router, responsive UI shell) │ ├──────────────────────────────────────────────────────────┤ │ Tool Layer (Server Actions + Zod validation) │ │ UI calls tools • Agents call tools • same interfaces │ ├──────────────────────────────────────────────────────────┤ │ Intelligence Layer │ │ Ask MESkit • Quality Monitor • Planner │ ├──────────────────────────────────────────────────────────┤ │ Supabase (Postgres + Auth + Realtime + Edge Functions) │ ├──────────────────────────────────────────────────────────┤ │ MQTT Broker (M6) → Edge Function bridge │ └──────────────────────────────────────────────────────────┘

Tool layer rationale

Single source of truth for operations.

Type safety

Every tool contract is schema-validated before touching persistence, regardless of caller.

Testability

Business logic is isolated in functions that can be tested without UI rendering or model prompts.

Auditability

Tool-level call traces provide clear accountability for user and automated actions.

North Star architecture

Three automation layers building toward automated rescheduling.

Summary

The product vision is automated predictive rescheduling: predict a machine failure and coordinate the shop floor response before it happens. Three automation layers (Monitor, Plan, Act) build toward this — operators stay in command.

Monitor (Machine Health, M6) → detects degradation, outputs failure probability ↓ Plan (Production Planner, M5) → evaluates constraints, computes alternative schedules ↓ Act (Intelligence Layer, M1+) → acts through tool layer, updates schedules, notifies operators

In the MVP, these layers operate independently. Post-MVP, Monitor triggers Plan, which triggers Act — closing the coordination loop. See smart features for detailed profiles.

Intelligence layer

Claude tool-use with explicit constraints.

Runtime behavior

  • Injects mode and context before tool selection.
  • Accepts model-selected tool calls only from registered definitions.
  • Streams tool results back into assistant responses.
Example flowClaude tool-use
Prompt → tool selection → schema validation
→ execution against Supabase
→ structured result
→ final assistant response

Supabase and MQTT transition

Stable operational contracts across transport shifts.

Why Supabase

  • Postgres relational model aligns with ISA-95 tables.
  • Realtime channels support dashboards and event triggers.
  • Auth and edge functions reduce initial infrastructure overhead.

MQTT bridge design

  • Topic pattern: meskit/{line_id}/{workstation_id}/{event_type}
  • Gateway validates payloads and writes to Postgres.
  • Downstream behavior continues through existing tool logic.

Key facts and mini FAQ

Answer-ready architecture summary.

Key facts

  • Frontend uses Next.js App Router with SSR/SSG-friendly rendering.
  • Tool layer is the single source of truth for UI and smart features.
  • Intelligence layer uses Claude tool-use with explicit tool registration.
  • Three automation layers (Monitor, Plan, Act) target automated predictive rescheduling.
  • Supabase provides Postgres, auth, realtime, and edge functions.
  • MQTT bridge is planned for milestone M6 using the same operational contracts.

Mini FAQ

Why is the tool layer central?

It prevents business logic drift between UI handlers and agent actions.

Does MQTT require a separate logic stack?

No. MQTT changes transport, while execution remains on the same validated tool functions.

Where are realtime updates handled?

Supabase Realtime subscriptions push state updates to connected clients and triggers.

Canonical links

Supporting technical pages.