PsyntientPsyntient

The Runtime Layer

The Psyntient Node.

The intelligent runtime of the Psyntient ecosystem. Every researcher, lab, institution, and developer runs a Node. Applications never touch the Vault or the Archive directly — they talk to the Node, and the Node handles the rest.

The Psyntient Node · Video coming soon

§ 01

What it is

The Psyntient Node is the runtime that sits between Applications and the Neural Vault + the Noetic Archive. It functions as the runtime for Psyntient-enabled software: applications communicate exclusively with the Node, and the Node owns every connection out to storage, the Archive, and other services.

The result is a federated architecture: computation and data ownership at the edge in each user's Node and Vault; collective scientific knowledge in the shared Archive.

§ 02

What the Node is not

Not an application

The Node has no product surface of its own. Applications — the Research Agent, Psyntient Ground, third-party apps and devices — sit on top and speak to the Node through its API.

Not a data store

The Node never permanently holds research data. It abstracts storage through drivers so the Vault can live wherever the user chooses.

Not tied to one backend

Local disk, Google Drive, Dropbox, Git, Amazon S3, NAS, or future providers — the Node speaks to all of them behind the same API.

§ 03

What lives inside every Node

  • Noetic InterfaceThe Node's primary user interface. A conversational surface where you search the Vault, manage projects, run analyses, schedule work, and configure the Node itself. Every Node has one.
  • CortexThe intelligent orchestration layer inside the Node — conversation, planning, reasoning, tool selection, workflow. The Cortex decides what should happen; it never manipulates storage directly.
  • Runtime servicesDeterministic workers the Cortex delegates to for projects, storage, scheduling, authentication, and Archive communication.
  • Plugin runtimeExtends the Cortex with new capabilities — a Research plugin, a Clinical plugin, a Dream-Analysis plugin, or anything a developer wants to add.
  • Node APIThe stable programmatic surface every Application talks to. Same API whether the Node is embedded in the app, running locally, or reached remotely.

§ 04

Intelligence separated from infrastructure

The Cortex handles the reasoning — conversation, planning, tool selection, workflow. Everything that mutates the Vault flows through a deterministic runtime service underneath it. That separation is what keeps the system auditable: the intelligent layer decides what should happen, and predictable machinery makes it happen, at the right time, in the right place.

§ 05

Deployment models

Applications don't need to know where the Node is running. Three deployment models expose the exact same Node API:

Embedded Node

Ships as a library inside the application itself. Zero configuration for the end user.

Local Node

A shared Node running elsewhere on the same computer — used by multiple applications and devices at once.

Remote Node

A Node running on another machine or server. Same API, over the network.

§ 06

Applications and plugins

A piece of software may talk to the Node from the outside as a standalone Application, or register capabilities back to the Node as a plugin the Cortex can invoke — a Research plugin, a Clinical plugin, an EEG analysis engine, a dream-analysis engine. Same architecture either way; the distinction is deployment.

§ 07

How data flows

Recording

ApplicationPsyntient NodeNeural Vault

Analyzing research

Research AgentPsyntient NodeNeural Vault

Publishing research

Research AgentPsyntient NodeNoetic Archive

Exploring collective knowledge

Any ApplicationPsyntient NodeNoetic Archive

§ 08

Why it matters

  • Applications never own research data. The user does.
  • Build once, work everywhere. An app that speaks Node speaks to every user's Vault and, with consent, the Archive — across every storage backend and every deployment model.
  • Consent and provenance are architectural — not features an application has to implement itself.
  • The Architect never accesses private Vaults. It only sees Observation Packets a user has explicitly published through their Node.