05DOCS

HORRIS / DOCS

DOCUMENT THE MACHINE.
INSPECT EVERY BOUNDARY.

The Horris documentation surface is organized around architecture, execution safety, network capability and operator workflows rather than a single scrolling product page.

LAUNCH TERMINAL →BACK HOME
01ARCHITECTURE→

Start with the protocol lifecycle.

Understand how intent becomes simulation, risk analysis, policy authorization and finally an execution-eligible transaction.

  • /protocol
  • AUTHORITY MODEL
  • LIFECYCLE
02ENGINE→

Inspect AI and deterministic boundaries.

Review how the Groq provider is isolated from execution authority, how proposals are validated and how preflight gates remain fail-closed.

  • /engine
  • AI BOUNDARY
  • PREFLIGHT
03NETWORK→

Verify contracts and capability by chain.

Use the network section to distinguish Celo Sepolia testnet proof, Mento stable routing and UpDown mainnet-only capabilities.

  • /network
  • CELO
  • DEPLOYMENT EVIDENCE
04OPERATIONS→

Use the control terminal for live work.

The terminal contains the actual wallet, stable intent, AI proposal, perp risk, monitoring, vault and execution-history interfaces.

  • /terminal
  • WALLET
  • LIVE STATE
05RESEARCH→

Understand why the safety model exists.

Research notes frame Horris around bounded autonomy, explainability, protection and recovery rather than generic AI automation.

  • /research
  • RISK
  • RECOVERY
STAGETESTNET
AUDIT STATUSUNAUDITED
MAINNET BROADCASTLOCKED WHERE UNVERIFIED
SOURCEGITHUB / mushee-io/Horris
// HORRIS / SYSTEM PRINCIPLE

Documentation should tell the operator what is real, what is simulated and what is blocked.

Horris documentation keeps capability claims narrow and testable. Unknown or unavailable state is displayed as unavailable rather than filled with placeholder success.

[ OPEN CONTROL TERMINAL ]