System Architecture & Pipeline Blueprint
A structural description of how these products are compiled and delivered. It covers boundaries, stages and stated dependencies. It does not include source, algorithms or implementation detail — those ship inside the archive a buyer receives.
Native binaries, no runtime framework
Each product compiles to a single native executable. There is no interpreter, no virtual machine and no web framework in the delivered artefact — the thing a buyer runs is the compiled program. Builds can be configured to link the C++ runtime statically, which is how a binary runs on a machine with no toolchain installed on it.
This is deliberately not a zero-dependency claim. The engines link a small, named set of third-party libraries, declared through vcpkg and listed in full below. Each archive carries the attribution notices those libraries require.
What is linked, and what is optional
- OpenSSL (Apache 2.0) — HTTPS support in the shared agent. Optional and detected at configure time: built without it the agent still compiles and runs, plain HTTP works, and HTTPS is refused at runtime with an explicit message rather than failing quietly.
- uSockets / uWebSockets, zlib — the live feed path in the trading engine.
- poppler — optional document parsing in the retrieval engine, behind a build flag.
Everything else in the archives is original work. The third-party list and its licence obligations travel with every archive at every price tier, including the cheapest, because attribution is not a premium feature.
What each product on sale is built from
Counted from the source each archive is built from when this page was requested: code files only (.cpp, .hpp, .h), tests and examples excluded, lines without blanks and comments. For a product built on the shared agent core, the figures are that product's own module; the core (scheduler, journal, HTTP, JSON) ships in the archive on top of it and is not counted here. The design lines describe that source and nothing else; which parts a given archive contains follows its build tier.
- C++20, one native executable
- Durable task queue: every accepted task is appended to a journal on disk and again on each state change
- After a crash or restart, anything not finished is replayed from that journal
- The journal is flushed to the operating system, not fsync'd: a power cut can lose the last few records
- Worker threads: one per hardware thread by default, or the count set in config/agent.json
- Failed tasks are retried with a growing delay up to the retry budget in the config, then parked as dead instead of looping
- Queue depth is capped, so a runaway producer is refused rather than exhausting memory
- C++20, one native executable
- Market data crosses threads through a lock-free single-producer, single-consumer ring
- Fee-aware: a signal is emitted only when the edge still clears the configured minimum after each venue's fees
- Replay mode runs recorded ticks through the same code path as live
- Pro build and above: a risk layer between signal and order, where every rejection carries a reason, and simulated execution
- Enterprise build: statistical z-score signal and pinning of the hot thread to one CPU core (--pin)
- C++20, one native executable
- Durable task queue: every accepted task is appended to a journal on disk and again on each state change
- After a crash or restart, anything not finished is replayed from that journal
- The journal is flushed to the operating system, not fsync'd: a power cut can lose the last few records
- Worker threads: one per hardware thread by default, or the count set in config/agent.json
- Failed tasks are retried with a growing delay up to the retry budget in the config, then parked as dead instead of looping
- Queue depth is capped, so a runaway producer is refused rather than exhausting memory
- One native executable built from the source in the archive
- C++20, one native executable
- Durable task queue: every accepted task is appended to a journal on disk and again on each state change
- After a crash or restart, anything not finished is replayed from that journal
- The journal is flushed to the operating system, not fsync'd: a power cut can lose the last few records
- Worker threads: one per hardware thread by default, or the count set in config/agent.json
- Failed tasks are retried with a growing delay up to the retry budget in the config, then parked as dead instead of looping
- Queue depth is capped, so a runaway producer is refused rather than exhausting memory
Wrappers / Bindings (Not Typical API Wrappers)
A typical “API wrapper” is a thin client around someone else's remote HTTP service: the work happens on their servers and stops when the service does. Nothing here is that. Every wrapper below calls the compiled C++ engine directly, on the buyer's own machine, with no BotStudio9 server in the path.
- Native runner — the compiled program itself (bin/bot or bot.exe), with launchers that open a terminal in the right folder. Commands in, results out, no service to sign in to.
- In-process WebAssembly binding — where a product ships a workspace, the same C++ is compiled to WebAssembly and called inside the page through three exported functions (bs9_alloc, bs9_free, bs9_call): a JSON request in, a JSON reply out. It runs from a file on disk and makes no network request.
- The source — the C++ the binaries were compiled from, with the build files, so the engine can be rebuilt or linked into the buyer's own program.
What an archive contains, by tier: the C++ source, prebuilt binaries where the tier includes them, documentation, and the runners above. Language bindings for Python or Node are not shipped today; from those languages the engine is driven through the runner's command line and its JSON output.
One listing, one configured build
The product name chosen at publish is written into a generated build-identity file, compiled into the binary, and carried through the archive's documentation and licence. The binary reports the name it was sold under rather than an internal codename.
The shared agent core carries every category's module. A build compiles exactly one — the category purchased. The others are removed from the archive rather than shipped and disabled, so a buyer never receives the source of products they did not buy.
Lower price tiers ship their own entry point and a build file whose source list matches what is actually in the archive. They are not the full program with files deleted — that produces something that fails before it reaches the compiler. Every tier configures and builds.
Worker count, retry policy, queue depth, journal persistence and log level are written into the delivered configuration. Two tiers of the same product behave observably differently when run, rather than differing only on the product page.
The publish path refuses any category that has no real source behind it. A missing implementation is treated as a missing product, not a formatting problem, so a listing cannot advertise something the factory cannot build.
Local-first, with an opt-in cloud path
The engines run on the operator's own machine and keep their working data there. The retrieval engine in particular is built to index and answer from local files without contacting a remote service, which is what makes it usable on networks where documents are not allowed to leave.
Operational telemetry is off by default and requires two separate decisions to leave a machine: switching it on, and explicitly uploading. Until then it is a local file. Nothing about the sender — no address, no user agent — is recorded when a batch is received.
The published data profile states the collection basis in writing, including that the current consent does not permit transferring those records to third parties. That constraint is why the public performance page reports build-time benchmarks and not operator data.
From purchase to a file on disk
Entitlement is established from the payment processor on the server. Nothing about access is decided by the browser.
Access is issued as a signed grant bound to one purchase and one product, valid for minutes rather than indefinitely. It cannot be re-pointed at a different product.
The download path re-derives entitlement from the database each time rather than trusting what the grant asserts. A refund therefore revokes access immediately, without anything needing to expire first.
Product files are held in private storage and reached through a short-lived signed URL generated per request. The files are never publicly addressable.
An allowlist, not a filter
The telemetry intake accepts a fixed, declared shape. A record carrying an unknown field, free text, or a value outside the permitted character set is rejected as a whole rather than cleaned up and stored. The engines never produce such a record, so anything of that shape did not come from them.
Delivery is at-least-once from the engine and exactly-once at rest: a batch resent after a timeout is stored once, keyed on the event identifier. Oversized batches are refused outright, and storage failures answer with a retryable status so the sender keeps the data rather than dropping it.
Shipped binary sizes
Windows build sizes, read from disk when this page was requested. These are on-disk artefact sizes, not memory usage — no runtime memory figure is published here because none has been measured under a stated workload.
Measured timings for these engines: build-time benchmarks.