Field-operated over mobile-first
The device is treated as field equipment operating in a high-risk, low-trust environment rather than a generic handset.
Limited public design summary
Myosotis Design Summary
This document is a constrained summary of the Myosotis RFC set. It describes the architecture and design intent without making production, performance, or efficacy claims.
The public framing follows explicit claim discipline: design claims, constraint claims, and risk-bounding claims only.
What Myosotis is
Myosotis is a security-bounded architecture for field-operated AI tools on mobile devices. It defines how a mobile device can serve as a governed execution node in an AI system while preserving local policy enforcement, explicit invocation, attributable audit, and meaningful human consent.
The design is intended for environments where field conditions, sensitive context, and operational safety matter more than maximizing autonomy or cloud-side convenience.
Core design principles
Bounded tools over autonomous agents
Each tool action is narrow, explicit, and policy-scoped. No free-form or inferred authority is assumed.
Operational safety over capability expansion
The system is designed to contain failure, preserve operator clarity, and avoid hidden authority.
Trust boundaries over convenience
Devices, agents, tools, and registries are untrusted by default. Trust is established through policy, provenance, and audit.
Architecture in brief
Myosotis uses a two-plane model. The control plane handles discovery, identity, routing metadata, and scoped authorization. The data plane remains on or near the device, where policy evaluation, consent, audit, and tool execution occur.
This separation is intended to prevent a central service from becoming a hidden execution proxy or a silent authority over field-side actions.
Local authority and explicit invocation
A request from an agent does not imply permission to execute. Device-side policy remains the final authority. Tokens and routing metadata may define scope, but they do not override local enforcement.
Capability execution is explicit and constrained. New tools, new invocation paths, and new capabilities require deliberate definition and review rather than runtime expansion.
Consent and operator visibility
Human consent is treated as a security control, not a UX decoration. Where required by policy or context, approval must be specific, bounded, understandable, and attributable. Silence, timeout, or ambiguity do not imply approval.
Multi-device execution must remain legible to the operator. The system should not collapse distributed behavior into a single, ambiguous result.
Failure model
Myosotis is designed around deterministic, fail-closed behavior. Policy validation failure denies execution. Capability expiry hard-fails. Audit write failure aborts action. Network loss transitions the device into local-only behavior rather than silently degrading authority.
The goal is not uninterrupted autonomy. The goal is bounded behavior under adverse conditions.
Current status
Myosotis currently exists as a design and governance effort backed by RFCs, not as a production-validated product. The present value is the coherence of the architectural model, security invariants, and external claim discipline.
RFC sources
- RFC-001 establishes the decision to use security-constrained mobile MCP servers for field-operated AI tools.
- RFC-002 through RFC-004 define the threat, policy, audit, and compliance foundations.
- RFC-005 through RFC-007 define the reference architecture, failure behavior, and sync model.
- RFC-008 governs how public messaging must be derived from the RFC set without marketing overreach.
- RFC-009 through RFC-014 define distributed execution, federation, authorization, and consent semantics.