STAR-SERVER-000 Composable Intelligence GServer Domains

Version	Date	Description of change	Did nsaspy approve it
0.1.0	2026-07-19	Seed domain-gserver composition and isolation architecture	Pending
0.2.0	2026-07-19	Depend on extended Sento, per-domain dispatchers, and ZeroMQ bridges	Pending

TODO Design File System

Objective

Define how StarIntel¹ composes specialized gservers² for:

HUMINT³
SOCMINT⁴
SIGINT⁵
cyber⁶
BBP⁷
threat intelligence⁸

The domain gservers are tools inside StarIntel. They consume and emit typed StarIntel documents⁹ and participate in actor-manifest¹⁰ and dataset-manifest¹¹ flows.

This design does not implement generic supervision, managed routers, dispatcher trees, remoting policy, or ZeroMQ socket ownership. Those capabilities belong to:

SENTO-000 Managed Component Runtime

Supporting research:

Decision

Use one extended Sento¹² actor system¹³ per StarIntel server process¹⁴ by default.

Inside that actor system, create one root domain supervisor¹⁵ and six child domain supervisors:

/user/domains
/user/domains/humint
/user/domains/socmint
/user/domains/sigint
/user/domains/cyber
/user/domains/bbp
/user/domains/threat-intel

Each domain supervisor owns one complete actor subtree¹⁶ and exposes one domain-gserver handle¹⁷.

A logical domain is not automatically a separate actor system or process.

A separate process is used when the domain requires independent deployment, scaling, privilege boundary, memory limit, or crash containment.

Required Sento extension dependency

StarIntel domain gservers require the following SENTO-000 capabilities:

actor failure policies
structured termination reasons
supervisor actors
child specifications
one-for-one, one-for-all, and rest-for-one restart strategies
managed router pools
keyed routing
mailbox overload policies
mailbox drain and deadline shutdown
public mailbox and dispatcher metrics
component handles
component registry
scoped event buses
secure Sento remoting
ZeroMQ¹⁸ reactor components

StarIntel must not recreate these features as private domain-specific glue.

Domain-gserver definition

A domain gserver contains:

one root supervisor
one control dispatcher¹⁹
one default domain dispatcher²⁰
zero or more subdomain dispatchers²¹
one typed ingress actor²²
zero or more workflow coordinators
zero or more managed router pools²³
domain-local state actors
optional domain-local event bus²⁴
optional ZeroMQ reactor²⁵
actor-manifest registrations
dataset-manifest bindings
health and readiness state
lifecycle and restart policy
mailbox, dispatcher, router, and transport telemetry²⁶

Default runtime tree

@startuml
skinparam componentStyle rectangle

component "StarIntel Server Process" as Runtime
component "Extended Sento Actor System" as Sento
component "Domain Root Supervisor" as Root
component "HUMINT GServer" as HUMINT
component "SOCMINT GServer" as SOCMINT
component "SIGINT GServer" as SIGINT
component "Cyber GServer" as Cyber
component "BBP GServer" as BBP
component "Threat Intel GServer" as ThreatIntel
component "Shared Service Components" as Shared
component "Sento Remoting Adapter" as Remoting
component "ZeroMQ Adapter" as ZMQ
component "Star Router Adapter" as StarRouter

Runtime --> Sento
Sento --> Root
Root --> HUMINT
Root --> SOCMINT
Root --> SIGINT
Root --> Cyber
Root --> BBP
Root --> ThreatIntel
Root --> Shared
Root --> Remoting
Root --> ZMQ
Root --> StarRouter

HUMINT --> Shared
SOCMINT --> Shared
SIGINT --> Shared
Cyber --> Shared
BBP --> Shared
ThreatIntel --> Shared

HUMINT --> Remoting
SOCMINT --> Remoting
SIGINT --> ZMQ
Cyber --> ZMQ
BBP --> StarRouter
ThreatIntel --> ZMQ
@enduml

The transport arrows are examples. Actor and dataset manifests select the actual adapter for each declared route.

TODO Dispatcher Architecture

Per-domain rule

Dispatchers are per domain by default.

Every domain receives:

one small control dispatcher
one default data dispatcher

A domain may define subdomain dispatchers inside the same process.

Workload-class dispatchers may exist as shared platform services, but they are not the main domain ownership boundary.

Domain dispatcher examples

:domain/humint/control
:domain/humint/default
:domain/humint/source-management
:domain/humint/interviews

:domain/socmint/control
:domain/socmint/default
:domain/socmint/platform-telegram
:domain/socmint/platform-discord
:domain/socmint/media

:domain/sigint/control
:domain/sigint/default
:domain/sigint/ingest
:domain/sigint/decode
:domain/sigint/correlation

:domain/cyber/control
:domain/cyber/default
:domain/cyber/discovery
:domain/cyber/scanning
:domain/cyber/analysis

:domain/bbp/control
:domain/bbp/default
:domain/bbp/programs
:domain/bbp/enumeration
:domain/bbp/findings

:domain/threat-intel/control
:domain/threat-intel/default
:domain/threat-intel/feeds
:domain/threat-intel/enrichment
:domain/threat-intel/correlation

These names are examples. The actor manifest declares actual dispatchers.

Control-dispatcher restriction

The control dispatcher runs only:

supervision
lifecycle
registry operations
routee management
readiness and health
overload decisions
transport control
metrics snapshots
shutdown coordination

Collection, parsing, enrichment, storage, analysis, and other normal domain work must not run on the control dispatcher.

Subdomain rule

A subdomain is a named area inside one domain process.

A subdomain may own:

dispatcher
supervisor
managed router pools
mailbox limits
scoped event bus
ZeroMQ reactor
metrics prefix
readiness and health state

A subdomain is not automatically a new process.

TODO Domain-GServer Protocol

Every domain gserver implements equivalent operations:

start-domain
stop-domain
restart-domain
domain-ready-p
domain-health
domain-ingress
domain-capabilities
domain-routes
domain-workers
domain-dispatchers
domain-subdomains
domain-mailbox-metrics
domain-transport-status
domain-manifest

The public object is a domain-gserver handle.

Callers do not need to know whether the domain is:

local in the same actor system
local in another actor system
remote through Sento remoting²⁷
remote through ZeroMQ
remote through Star Router²⁸

The handle contains stable logical identity and opaque²⁹ routing information rather than raw actor internals or socket pointers.

TODO Domain Layout

HUMINT gserver

Owns HUMINT-specific workflows such as:

source and contact records
tasking and collection plans
interview and debrief ingestion
report normalization
relationship extraction
timeline construction
review queues
source-facing and analyst-facing workflow actors

Possible subdomains:

source management
interviews
debrief processing
relationship analysis
review

SOCMINT gserver

Owns social-media intelligence workflows such as:

platform collectors
profile and account normalization
post, message, thread, and reaction ingestion
media and attachment processing
identity and account correlation
interaction graph generation
platform checkpoint actors
platform-specific rate and session actors

Possible subdomains:

one per platform
media processing
account correlation
graph updates
collection scheduling

SIGINT gserver

Owns signal-oriented workflows such as:

stream and session ingestion
sensor and receiver metadata
protocol and format decoders
signal-event normalization
channel and session correlation
temporal correlation
decoder worker pools
high-volume bounded mailboxes

Possible subdomains:

ingest
decoding
session tracking
temporal correlation
storage

Cyber gserver

Owns cyber operations and analysis such as:

asset discovery
network and service documents
web and protocol observations
vulnerability and exposure analysis
incident documents
malware and artifact analysis
infrastructure correlation
cyber graph updates

Possible subdomains:

discovery
scanning
web analysis
vulnerability analysis
malware analysis
incident response

BBP gserver

Owns bug-bounty-program workflows such as:

program and scope ingestion
scope validation
target locks
enumeration workflows
tool execution coordination
finding normalization
duplicate-finding analysis
reproduction packaging
submission-state tracking

Possible subdomains:

program management
scope management
enumeration
finding analysis
submission tracking

BBP remains separate from general cyber because program scope, target locks, finding duplication, and submission state require separate workflow state.

Threat-intelligence gserver

Owns threat-intelligence workflows such as:

feed ingestion
indicator normalization
tactic, technique, and procedure mapping³⁰
campaign and actor documents
enrichment
scoring and prioritization
watchlists
cross-source correlation
alert generation

Possible subdomains:

feeds
normalization
enrichment
actor and campaign tracking
correlation
alerting

TODO Shared Service Components

Do not duplicate generic services inside every domain.

Provide shared components for:

document validation
normalization
persistence
CouchDB³¹ operations
search
attachment processing
optical character recognition³²
entity resolution
graph updates
embedding generation³³
language-model requests³⁴
audit and telemetry emission

Domains call shared services through typed component handles.

Shared services must not contain hidden domain policy.

Shared services may have their own platform dispatchers and process boundaries.

TODO Actor Hierarchy and Naming

Use the domain supervisor actor context for domain-owned children.

Actor names must be unique only inside their immediate actor context.

Repeated leaf names are permitted:

/user/domains/socmint/collector
/user/domains/cyber/collector
/user/domains/threat-intel/collector

Cross-domain actors do not discover each other by arbitrary actor path.

Cross-domain work enters through:

destination domain ingress
declared shared-service handle
declared actor-manifest route
declared dataset-manifest flow

TODO Local Router Use

Use extended Sento managed routers for homogeneous³⁵, independently processable local work.

Good routee-pool candidates:

document validation
text normalization
parsing
optical character recognition
attachment metadata extraction
entity extraction
independent enrichment calls
independent database operations

Do not randomly route stateful target, case, account, sensor, program, or dataset state.

Use keyed routing for stateful affinity³⁶.

Every router pool is owned by a domain or subdomain supervisor.

TODO Transport Selection

Local Sento

Use local Sento actor messages when source and destination are inside the same actor system.

This is the default and lowest-overhead route.

Sento remoting

Use Sento remoting when both endpoints are Sento actor systems and location-transparent actor-reference behavior is useful.

The hardened remoting layer must use explicit exports, safe serialization, deadlines, peer policy, and structured errors.

ZeroMQ

Use ZeroMQ when:

the destination is another process
the destination may not use Sento
asynchronous ROUTER/DEALER messaging is useful
a cross-process event bridge is useful
a one-way worker pipeline is useful
the topology benefits from ZeroMQ endpoints and proxies

Each domain may own a ZeroMQ reactor component.

Ordinary domain actors never access raw ZeroMQ sockets.

The extended Sento runtime owns socket threads, context lifetime, CURVE security³⁷, ZAP authentication³⁸, overload mapping, monitoring, and restart.

Star Router

Use Star Router for client-facing and application-level cross-process routing.

Star Router remains the external routing boundary and may route to a local component handle, a Sento remote handle, or a ZeroMQ remote handle.

Transport decision table

Requirement	Local Sento	Sento remoting	ZeroMQ	Star Router
Same actor system	Default	No	No	No
Direct remote Sento actor reference	No	Default	Optional	Optional
Non-Sento service	No	No	Default	Default
Client-facing API	No	No	No	Default
Asynchronous request and reply	Yes	Yes	ROUTER/DEALER	Yes
Loss-tolerant event fanout	Local event bus	Possible	XPUB/XSUB	Possible
Stateless one-way work	Local router	Possible	PUSH/PULL	Possible
Durable delivery	No	No	No	Depends on backend
Raw socket exposed to domain actor	Never	Never	Never	Never

TODO ZeroMQ Domain Wiring

A domain that enables ZeroMQ receives:

/user/domains/cyber
├── supervisor
├── ingress
├── registry
├── routers
└── transports
    └── zeromq
        ├── reactor-supervisor
        ├── bridge
        ├── monitor
        └── endpoint-state

The ZeroMQ bridge actor runs on the domain control dispatcher.

The dedicated reactor thread owns all sockets.

Domain and subdomain actor manifests declare:

endpoint identifier
socket pattern
bind or connect role
remote node
target component export
serializer
security policy
queue limits
deadline policy
restart policy
event topics or work routes

Example actor-manifest fragment:

(:transport
 (:kind :zeromq
  :reactor :domain/cyber
  :pattern :router-dealer
  :endpoint :cyber-node-ingress
  :connect "tcp://cyber-node.internal:7710"
  :target :cyber/ingress
  :serializer :starintel-schema-v1
  :security :curve-internal-nodes
  :send-high-water-mark 1000
  :receive-high-water-mark 1000
  :send-timeout-ms 250
  :linger-ms 1000))

This is a configuration example, not the final manifest syntax.

TODO Event Policy

A domain may use:

local scoped Sento event bus for reliable in-process notification attempts
ZeroMQ XPUB/XSUB for loss-tolerant cross-process event distribution
dataset-manifest flows for document movement
durable event or database storage when replay is required

All events use typed, namespaced envelopes.

Minimum domain event:

(defstruct domain-event
  domain
  subdomain
  event-type
  trace-id
  dataset
  document-id
  generation
  payload)

PUB/SUB is not used as the only channel for required lifecycle transitions, commands, or messages that must survive subscriber downtime.

TODO Lifecycle and Supervision

Every domain and subdomain declares:

child specifications
startup order
reverse shutdown order
restart strategy
restart limits and window
permanent, transient, or temporary child class
readiness rules
health rules
failure escalation
mailbox-drain policy
checkpoint recovery
transport shutdown policy

The Common Lisp supervisor executes direct actor and transport lifecycle operations.

The planned Prolog supervisor actor³⁹ may evaluate dependency and policy rules.

A domain becomes ready only when:

supervisor is ready
ingress is accepting work
required dispatchers are running
required local router pools are ready
required shared services resolve
required transports are ready
required dataset bindings are loaded

TODO Domain Registry

The runtime maintains a registry keyed by domain identifier:

:humint
:socmint
:sigint
:cyber
:bbp
:threat-intel

Registry entries include:

domain handle
supervisor reference
ingress reference
lifecycle state
readiness state
health state
capability set
actor-manifest identifier
dataset-manifest identifiers
dispatcher identifiers
subdomain identifiers
transport handles
process or node identity
generation

TODO Isolation Modes

One actor system with domain supervisors

Default mode.

Advantages:

one lifecycle root
direct local actor references
one component registry
shared services
lower duplicated runtime overhead
straightforward cross-domain orchestration

One actor system with domain and subdomain bulkheads

Default execution-isolation mode.

Use per-domain and per-subdomain dispatchers, bounded mailboxes, managed routers, and optional transport reactors.

Multiple actor systems in one process

Use only for:

test isolation
compatibility bridge
plugin lifecycle containment
isolated event stream or scheduler configuration
measured runtime requirement

This does not provide memory isolation.

Multiple processes

Use for:

process crash containment
privilege separation
memory limit
independent deployment
independent scaling
remote placement

Connect through hardened Sento remoting, ZeroMQ, or Star Router according to the route contract.

TODO Implementation Sequence

Implement SENTO-000 failure and termination core.
Implement Sento supervisor and component systems.
Implement per-domain dispatcher declarations.
Implement the domain-gserver handle and registry.
Implement the domains root supervisor.
Implement one domain supervisor with ingress, health, and lifecycle handling.
Implement managed local router pools.
Implement typed domain-event envelopes.
Add actor-manifest and dataset-manifest bindings.
Add all six domain supervisors with empty capability-specific child trees.
Implement the sento-zmq reactor and component-handle adapter.
Enable one domain ZeroMQ route as a prototype.
Add Sento-remoting and Star Router adapters behind the same handle protocol.
Benchmark local, remoting, ZeroMQ, and process-separated modes.
Add failure-injection and restart-policy tests.

TODO Validation Requirements

The implementation must demonstrate:

all six domain gservers start in one actor system
actor paths remain stable and domain-scoped
each domain has separate control and default dispatchers
domains can create subdomain dispatchers inside the same process
one domain can restart without stopping unrelated domains
one subdomain can restart without stopping sibling subdomains
shared services remain reachable through declared handles
a saturated domain data dispatcher does not starve its control dispatcher
a saturated domain does not starve unrelated domains
bounded mailboxes produce structured overload results
routee failure is detected and repaired by the pool manager
keyed work preserves affinity
cross-domain messages carry trace, dataset, and generation metadata
transport selection is hidden behind component handles
ZeroMQ sockets are never exposed to ordinary domain actors
ZeroMQ reactor restart rejects stale replies
ZeroMQ authentication maps peers to declared component capabilities
loss-tolerant event routes are explicitly marked
complete shutdown leaves no actor, dispatcher, timer, proxy, socket, reactor, remoting, or Star Router resource running

TODO Open Questions

Which domain receives the first ZeroMQ prototype route?
Which subdomains need their own reactor instead of sharing the domain reactor?
Which domain events are permitted on loss-tolerant XPUB/XSUB routes?
Which component routes require Sento remoting rather than ZeroMQ?
Which component handles need actor-protocol compatibility?
Which actor-manifest syntax declares dispatcher, subdomain, and transport trees?
Which lifecycle policies remain in Common Lisp and which are evaluated by Prolog?

Footnotes and Glossary

TODO Citations

SENTO-000 managed component runtime: SENTO-000 Managed Component Runtime
Sento runtime research: SENTO-000 Sento Runtime Analysis
ZeroMQ transport research: SENTO-000 ZeroMQ Transport Analysis
Sento documentation: https://mdbergmann.github.io/cl-gserver/index.html
ZeroMQ core engine: https://github.com/zeromq/libzmq
ZeroMQ socket API: https://libzmq.readthedocs.io/en/latest/zmq_socket.html
ZeroMQ Authentication Protocol: https://rfc.zeromq.org/spec/27/
CurveZMQ: https://rfc.zeromq.org/spec/26/

Footnotes:

StarIntel: The document-driven intelligence search and analysis platform being designed in this repository.

Gserver: A managed service composed from actors, dispatchers, routing, lifecycle state, and a stable entry point.

HUMINT: Human Intelligence. Information collected from human sources, interviews, contacts, reports, and related human-origin material.

⁴

SOCMINT: Social Media Intelligence. Information collected and analyzed from social-media platforms, accounts, posts, interactions, and related media.

⁵

SIGINT: Signals Intelligence. Information derived from signals, communications, electronic emissions, receivers, sensors, and decoded signal activity.

⁶

Cyber: Computer, network, service, software, vulnerability, incident, malware, and digital-infrastructure work.

⁷

BBP: Bug Bounty Program. A program where an organization authorizes testing of declared systems and accepts vulnerability reports under program rules.

⁸

Threat intelligence: Structured information about threats, indicators, tactics, campaigns, actors, infrastructure, and risk.

⁹

StarIntel document: A typed record following the StarIntel document specification, including content and metadata used for storage, search, routing, and analysis.

¹⁰

Actor manifest: A declarative file or data structure describing an actor component's capabilities, dependencies, dispatchers, routes, startup rules, and configuration.

¹¹

Dataset manifest: A declarative file or data structure describing a dataset, its storage, indexes, processing, actor bindings, and document flows.

¹²

Sento: The Common Lisp actor framework in the mdbergmann/cl-gserver repository and the generic extensions described by SENTO-000.

¹³

Actor system: The top-level runtime container that owns actor contexts, dispatchers, timers, and system resources.

¹⁴

Process: One operating-system instance of a running program with its own memory and threads.

¹⁵

Supervisor: An actor that starts, watches, restarts, and stops child actors or components according to declared policy.

¹⁶

Actor tree: A hierarchy where parent actor contexts own child actors and their child contexts.

¹⁷

Domain-gserver handle: A stable reference used to send work to a domain without exposing whether the domain is local or remote.

¹⁸

ZeroMQ: A brokerless messaging library providing asynchronous message sockets, routing patterns, and multiple transports.

¹⁹

Control dispatcher: A small worker pool reserved for lifecycle, supervision, routing control, health, and shutdown messages.

²⁰

Domain dispatcher: A worker pool owned by one intelligence domain for normal actor message processing.

²¹

Subdomain: A named workload or organizational area inside one domain, such as decoding inside SIGINT or media processing inside SOCMINT.

²²

Ingress actor: The declared entry actor through which other components submit work to a domain.

²³

Router pool: A managed set of equivalent worker actors selected by a router.

²⁴

Event bus: A publish-and-subscribe path used to distribute typed events to interested components.

²⁵

ZeroMQ reactor: A supervised component with a dedicated thread that owns ZeroMQ sockets and bridges their messages to Sento actors.

²⁶

Telemetry: Runtime measurements and events used to observe system behavior.

²⁷

Remoting: Sending actor messages between separate Sento actor systems over a network connection.

²⁸

Star Router: StarIntel's client-facing and application-level cross-process routing layer.

²⁹

Opaque: Intentionally hiding internal representation so callers use only the declared public operations.

³⁰

TTP: Tactic, Technique, and Procedure. A description of how an actor plans, performs, and operationalizes activity.

³¹

CouchDB: A document-oriented database that stores JSON documents and exposes an HTTP interface.

³²

OCR: Optical Character Recognition. Software that converts text visible in images or scans into machine-readable text.

³³

Embedding: A numeric vector representing content so semantically related items can be compared or retrieved.

³⁴

LLM: Large Language Model. A machine-learning model that processes or generates language and related structured output.

³⁵

Homogeneous: Equivalent enough that any worker in the group can safely process the same kind of message.

³⁶

Affinity: Keeping related messages assigned to the same worker so sequential state remains consistent.

³⁷

CURVE: ZeroMQ's public-key encryption and authentication mechanism based on CurveZMQ.

³⁸

ZAP: ZeroMQ Authentication Protocol. The in-process protocol used to approve or reject connecting ZeroMQ peers.

³⁹

Prolog supervisor actor: A planned actor that uses Prolog rules to evaluate component dependencies, scheduling, and lifecycle policy.