The Edge and OEM Runtime is selected as a deployment composition when the host device must own state, policy, evidence and optional inference inside a bounded local resource and egress profile.
Edge & OEM Runtime
Bring governed cognition to customer-controlled hardware.
Composes local state, ingestion, retrieval, answer assurance, egress policy and optional separately installed inference behind provider-neutral Rust contracts.
A useful local cognitive surface that can ingest, retrieve, reason, assure and retain state within the chosen device profile, with optional inference injected by the host and no mandatory external service.
Why it exists
The problem this module is designed to solve.
Appliances, desktops and field systems cannot assume permanent connectivity, cloud identity or server-class resources. A cloud-shaped AI stack can become useless when the network disappears and can make a device dependent on infrastructure its operator does not control.
02 / How it works
A bounded path from need to accountable result.
The public model below describes responsibilities and decisions, not sensitive implementation details, provider secrets or customer data.
- 01
Compose the local core
Select the state, ingestion, retrieval, assurance and policy capabilities the target product actually needs.
- 02
Inject optional execution
Let the host provide an approved local model, accelerator or remote endpoint without making it a core installation side effect.
- 03
Enforce the device boundary
Apply explicit storage, egress, resource and fallback policy appropriate to the hardware and operating environment.
- 04
Qualify the exact profile
Measure restart, storage, memory, latency, energy and failure behavior on the real target instead of extrapolating from another device.
03 / Customer and operator value
Creates a path to appliances, desktop, embedded and sovereign environments without forcing Docker, PostgreSQL or a vendor account into the core profile.
No mandatory model or external service
Network-denied Docker canary
Digest-pinned optional local assets
Host-injected provider and policy capabilities
04 / Where it creates value
Concrete situations, not generic feature claims.
These are representative product situations. Every deployment still requires its own policy, data boundary and acceptance criteria.
Sovereign knowledge appliance
Deliver local document understanding and governed answers inside a customer-controlled server or secure workstation.
Disconnected field operation
Keep core evidence and decision-support functions useful when connectivity is intermittent or prohibited.
OEM product integration
Compose Mentaview capabilities behind host-owned interfaces, hardware constraints and product-specific policy.
05 / Role in the cognitive system
A clear responsibility creates a trustworthy boundary.
No module is allowed to become an invisible monolith. It owns a narrow contract, composes with named capabilities and refuses responsibilities that belong elsewhere.
What it owns
- Air-gap composition canary
- Local state lifecycle
- Embedded provider selection
- Device profile contract
What it composes with
Rust direct APIEmbedded RetrievalOptional model packsHost SDK roadmap
What it refuses to own
Boundary before convenience.
Current executable evidence uses Docker isolation on laptop-class hardware. It is not a physical network cut or qualification of mobile devices, OEM SKUs, energy budgets, native ABIs or integrator packaging.
06 / Vision and mission
Useful when infrastructure disappears
This runtime makes sovereignty practical: the cognitive contract can survive the absence of a network, a cloud account or a bundled provider while remaining honest about each device's qualification level.
AI systems that remain useful, inspectable and sovereign across models, providers and deployment boundaries.
Build the cognitive layer that chooses the smallest sufficient path and turns evidence into accountable action.
Capture the value of advanced AI without surrendering data control, architectural freedom or intellectual honesty.
07 / Evidence and maturity
What the current label means — and what remains open.
ENGINEERING MATURITYM4Mentaview internal laboratory assessment
OBJECTIVE REVIEW
Passed with moderate confidence
The offline runtime, signed install chain, anti-rollback state and TPM transcript boundary are executable and locally failure-tested; physical-device claims remain false.
OPEN LIMITS
- No physical TPM execution or controlled power-cut campaign.
- No OEM target workload, fleet rollout or native packaging qualification.
- No measured target-device RAM, storage, latency or energy envelope.
What exists today
The real core-only binary passed a persistent restart and a sealed baseline-to-candidate-to-authorized-rollback exercise under Docker network mode none, with a read-only non-root sandbox, exact state handoff, local memory/RAG and zero provider calls observed. Its zero-valued egress fields are static declarations, not measured attempt telemetry.
Canary
A restricted test profile and supporting evidence exist. Results apply only to the stated profile and must not be generalized to other workloads or deployments.
What must earn promotion
Repeat on each physical target and qualify hardware-rooted signing and identity, power-loss, fleet rollout/revocation, storage, RAM, latency, energy, native integration and packaging.
Public truth boundary: M4− is a non-standard Mentaview engineering label for internal laboratory validation. It is not an official TRL decision and does not assert production qualification, customer acceptance, independent assurance, certification or universal performance. Inspect the complete assessment record.