arxiv: 2605.04256 · v1 · submitted 2026-05-05 · 💻 cs.DC · cs.ET· cs.NE

Recognition: unknown

phys-MCP: A Control Plane for Heterogeneous Physical Neural Networks

Maliheh Hariri, Sebastian Otte, Stefan Fischer

Pith reviewed 2026-05-08 17:27 UTC · model grok-4.3

classification 💻 cs.DC cs.ETcs.NE

keywords physical neural networkscontrol planeheterogeneous substratesedge computingdigital twinsorchestration architecturewetware interfacestelemetry

0 comments

The pith

A common control plane lets physical neural networks from different materials act as standard resources in edge and cloud systems while keeping each material's timing and adaptability intact.

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

Physical neural networks perform computation directly in the physics of materials such as chemicals, cells, or photonic devices, which makes them promising for sensing and actuation right at the edge. The paper claims that these substrates can be brought into ordinary software workflows through a single orchestration layer that registers their individual capabilities and monitoring needs. If that layer works, developers could mix physical and conventional resources without rewriting control logic for every new material. The authors test the idea by building a prototype that handles several backend types and routes calls to a live biological system through the same interface.

Core claim

phys-MCP is a substrate-aware orchestration architecture that exposes physical neural substrates as discoverable and invocable resources for edge, fog, and cloud workflows. It defines a capability model, lifecycle semantics, telemetry interfaces, and digital-twin bindings that retain substrate-specific properties such as latency, resetability, plasticity, and I/O modality. A prototype with three representative backend classes, an HTTP execution path, and a Cortical Labs adapter shows descriptor-portable integration, improved runtime-aware matching, telemetry-aware recovery under faults, successful wetware execution, and small local control-path overhead.

What carries the argument

phys-MCP, the substrate-aware orchestration architecture built around a capability model, lifecycle semantics, telemetry interfaces, and digital-twin bindings that register and invoke heterogeneous physical substrates uniformly.

If this is right

Descriptor-portable integration lets the same workflow description run unchanged across multiple physical backends.
Runtime-aware matching selects physical resources more effectively than simpler static assignment methods.
Telemetry-aware recovery restores operation after representative faults in physical substrates.
The wetware-facing API path executes successfully inside the unified control model.
Local control-path overhead remains small enough to support practical edge deployment.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

The same capability model could be reused to coordinate large numbers of physical devices whose reset or plasticity behaviors change over time.
Hybrid applications become possible in which physical substrates handle immediate sensing while digital components manage longer-term planning.
Testing the architecture under sustained high request rates would reveal whether the twin bindings introduce bottlenecks at scale.
The approach suggests a path for treating neuromorphic chips and biological cultures under one registration and monitoring scheme.

Load-bearing premise

That a single set of capability models, lifecycle rules, telemetry interfaces, and digital-twin bindings can capture and preserve the distinct latency, resetability, plasticity, and I/O properties of each physical substrate without unacceptable overhead or loss of function.

What would settle it

A side-by-side measurement of end-to-end latency and plasticity retention for the Cortical Labs wetware path when driven through phys-MCP versus through its native API, checking whether the difference stays within the small-overhead range reported for the prototype.

Figures

Figures reproduced from arXiv: 2605.04256 by Maliheh Hariri, Sebastian Otte, Stefan Fischer.

**Figure 1.** Figure 1: High-level system architecture of phys-MCP. view at source ↗

**Figure 2.** Figure 2: Internal PHYS-MCP three-plane architecture. Internal three-plane architecture of phys-MCP. phys-MCP separates control-plane orchestration, twinplane state and validity management, and data-plane substrate access. The control plane handles capability discovery, task-to-substrate matching, invocation, lifecycle control, and policy enforcement. The twin plane aggregates telemetry from substrate adapters, mai… view at source ↗

**Figure 3.** Figure 3: Concrete closed-loop wetware workflow centered on the Cortical Labs view at source ↗

read the original abstract

Physical neural networks (PNNs) embed computation directly in material dynamics, including molecular, chemical, biological, photonic, memristive, and mechanical substrates. They are attractive for edge computing, especially at the extreme edge, where computation can be placed at the interface to sensing, actuation, or the physical process itself. However, PNNs are difficult to integrate into edge-cloud software stacks because each substrate exposes distinct interfaces, timing behavior, observability limits, and lifecycle requirements. This paper argues that the missing systems component is a common control plane for heterogeneous PNNs. We present phys-MCP, a substrate-aware orchestration architecture that exposes physical neural substrates as discoverable and invocable resources for edge, fog, and cloud workflows, while preserving their possible placement at the extreme edge. phys-MCP defines a capability model, lifecycle semantics, telemetry interfaces, and digital-twin bindings that retain substrate-specific properties such as latency, resetability, plasticity, and I/O modality. We instantiate the architecture through a prototype with three representative backend classes, an HTTP-backed execution path, and an integrated Cortical Labs adapter exposing a wetware-facing API path through the same control model. The evaluation combines controlled experiments on representative backends with end-to-end validation of the Cortical Labs path. Results show descriptor-portable integration across heterogeneous backends, improved runtime-aware matching over simpler baselines, telemetry-aware recovery under representative faults, successful execution against the API-backed wetware path, and small local control-path overhead. Overall, results provide prototype-level evidence that substrate-aware control can span heterogeneous physical AI resources, twin-backed backends, and a wetware-facing API path.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Desk Editor's Note private letter to a colleague

phys-MCP gives a working prototype control plane for heterogeneous physical neural nets including wetware, but the evaluation skips direct tests on whether it preserves native latency and plasticity.

read the letter

This paper introduces phys-MCP as a control plane that lets edge systems treat physical neural networks from different materials as ordinary resources. It supplies a capability model, lifecycle rules, telemetry hooks, and digital-twin bindings so that memristive, photonic, and biological substrates can be discovered and invoked without rewriting the rest of the stack. The prototype wires three backend classes together, adds an HTTP path, and routes calls through to a Cortical Labs wetware adapter using the same interface. That combination is new for this domain. The experiments show descriptor portability, improved runtime matching over a simple baseline, telemetry-driven fault recovery, successful wetware execution, and low local overhead. Those results are concrete and useful for anyone building mixed physical-AI edge setups. The soft spot is the missing before-and-after data on the properties the paper says it preserves. The central promise is that latency, resetability, plasticity, and I/O modality survive the abstraction layer, yet the reported numbers focus on integration success and recovery rather than direct comparisons of native versus mediated timing or learning curves. On variable biological hardware that gap matters. If those measurements exist deeper in the paper they should be highlighted; otherwise the retention claim rests on the architecture alone. This is for systems researchers working on edge orchestration or physical substrates. It is coherent, implements something real, and addresses a practical integration problem, so it deserves peer review even if the next round needs tighter performance evidence.

Referee Report

2 major / 2 minor

Summary. The paper proposes phys-MCP, a substrate-aware control plane architecture for heterogeneous physical neural networks (PNNs) spanning molecular, memristive, photonic, and biological substrates. It defines a capability model, lifecycle semantics, telemetry interfaces, and digital-twin bindings intended to expose PNNs as discoverable resources in edge/fog/cloud workflows while retaining substrate-specific traits such as latency, resetability, plasticity, and I/O modality. A prototype is implemented with three backend classes, an HTTP execution path, and a Cortical Labs wetware adapter; evaluation reports descriptor-portable integration, runtime-aware matching improvements, telemetry-driven fault recovery, successful wetware API execution, and small local control-path overhead.

Significance. If the retention claims are substantiated, the work supplies a missing systems layer for integrating physical AI substrates into standard software stacks, with particular value for extreme-edge deployments. The prototype's coverage of a wetware-facing path alongside conventional backends constitutes concrete evidence of cross-substrate orchestration feasibility.

major comments (2)

[Evaluation] Evaluation section: the reported results establish descriptor portability, runtime matching, fault recovery, and wetware API success, yet provide no direct before/after measurements of substrate-specific timing or state properties (e.g., reset latency for memristive or biological substrates, or plasticity reflected in learning curves) comparing native backend access versus phys-MCP-mediated access. This comparison is required to substantiate the central claim that the capability model, lifecycle semantics, telemetry, and twin bindings preserve distinct properties without unacceptable overhead.
[§3 and Evaluation] §3 (Architecture) and Evaluation: the 'small local control-path overhead' claim is presented without quantified breakdown by backend class or by operation type (e.g., telemetry polling versus invocation), leaving open whether serialization or abstraction costs remain acceptable for latency-sensitive or stateful substrates.

minor comments (2)

[Abstract] Abstract: the phrase 'improved runtime-aware matching over simpler baselines' is stated without naming the baselines or reporting the magnitude of improvement (e.g., success rate or latency delta).
[Discussion or Conclusion] The manuscript would benefit from an explicit limitations subsection discussing the scope of the three backend classes and any assumptions about substrate observability that may not generalize.

Simulated Author's Rebuttal

2 responses · 0 unresolved

We thank the referee for the constructive and detailed comments. We agree that strengthening the evaluation with direct comparisons and overhead breakdowns will better substantiate the central claims. We address each major comment below and will revise the manuscript accordingly.

read point-by-point responses

Referee: [Evaluation] Evaluation section: the reported results establish descriptor portability, runtime matching, fault recovery, and wetware API success, yet provide no direct before/after measurements of substrate-specific timing or state properties (e.g., reset latency for memristive or biological substrates, or plasticity reflected in learning curves) comparing native backend access versus phys-MCP-mediated access. This comparison is required to substantiate the central claim that the capability model, lifecycle semantics, telemetry, and twin bindings preserve distinct properties without unacceptable overhead.

Authors: We agree that direct before/after comparisons of substrate-specific timing and state properties are required to fully substantiate the preservation claims. In the revised manuscript we will add controlled experiments measuring reset latency, plasticity (via learning curves), and other timing properties for native backend access versus phys-MCP-mediated access on the representative backends. These results will quantify overhead and confirm that distinct substrate properties are retained. revision: yes
Referee: [§3 and Evaluation] §3 (Architecture) and Evaluation: the 'small local control-path overhead' claim is presented without quantified breakdown by backend class or by operation type (e.g., telemetry polling versus invocation), leaving open whether serialization or abstraction costs remain acceptable for latency-sensitive or stateful substrates.

Authors: We acknowledge that the overhead claim lacks a detailed breakdown by backend and operation. We will revise the evaluation section to include a quantified breakdown of control-path overhead, reported separately for each backend class and for distinct operations (invocation, telemetry polling, lifecycle transitions). This will clarify serialization and abstraction costs for latency-sensitive and stateful substrates. revision: yes

Circularity Check

0 steps flagged

No circularity; architecture and prototype evaluation are self-contained

full rationale

The paper presents a systems architecture for a control plane, defines capability/lifecycle/telemetry models, and validates them via prototype implementation across backends including a wetware adapter. No equations, derivations, fitted parameters, or predictions appear in the provided text. Central claims rest on experimental outcomes (descriptor portability, runtime matching, fault recovery, API execution, overhead measurements) rather than any self-referential loop or reduction to inputs by construction. Self-citations, if present, are not load-bearing for any derivation. This is a standard non-circular prototype paper.

Axiom & Free-Parameter Ledger

0 free parameters · 1 axioms · 1 invented entities

The work rests on domain knowledge about physical substrates rather than fitted parameters or new physical postulates.

axioms (1)

domain assumption Each physical neural substrate exposes distinct interfaces, timing behavior, observability limits, and lifecycle requirements that must be preserved.
Explicitly stated in the abstract as the core motivation for needing a control plane.

invented entities (1)

phys-MCP control plane no independent evidence
purpose: Unified orchestration layer for heterogeneous PNNs
The proposed architecture itself, validated only through the authors' prototype.

pith-pipeline@v0.9.0 · 5606 in / 1266 out tokens · 19713 ms · 2026-05-08T17:27:37.168136+00:00 · methodology

discussion (0)

Reference graph

Works this paper leans on

17 extracted references · 8 canonical work pages · 2 internal anchors

[1]

Beyond Silicon: Materials, Mechanisms, and Methods for Physical Neural Computing

S. Fischer et al.,Beyond silicon: Materials, mechanisms, and methods for physical neural computing, 2026.DOI: 10.48550/arXiv.2604.09833 [Online]. Available: https://arxiv.org/abs/2604.09833

work page internal anchor Pith review Pith/arXiv arXiv doi:10.48550/arxiv.2604.09833 2026
[2]

Neuromorphic intermediate representation: A unified instruction set for interoperable brain-inspired computing,

J. E. Pedersen et al., “Neuromorphic intermediate representation: A unified instruction set for interoperable brain-inspired computing,”Nature Communica- tions, vol. 15, 2024.DOI: 10.1038/s41467-024-52259-9

work page doi:10.1038/s41467-024-52259-9 2024
[3]

Model context protocol specification,

D. S. Parra and J. Spahr-Summers, “Model context protocol specification,” Model Context Protocol, Tech. Rep., Nov. 2025. [Online]. Available: https : / / modelcontextprotocol.io/specification/2025-11-25

2025
[4]

Edgemap: An optimized mapping toolchain for spiking neural network in edge computing,

J. Xue et al., “Edgemap: An optimized mapping toolchain for spiking neural network in edge computing,”Sensors, vol. 23, no. 14, p. 6548, 2023.DOI: 10. 3390/s23146548

2023
[5]

Biocrnpyler: Compiling chemical reaction networks from biomolecular parts in diverse con- texts,

W. Poole, A. Pandey, A. Shur, Z. A. Tuza, and R. M. Murray, “Biocrnpyler: Compiling chemical reaction networks from biomolecular parts in diverse con- texts,”PLOS Computational Biology, vol. 18, no. 4, e1009987, 2022.DOI: 10. 1371/journal.pcbi.1009987

2022
[6]

In vitro neurons learn and exhibit sentience when embodied in a simulated game-world,

B. J. Kagan et al., “In vitro neurons learn and exhibit sentience when embodied in a simulated game-world,”Neuron, vol. 110, no. 23, 3952–3969.e8, 2022.DOI: 10.1016/j.neuron.2022.09.001

work page doi:10.1016/j.neuron.2022.09.001 2022
[7]

Open and remotely accessible neuroplatform for research in wetware computing,

F. D. Jordan, M. Kutter, J.-M. Comby, F. Brozzi, and E. Kurtys, “Open and remotely accessible neuroplatform for research in wetware computing,”Frontiers in Artificial Intelligence, vol. 7, p. 1 376 042, 2024.DOI: 10 . 3389 / frai . 2024 . 1376042

2024
[8]

The digital twin synchronization problem: Framework, formulations, and analysis,

B. Tan and A. Matta, “The digital twin synchronization problem: Framework, formulations, and analysis,”IISE Transactions, vol. 56, no. 6, pp. 652–665, 2024. DOI: 10.1080/24725854.2023.2253869

work page doi:10.1080/24725854.2023.2253869 2024
[9]

Hogan et al.,Cl api: Real-time closed-loop interactions with biological neural networks, version 1.0, 2026.DOI: 10

D. Hogan et al.,Cl api: Real-time closed-loop interactions with biological neural networks, version 1.0, 2026.DOI: 10 . 48550 / arXiv . 2602 . 11632 [Online]. Available: https://docs.corticallabs.com/

2026
[10]

Recent advances in physical reservoir computing: A review,

G. Tanaka et al., “Recent advances in physical reservoir computing: A review,” Neural Networks, vol. 115, pp. 100–123, Jul. 2019.DOI: 10.1016/j.neunet.2019. 03.005

work page doi:10.1016/j.neunet.2019 2019
[11]

C. C. Horuz, A. Ceni, C. Gallicchio, and S. Otte,Scalable memristive-friendly reservoir computing for time series classification, 2026.DOI: 10.48550/arXiv. 2604.19343 [Online]. Available: https://arxiv.org/abs/2604.19343

work page internal anchor Pith review Pith/arXiv arXiv doi:10.48550/arxiv 2026
[12]

Physics for neuromorphic computing,

D. Markovi ´c, A. Mizrahi, D. Querlioz, and J. Grollier, “Physics for neuromorphic computing,”Nature Reviews Physics, vol. 2, pp. 499–510, Jul. 2020.DOI: 10. 1038/s42254-020-0208-2

2020
[13]

[Online]

Cortical Labs,Developer Guide: Cortical Labs API (CL API), Accessed: 2026- 04-17, Cortical Labs. [Online]. Available: https://docs.corticallabs.com/

2026
[14]

Toolformer: Language models can teach themselves to use tools,

T. Schick et al., “Toolformer: Language models can teach themselves to use tools,” inAdvances in Neural Information Processing Systems 36 (NeurIPS 2023), 2023. [Online]. Available: https://proceedings.neurips.cc/paper files/paper/2023/hash/ d842425e4bf79ba039352da0f658a906-Abstract-Conference.html

2023
[15]

Web of things (wot) architecture 1.1,

M. Lagally, R. Matsukura, M. McCool, and K. Toumura, “Web of things (wot) architecture 1.1,” World Wide Web Consortium (W3C), W3C Recommendation, Dec. 2023. [Online]. Available: https://www.w3.org/TR/wot-architecture11/

2023
[16]

Declarative lifecycle management in digital twins,

E. Kamburjan, N. Bencomo, S. L. T. Tarifa, and E. B. Johnsen, “Declarative lifecycle management in digital twins,” inProceedings of the ACM/IEEE 27th International Conference on Model Driven Engineering Languages and Systems, Association for Computing Machinery, Oct. 2024, pp. 353–363.DOI: 10.1145/ 3652620.3688248

work page arXiv 2024
[17]

Fischer,Phys-MCP prototype: Bridging physical and digital AI systems, 2026

S. Fischer,Phys-MCP prototype: Bridging physical and digital AI systems, 2026. DOI: 10.5281/zenodo.19595082 [Online]. Available: https://doi.org/10.5281/ zenodo.19595082

work page doi:10.5281/zenodo.19595082 2026