NeuroFabric · Architecture

Reference control-plane architecture

This page documents the runtime primitives NeuroFabric studies: governed execution, policy-bounded automation, deterministic orchestration, and an execution ledger for ordered traces, review, and replay-oriented workflows. It is a technical reference for the research initiative, not a product catalog.

Planning (including from a model) is separated from what may run: policy gates, a registry of allowed capabilities, ledgered steps, and orchestration that dispatches only to registered, deterministic tools.

End-to-end execution path

The diagram below is a reference ordering of concerns: planning, policy gate, allow-listed capabilities, append-style execution trace, dispatch, and bounded tool execution. Exact implementations vary; the intent is readable separation of phases without implying a single shipped layout.

Governed execution here means: nothing runs unless it passes policy against a known registry, and meaningful steps are reflected in an execution ledger suitable for review. Deterministic orchestration means the orchestrator invokes only registered adapters/tools under those constraints — not open-ended model-driven side effects.

Primitive shorthand

Many security and platform teams already use adjacent ideas. The table is a lexical bridge — not a claim that these enterprise controls are identical to NeuroFabric components.

Familiar control idea Runtime primitive in this architecture
Egress / access gate Tool policy and allow-list (registry)
Central event / audit log Execution ledger (ordered trace)
Orchestrated runbooks Deterministic orchestration under policy
Identity and tenancy boundaries Workspace / context boundaries

Use it to orient readers; the canonical definitions are the primitives in the following section.

Runtime primitives

How the architecture program talks about control — concise, implementation-agnostic where possible.

1

Policy and registry

  • • Policy-bounded automation: intent does not imply permission to execute
  • • Registry models allowed tools and adapters — not arbitrary endpoints
  • • Governed execution paths instead of ad hoc model-to-network chains
  • • Least-privilege framing for what the orchestrator may invoke
2

Execution ledger

  • • Ordered record of meaningful steps for review and incident-style analysis
  • • Supports replay-oriented debugging and audit-style narratives where applicable
  • • Complements (not replaces) your own retention and access policies
  • • Design space includes validation hooks; specifics depend on implementation
3

Deterministic orchestration

  • • Orchestrator dispatches only along registered, contract-shaped paths
  • • Separates non-deterministic planning from side-effecting execution
  • • Reduces prompt-injection surface against unregistered tools (design goal)
  • • Automation cannot exceed declared policy in this architectural model
4

Control-plane components

  • • Planner — structured plan from planning input (e.g. model output)
  • • Policy — gate on what may proceed
  • • Registry — authoritative allow-list of tools/adapters
  • • Ledger — execution trace for review and replay-oriented use
  • • Orchestrator — deterministic dispatch within constraints
  • • Context — bounded state visible to the path

Deployment topology (conceptual)

The initiative treats protected / sovereign / private deployment models as first-class design targets: residency, trust boundaries, and where the control-plane path runs relative to data and tools. The figure is schematic — it does not assert certifications, approvals, or a specific live topology.

Reference deployment topologyDiagram showing an outer protected environment boundary containing a control-plane execution path and registered tools, without implying any specific certification or approval. Protected environment (private / sovereign / air-gapped — design target) REFERENCE CONTROL-PLANE PATH Planning → policy gate → registry → execution ledger → deterministic orchestration Policy-bounded automation; ordered traces for review and replay-oriented workflows Not a statement of certification, approval, or a specific live deployment Registered tools & adapters Deterministic execution surface; no arbitrary outbound calls outside the registry model
Conceptual only: illustrates how boundaries and runtime primitives are discussed in the architecture program.

Collaboration and scope

Technical depth

Engagements focus on architecture, prototypes, and documentation — what is bounded, what is ledgered, and how orchestration stays deterministic relative to registered tools.

Reviewable artifacts

Outputs are meant for engineering and security review: explicit tradeoffs, open questions, and traceable narratives — not undifferentiated “AI” claims.

Deployment conversations

NeuroFabric is not framed here as the in-market deployment vehicle. For current deployment conversations, use Atlas.

In-market product

For current deployment conversations, see Atlas .

Continue with the architecture program

Contact is appropriate for research questions and technical discussion. For applied work and rollout, follow the Atlas pointer below.

In-market product

For current deployment conversations, see Atlas .

Contact (research) Work notes