SPEC: KapitaalBot Runtime

This page is the canonical public technical specification of KapitaalBot. It focuses on system behavior, operational architecture, and latency requirements. Source code, sensitive tuning values, and private account details remain intentionally out of scope.

1) Technology stack

ComponentSpecPublic note
LanguageRustCore runtime and execution logic
DatabasesPostgreSQLRole-separated data paths (ingest / decision / research where applicable)
OS / RuntimeLinux (Ubuntu class)Service-oriented runtime on dedicated host(s)
Process controlsystemd servicesDeterministic startup/restart and health supervision
Exchange integrationWebSocket-firstLive market + execution channels, snapshot/export driven website
Observability exportRead-model JSON snapshotsPublic and tiered observability without direct DB exposure

2) Runtime / architecture specs

KapitaalBot operates as a timing-aware multistrategy route-selection engine with live route-state, regime routing, position context, execution choke, and feedback-driven explainability.

spec.runtime.diagram.titlespec.runtime.diagram.caption

spec.runtime.diagram.desc

3) Latency specification

The table below explicitly distinguishes latency targets, observed ranges, and delayed/background paths.

Tier / PathTarget latencyObserved latencyWhy it matters
Hot path (ranking → choke → submit)Sub-second classRuntime-dependent, monitored continuouslyDirect impact on execution viability and stale-decision risk
Warm path (route-state refresh, explainability updates)Seconds classLow-seconds class under normal loadControls decision freshness and interpretability
Tier 1 public observabilityDelayed by designDelayed snapshotsPrevents real-time strategy leakage while preserving transparency
Tier 2 analytical observabilityNear-operational delaySnapshot cadence dependentSupports deep diagnostics without exposing account-sensitive internals
Tier 3/admin and private operator pathsOperationally immediateInternal-onlyUsed for sensitive account/runtime control and forensic analysis

4) Public safety boundary

  • YES: functional behavior, architecture, high-level decision logic, outcomes, explainability.
  • NO: source code, exact private thresholds, sensitive allocator/sizing details, account-specific data.