Core concepts

Neuralis has a small, stable vocabulary, and it is deliberately the vocabulary of an organization: projects and members, roles and grants, agents with workspaces and schedules. Every other page of this documentation builds on the terms below — each entry here is a one-paragraph orientation with a link to the page that explains the concept in full.

ProjectCopy Anchor Link

The unit of membership and isolation. Users join a project with a role; agents, conversations, filesystem sources, and package enablement are all project-scoped, and a project's data lives in its own directory tree. A user who is not a member of a project cannot see that it has agents, packages, or sources at all. See multi-tenancy.

User and roleCopy Anchor Link

A user is an authenticated account; a role is what that user may do within one project. Roles (owner, admin, manager, member, viewer, plus custom roles) are bundles of feature grants, ordered by priority so that nobody can hand out a role stronger than their own. See roles and features.

Feature grantCopy Anchor Link

The atomic permission unit: string keys such as core.execute, drive.read, or platform.config, granted to roles and checked server-side before any data access or mutation. Anything not granted is denied. The prefix tells you the blast radius: a project.* feature acts inside your current project, a platform.* one crosses the project boundary. The owner role holds the '*' wildcard; the admin role holds every project-tier feature explicitly. Packages declare the features they provide and require — see features and access.

AgentCopy Anchor Link

An AI assistant configured inside a project: its model, system prompt, enabled packages, and tool access. Each agent owns its conversations and a per-agent data zone, including identity files it can rewrite to remember who it is and what it has learned. See agent-core.

PackageCopy Anchor Link

The unit of capability. Everything beyond identity and routing — chat, files, memory, terminal, admin, machine automation — ships as a package that declares its tools, skills, routes, App surfaces, connectors, and policies in files and a manifest, never in host code. Packages reach the platform along three paths: installed by the admin (the @neuralis/* builtins), dropped into a project's _packages/ directory (WASM-sandboxed), or discovered as source packages inside any synced filesystem source — no install step at all. See the package system.

ContributionCopy Anchor Link

A markdown file a package contributes to the agent's context, organized by category folder: skills/<name>/SKILL.md (a procedure the model can activate, with optional scripts), plus flat .md files under instructions/, rules/, agents/ (subagent personas), and docs/. Contributions are injected into the system prompt subject to package enablement and the caller's feature grants. See contributions and skills.

ToolCopy Anchor Link

A model-callable function declared by a strict JSON schema in a package's tools/*.json, executed by the package's handler. Tool calls pass feature gates, trust ceilings, input validation, and policy evaluation before they run. See tools.

Source and connectorCopy Anchor Link

A source is a mounted data location — a project's data folder, an extra host directory, the vector memory, a machine sandbox — identified by a slug and scoped to a project, user, or agent. A connector is the driver behind a source kind (local disk, brain vector memory, webtop machine, host the operator's own machine reached over the host broker). Synced sources are chunked and embedded into the vector index, which makes them semantically searchable and lets their markdown contribute source packages. See sources and connectors.

URICopy Anchor Link

Every file artifact is addressed as <source>://<path> — for example data://notes/meeting.md. Tools, routes, the UI, and the shell all resolve the same URIs, and per-path access is governed by URI policies evaluated against the caller's role. See brain-core for the vocabulary and URI policies for the protection model.

WorkflowCopy Anchor Link

A persistent, per-agent schedule entry that fires an instruction into a normal agent stream — on a timezone-aware cron schedule, at a one-shot time, or on demand. Runs queue, obey concurrency caps, and always execute as the workflow's creator with that person's current rights, never as a system identity. The Calendar widget is the workspace view over the whole project's workflow activity. See workflows.

SessionCopy Anchor Link

The single identity carrier for every operation: who is calling (userId), where (projectId, optional agentId), and with what authority (role and granted features). Routes, tools, and skill scripts all authenticate to the same session contract — there are no parallel identity paths. See sessions.

Workspace and widgetCopy Anchor Link

The workspace is the browser shell you see after signing in: a dock, tiled panels, and widgets. A widget is a App surface contributed by a package through its manifest — chat, files, terminal, machine, and admin are all package widgets. See the workspace and App surfaces.