First Steps: Understand the Barfinex Service Boundaries

Orientation to the five Barfinex services, their responsibilities, private runtime flow, and the safest order for learning the platform before deployment.

Barfinex is not a trading bot or a strategy toolkit. It is a modular trading-infrastructure stack that separates market data, strategy candidates, deterministic policy admission, risk authority, and operational observation.

The Five Services

Each service has a single, well-defined responsibility:

Component	Responsibility
Provider	Market data gateway. Ingests, normalizes, and serves exchange and account evidence to authorized runtime consumers.
Detector	Strategy runtime. Evaluates typed rule configurations against market data and emits scored candidates.
Advisor	Small deterministic policy stage. Validates immutable Detector candidates and signed Provider evidence, then records `ADMIT` or `REJECT`.
Inspector	Final execution and risk authority. Resolves current account/portfolio truth, computes final size, applies risk policy, and executes approved intents through Provider.
Studio	Operations terminal. Visualizes candidate lifecycles, policy decisions, risk state, and operational context.

How They Connect In A Private Runtime

Exchange
    │
    ▼
Provider ──────────────────────────────────────────▶ Studio
    │                                               (authenticated runtime view)
    ├──▶ Detector ──▶ Advisor ──▶ Inspector ──▶ Provider ──▶ venue
    │   (candidate)   (policy)     (risk + execution authority)   (broker boundary / confirmed outcome)
    │
    └──▶ internal eventing

Provider is the authenticated gateway for the private runtime. The public website does not connect to that full operator graph; it exposes only public-safe documentation, catalogs, and sanitized market-intelligence projections.

How Data Flows

Provider receives and normalizes venue observations.
Detector evaluates configured strategy rules and produces an immutable candidate with strategy attribution.
Advisor validates the candidate and required evidence, then records deterministic ADMIT or REJECT.
Inspector is the final execution and risk authority: it resolves current truth, sizes or blocks the intent, and owns the governed order lifecycle.
Inspector executes through Provider. Provider remains the sole broker/exchange boundary; venue-confirmed account, order, and fill evidence remains the operational source of truth.
Studio presents the authorized runtime state to operators.

Before You Install

Learn the responsibility boundaries before configuring credentials.
Keep exchange credentials and operator-only controls inside the private deployment.
Treat public examples as orientation, not as a substitute for the current deployment configuration.
Strategies are typed configurations/code and should be versioned and reviewed.
Risk rules should remain independently reviewable from strategy logic.

Recommended learning path

Architecture — understand ownership and boundaries.
Provider — understand the market-data gateway.
Detector — understand strategy candidates.
Advisor — understand deterministic admission.
Inspector — understand final execution, sizing, and risk authority.
Studio — understand runtime observation.

For a research-first view of the platform, see Trading Research Platform.