***

title: Runtime Architecture
description: 'Store, slices, middleware, and thunks in the current UE SDK'
slug: ue/architecture
---------------------

The current UE plugin mirrors the architecture of `@forbocai/core` and `@forbocai/node`: a central store, pure slice reducers/selectors, and thunk-based side effects.

## Root State

```cpp
struct FSDKState {
  NPCSlice::FNPCSliceState NPCs;
  MemorySlice::FMemorySliceState Memory;
  DirectiveSlice::FDirectiveSliceState Directives;
  BridgeSlice::FBridgeSliceState Bridge;
  CortexSlice::FCortexSliceState Cortex;
  SoulSlice::FSoulSliceState Soul;
  GhostSlice::FGhostSliceState Ghost;
  APISlice::FAPIState API;
};
```

Create a store with:

```cpp
auto Store = createSDKStore();
```

Use `ConfigureSDKStore()` only when you explicitly want the plugin's shared helper-layer store.

## Pure And Impure Boundaries

### Pure pieces

* slice reducers
* slice action creators
* selectors
* entity adapter updates
* JSON state-delta merge logic in `NPCSlice`

### Impure pieces

* API calls in `APISlice`
* local llama.cpp model load/inference
* local SQLite memory access
* Arweave upload/download helpers
* commandlet and Blueprint wrapper layers

The impure work is isolated in thunks, just as it is in the TypeScript SDKs.

## Middleware

`createNpcRemovalListener()` is the main cross-slice listener in `RuntimeStore.h`.

When an NPC is removed, it clears:

* directives for that NPC
* bridge validation state
* ghost session state
* soul slice state
* NPC block state
* memory state if the removed NPC was the active NPC

This is the UE equivalent of the coordinated cleanup behavior in the core SDK.

## Thunks First, Wrappers Second

Direct thunk usage is the canonical runtime model:

```cpp
#include "Protocol/ProtocolThunks.h"
#include "Memory/MemoryThunks.h"
#include "Cortex/CortexThunks.h"
#include "Bridge/BridgeThunks.h"
#include "Soul/SoulThunks.h"
#include "Ghost/GhostThunks.h"
```

`SDKOps::*` in `CLI/CliOperations.h` does not implement a separate system. It dispatches those same thunks and blocks on the resulting `func::AsyncResult<T>`.

## Functional Core Utilities

The plugin still uses `functional_core.hpp`, but now as support infrastructure for the store/thunk runtime rather than as a separate end-user API surface.

Key types used throughout the runtime:

* `func::Maybe<T>`
* `func::Either<L, R>`
* `func::AsyncResult<T>`
* `func::TestResult<T>`
* `func::ValidationPipeline<I, O>`

See [Functional Core](/ue/functional-core) for the helper-layer details.