How it is built
ERIS3 is HitCorp’s current operational brain: a small, stable core plus bolt-on modules that each do one job. Modules are enabled only when the operator adds them to configuration; a disabled or broken module must not take down the core.
One brain, one public API path
Production traffic uses a single ERIS3 instance. The HitCorp website and PHP portal call the brain through the existing portal bridge (server-to-server trust), not from the browser directly. When the brain is offline, portal login and static pages can still work; ERIS chat and tools show an honest offline or degraded state.
Message path
External channels (website, Discord, Second Life interfaces, and others) normalize inbound traffic into one dispatch path. A module either handles the message and returns a response, or declines so the next handler can run—without stacked “guess layers” competing for the same message.
What lives in the core
- Configuration, database access, identity and access context
- Thin dispatch (message in, response out)
- LLM and agent facade, audit, health
- Thin channel I/O (connect, send, one inbound handler per channel)
Features such as group operations, memos, intake, dispatch radio, memory indexing, and assistant orchestration are modules under modules/, not extra core code.
Operator documentation
Restart procedures, environment layout, tunnel details, and module ownership live in the operator’s ERIS3 repository (docs/ops/, module READMEs). This manual stays at user-visible behavior; it does not replace those runbooks.