Integration Model

The integration model defines how applications, services, devices, and existing protocols interact with the Spook Systems substrate. It is designed so that applications remain simple at the surface while the daemon provides deterministic shared-state underneath. Synchronisation, conflict resolution, ordering, and recovery are not implemented by applications — they are properties of the substrate.

The core principle is that applications do not coordinate with each other. They coordinate with the daemon, and the daemon coordinates with everything else.

Architectural Overview

The integration model is structured around three cooperating layers:

This separation allows incremental adoption without rewriting existing systems.

Application Read/write state · observe changes · trigger collapses No retries · no conflict resolution · no distributed logic Existing Protocol SMB · LDAP · SSH · MQTT · HTTP · CoAP · SQL Language Bindings createPair · readState · writeState · collapse Protocol Wrappers Intercept → Map to QRegisters → Generate QCandidates → Apply QDeltas Central Daemon ETCP · ESTP · QSCS · QN — identity, collapse, deltas, decoherence, re-entanglement, multi-node correlation Unix socket · named pipe · secure WebSocket · embedded bridge Applications remain stateless with respect to synchronisation. The daemon is the synchronisation substrate.

The Daemon

The daemon is the central runtime responsible for all deterministic behaviour. It manages:

Stateless at Rest

The daemon does not store persistent state in memory. All durable state lives in StateBlocks, QStateVectors, and QRegister histories. This allows the daemon to restart cleanly without losing correlation or requiring replay storms.

Transport-Agnostic

The daemon communicates over Unix sockets, named pipes, secure WebSocket tunnels, and embedded device bridges. Transport does not affect semantics.

Language Bindings

Bindings expose a minimal, deterministic API. They do not implement protocol logic; they simply send commands to the daemon and surface state changes.

Binding API createPair openPair readState writeState observe collapse Supported Languages C Rust Go Python JS/TS Java Swift C# Browser bindings use WebAssembly · communicate with daemon via secure channels

Binding Philosophy

Bindings are intentionally thin: no retries, no caching, no conflict resolution, no local state machines. All complexity lives in the daemon.

Protocol Wrappers

Protocol wrappers allow existing systems to adopt deterministic shared-state without rewriting their logic. They sit between the application and the daemon.

Protocol operation Intercept Map to QRegister Generate QCandidate Apply QDelta SMB · LDAP · SSH · HTTP · MQTT · CoAP · SQL Legacy systems gain deterministic synchronisation without architectural changes

Integration Patterns

There are three primary integration patterns, each suited to different environments.

1. Direct State Apps interact directly with QRegisters through bindings Microservices · Real-time collab Robotics · Agentic AI Spatial computing · High-frequency 2. Protocol Wrapper Existing protocols adopt deterministic sync via wrappers File systems · Directory services Messaging · Legacy enterprise IoT protocols 3. Hybrid Both direct state and wrapped protocols coexist Complex distributed systems Multi-cluster cloud Hybrid classical-quantum workflows All patterns share the same deterministic substrate

Browser Integration

Browser runtimes host HalfPairs inside WebAssembly. They communicate with the daemon through secure WebSocket tunnels, local relay processes, or embedded device bridges.

Browser HalfPairs behave identically to native HalfPairs: same state machine, same collapse semantics, same delta rules, same decoherence and re-entanglement.

This enables deterministic shared-state in web apps, PWAs, collaborative editors, and spatial computing environments.

Identity and Authentication

Identity is part of the deterministic substrate, not an application-level concern.

Identity Primitives EndpointID PairID HalfPairID QDomainID QGroupID Deterministic identity-based authentication · Multi-device session correlation Permission propagation through QStateVectors · Clean divergence for abandoned sessions Identity is not a bolt-on — it is part of the state machine

Deployment Models

The integration model supports multiple deployment topologies without changing semantics:

Local per device Sidecar microservices Node Agent clusters Gateway IoT devices Relay browser Coordinator QN domain The protocol family behaves identically in all deployments

Operational Model

The system is designed to be operationally simple.

Eliminated Remaining Tasks No leader election No consensus rounds · No global locks No replay storms · No full-state resync No conflict resolution · No distributed retries Daemon lifecycle Domain configuration Routing policies · Register schemas Wrapper mappings

Everything else is deterministic.