VOLYAR X logo VOLYAR X

Technology

A documentation-grounded overview of how VOLYAR X is architected — what is implemented and live, what is implemented but isolated, and what is a documented future direction only.

Platform Overview

VOLYAR X is the central intelligence platform being built around VOLYAR Scanner, a live, production sports betting line-movement scanner that is currently in active use. The scanner detects meaningful movement in betting markets and classifies it into structured signals for a human operator. Around this operational core, VOLYAR X is developing an analytics and decision-support layer whose documented purpose is to help a person make better decisions under uncertainty — it is not designed as an autonomous trading agent or a stake-sizing system.

The project is currently in a stabilization phase: the priority is reliability, observability, and regression discipline in the systems already running live, rather than new feature expansion. The wider product direction — VOLYAR X today, a future domain-general VOLYAR OS, and a coordinating intelligence layer called TESKA — is documented as a roadmap, not as software that exists in full today. Section 9 below draws the line explicitly between what runs in production and what is documented direction only.

Core Principles

These are engineering principles stated in the project's own architecture documentation, not aspirational marketing language.

Evidence before confidence

Confidence in an output must be proportional to the evidence behind it. When evidence is incomplete, certainty is explicitly downgraded rather than assumed.

Explainability by design

Material decisions record their inputs, evidence, rules applied, confidence, risk, and outcome in a form that can be inspected after the fact.

Modularity without fragmentation

Modularity means clear ownership and replaceability of components — not an unbounded number of disconnected services.

Provider independence

External data providers and infrastructure vendors are accessed through replaceable abstraction layers, never wired directly into decision logic.

Testability by design

Time, randomness, network access, and provider behavior are built to be injectable or simulated, so behavior can be tested deterministically.

Replay validation

A deterministic replay harness feeds historical or synthetic market data through the real scanner decision code offline, producing an inspectable record of every decision it would have made.

High-Level Architecture

A layered view of documented components. Layers lower in the diagram are increasingly isolated from the live production path — the last layer is a documented future direction and does not exist as software yet.

Implemented Planned direction — not implemented
VOLYAR X layered architecture Five stacked layers connected top to bottom: VOLYAR Scanner operational core; the isolated intelligence and analytics layer; the advisory Decision Core pipeline with five stages (Context, Evidence, Safety, Explanation, Engine); the TESKA foundation modules; a replay and validation harness; and, as a dashed planned-direction box, the future VOLYAR OS. VOLYAR Scanner — Operational Core Provider abstraction · Signal detection & alerting · Desktop UI · Remote Panel Implemented — live, in production Intelligence & Analytics Layer Market memory · Historical baselines · Execution & CLV intelligence Implemented — isolated, read-only audit layer Decision Core — Advisory Pipeline Implemented — advisory only, not wired into any runtime path Context Evidence intake Evidence Assessment Safety Gate checks Explanation Human-readable Engine Orchestration TESKA — Foundation Modules Governance & safety evaluation · Reasoning & deliberation · Decision provenance & memory · Post-decision review Implemented — isolated and unwired, no production authority Replay & Validation Harness Implemented — deterministic offline replay of real scanner decision code VOLYAR OS Planned direction — future domain-general decision operating system, not implemented

Data Sources

VOLYAR Scanner is built around a provider-abstraction philosophy rather than a dependency on any single external data source. External providers are accessed only through an internal abstraction layer, and specific vendor names and integration details are treated as implementation detail rather than public architecture — they are intentionally omitted from this page.

What is documented is the design intent: the scanner is built to run against multiple interchangeable data providers, with automatic fallback routing if a source becomes unavailable, so no single vendor is a hard dependency for the system to keep operating.

Connector Layer

Two documented abstraction mechanisms sit between external data and decision logic:

Normalization contract (production)

Incoming provider data is converted into a canonical set of internal data types before it reaches signal or decision logic. No provider-specific handling exists past that boundary — the rest of the system only ever operates on normalized data.

Plugin-style connector framework (foundation layer)

A separate, isolated connector framework defines a common interface that any new data connector implements and registers. Adding a source is documented as: implement the interface, register it, and nothing else in the system changes. Individual connector failures are isolated from one another by design. This framework exists as an isolated foundation module and is not wired into the production scanner.

Intelligence Layer

Alongside the live scanner, an isolated, read-only analytics layer processes historical and runtime data to build additional context. Documented components include:

This layer is documented as read-only with respect to production runtime data — it reads from existing records and writes only to its own dedicated storage, without modifying the scanner's live operational files.

TESKA

TESKA's documented mission is "to help the Founder understand, verify, and improve VOLYAR X — never to run it." It is explicitly bounded to four functions: understand, verify, explain, and recommend. It is documented as never deciding, never autonomous, and never holding a write path into any production system.

TESKA does not exist as a complete, wired production system today. What has been implemented are isolated, deterministic foundation modules — disconnected from the live scanner and from each other's runtime effects — covering areas such as:

Each of these modules is documented as unwired: not imported by the scanner, the API layers, or any production decision path. No production authority exists through TESKA today.

Decision Pipeline

The advisory Decision Core assembles a structured decision record through a fixed, documented sequence of stages. No thresholds, scoring formulas, or internal decision logic are disclosed here — only the documented stage names and their high-level purpose.

  1. ContextAssembles the evidence and correlated inputs a decision will be based on.
  2. EvidenceAssesses confidence, quality, risk, and uncertainty from that context.
  3. SafetyApplies gate checks and determines readiness and any blockers.
  4. ExplanationBuilds a human-readable account of the reasoning and evidence involved.
  5. EngineMechanically assembles the prior stages' outputs into one final, inspectable decision record — it does not compute any label, gate outcome, or explanation text itself.

This pipeline is documented as advisory-only: it exists in code, but nothing in the live scanner or its scan loop currently calls it.

Current Capabilities

A strict separation, as documented in the project's own status records — nothing below is blended between the two columns.

Implemented

  • VOLYAR Scanner — live, in active production use
  • Desktop UI and Remote Panel operator interfaces
  • Provider-abstraction and normalization layer
  • Isolated analytics & intelligence audit layer
  • Advisory Decision Core pipeline (not wired into runtime)
  • TESKA foundation modules (isolated, unwired)
  • Deterministic replay & validation harness

Documented / Planned Direction

  • VOLYAR OS — future domain-general decision operating system
  • TESKA as a fully wired, coordinating intelligence layer
  • Runtime integration of the Decision Core pipeline
  • Deeper AI autonomy — explicitly frozen pending Founder approval
  • Monetization, subscriptions, and public scanner distribution — explicitly frozen

Future Expansion — Planned Direction

Everything in this section is a documented direction, not a built feature. No item here should be read as available or in progress unless it also appears in the Implemented column above.

Planned direction

VOLYAR X is documented as intended to grow along a scanner → platform → operating-system path. VOLYAR OS is described as the eventual, domain-general decision operating system that the platform grows into over time — it does not exist as software today. Similarly, TESKA's isolated foundation modules are documented as a starting point for a future coordinating intelligence layer, with each further stage of integration subject to explicit Founder approval before it is built. Several categories of change — deeper AI autonomy, monetization, and public distribution among them — are explicitly documented as frozen until the Founder unfreezes them.

Technology Stack

Languages, frameworks, and tooling confirmed in the repository's own dependency manifests.

Languages & desktop runtime

Backend services

Data & analytics

Quality & testing

Design Principles

Engineering discipline stated directly in the project's own development rules:

Stability first

Every change must leave the live system in a working state; changes that could affect signal delivery or logging require explicit review.

Reversibility

Edits are made as complete, unambiguous replacements — never left in a partially applied state — and nothing is silently deleted or renamed.

Backup before modify

Any change to a live production file requires a stated backup step, a restore path, and a defined failure symptom, before the change is made.

Atomic writes

Runtime-adjacent data files are written to a temporary file and swapped into place atomically, avoiding partially written state.

Consistent data encoding

All files written by any module use UTF-8 encoding explicitly, avoiding a class of encoding bugs the project has previously encountered.

Runtime data is protected

Live operational data is treated as protected: direct modification is disallowed, and schema changes go through a single, controlled migration path.