From Indicators to Intent: When Trading Libraries Grow Up

Most trading libraries begin innocently.

Someone wants an EMA. Then RSI. Then ATR. Then Bollinger Bands, pivots, candlestick patterns, rolling quantiles, regime flags, entry rules, exit rules, position sizing, stop-loss templates, and one mysterious helper called generate_alpha_final_v7() that nobody dares delete because it once worked during a bull market.

This is how indicator libraries become strategy junk drawers.

The February refactor of strategyr is interesting because it moves in the opposite direction. It does not try to impress users by becoming a larger box of trading toys. It tries to become more legible: a library that separates market description, predictive structure, position intent, and executable order logic. That sounds dry, which is usually a sign that something useful is happening.

The useful part is not that strategyr calculates indicators. TA-Lib has been doing that kind of thing for years, with a long catalog of technical-analysis functions from ATR and RSI to candlestick pattern recognition.¹ The useful part is architectural: the refactor asks what each object is allowed to mean.

That question matters because trading systems fail less often from missing indicators than from confused boundaries. A feature becomes a signal. A signal becomes a trade. A trade becomes an order. Then, when the backtest looks suspiciously heroic, nobody knows which layer smuggled in the assumption. Very professional. Very expensive.

The old problem was not indicator scarcity

The ordinary technical-analysis workflow is built around recognizable tools: moving averages, volatility measures, oscillators, bands, and event markers. These are convenient because they compress price history into readable objects. They are dangerous for the same reason.

An EMA does not say “go long.” ATR does not say “use 10x leverage.” A Bollinger Band touch does not say “fade the move with a fixed stop.” Those decisions may be reasonable inside a strategy, but they are not contained in the indicator itself. The problem begins when software architecture pretends otherwise.

The old version of strategyr carried this tension. It included indicators, feature generators, signal logic, position builders, and order-level helpers in a single conceptual neighborhood. That made experimentation easy. It also made interpretation harder.

A trader could call one function and get something close to an action. Convenient, yes. But convenience is not the same as accountability. In a research pipeline, the cost of convenience is often paid later, when a strategy must be debugged, explained, scaled, or migrated into a live execution system.

The refactor therefore makes a simple but important correction:

features describe; signals express intent; engines execute.

That line is not decorative. It is the operating principle.

strategyr is becoming an intent layer, not a trading robot

A mature trading library should not need to do everything. In fact, it should become suspicious of itself the moment it tries.

The refactored strategyr is best understood as a feature-and-intent layer. It prepares market representations and standardized position intentions. It should not pretend to be a broker, a portfolio engine, a risk committee, and a strategy guru wearing four hats badly.

This places it somewhere between classic indicator libraries and full-stack quantitative platforms. Qlib, for example, was designed as an AI-oriented quantitative investment platform covering the broader workflow from data infrastructure to modeling and investment research.² FinRL similarly frames trading as a pipeline involving market environments, agents, reward functions, constraints, and backtesting.³ Those projects are full-stack by design.

strategyr is doing something narrower. That is not a weakness. It is a scope decision.

This table is the refactor in miniature. It replaces “one more helpful function” with a sharper contract.

The likely misconception is that deleting strategy helpers makes the package less capable. It does not. It makes the package less ambiguous. A narrower public API can improve the quality of downstream systems because it reduces the number of places where intent can enter unnoticed.

That is boring in exactly the right way.

The important distinction is between prediction and action

The refactor’s most valuable conceptual move is the distinction between predictive objects and trading actions.

A volatility estimate can be useful without being a strategy. A trend-age measure can say something about persistence without saying whether to enter now. A cross event can mark a regime transition without specifying position size. These objects become more useful when they remain honest about their role.

Consider ATR. A traditional ATR calculation describes recent range behavior. In the refactor, volatility features increasingly move toward log-return space and half-life parameterization. The point is not to make the formula look more sophisticated. The point is to make the feature more comparable and less dependent on arbitrary window folklore.

A lookback window says: “Use the last 14 bars because that is what traders are used to.”

A half-life says: “Let older information decay at a defined rate.”

That is a different kind of promise.

The half-life framing matters more when features are reused across assets, bar sizes, or market regimes. A fixed window can behave differently when moving from 15-minute ETH candles to daily equity data. Log-return volatility and decay-based weighting do not eliminate this problem, but they make the design assumption visible. Visible assumptions are easier to test. Invisible ones become folklore with a function name.

Why fewer exports can improve research quality

Software users often treat a large API as a sign of maturity. In trading systems, a large API is often a museum of unresolved decisions.

The refactor removes or demotes strategy-level helpers that do not belong in the public surface: ladder builders, breakout order generators, composite position logic, and other machinery that mixes research intent with execution design. This matters because public functions become habits. Once a helper is exported, users build workflows around it. Once workflows depend on it, the package starts carrying old assumptions like technical debt in a tailored suit.

A cleaner API changes the research process in three ways.

First, it makes tests easier to interpret. If a function produces a feature, then the test can ask whether the feature is calculated correctly. If a function produces a position, then the test can ask whether the position reflects the intended signal rule. If a function produces an order, then the test must also care about execution rules, rounding, broker constraints, and risk parameters. Those should not be casually mixed.

Second, it makes comparison fairer. Two strategies can share the same feature layer while using different position logic. Or they can share the same position signals while being tested under different execution engines. This is how a research library supports serious experimentation instead of producing one-off backtest souvenirs.

Third, it makes failures easier to locate. When live performance diverges from backtest performance, a layered system can ask: was the feature unstable, was the signal overfit, was the portfolio engine wrong, or was execution unrealistic? A monolithic helper can only shrug.

And yes, shrugging is not a risk-management framework.

Performance choices are part of the architecture

The refactor’s use of data.table and Rcpp is not just a technical preference. It reinforces the package boundary.

data.table is built around fast, memory-efficient data manipulation and reference semantics, including update-by-reference behavior that avoids unnecessary copying in common workflows.⁴ For large bar datasets and repeated feature generation, that matters. Trading research is not always “big data” in the fashionable sense, but it is often wide, repeated, and annoyingly easy to copy into memory three times before lunch.

Rcpp serves a different role. It allows computationally intensive kernels to be written in C++ while remaining callable from R; the Rcpp literature emphasizes this bridge between R objects and C++ implementation.⁵ That division fits the package philosophy: keep orchestration readable in R, move iteration-heavy calculations into deterministic kernels when needed.

This is not an argument that every trading library should worship speed. Speed without structure simply lets users produce bad backtests faster, which is a generous public service to future regret. The point is that performance should support a clear computational contract.

For strategyr, the contract looks like this:

The business implication is not “Rcpp makes it fast.” That is the brochure version. The real implication is that a research stack becomes cheaper to diagnose. When a system has clean layers, engineering time is spent improving the weak layer, not arguing about which helper function secretly did what.

What the refactor directly shows

The refactor directly shows a package moving from breadth toward discipline. It clarifies the public API. It separates feature generation from position intent. It pushes order-level logic out of the core library. It favors parameterizations that make assumptions more explicit. It aligns the implementation stack with repeated, high-volume time-series computation.

That is the direct evidence.

It does not directly prove that any specific strategy will perform better. It does not prove that half-life features dominate fixed-window features. It does not prove that a narrower API will automatically make users more careful. Users are creative. They can misuse anything. Give them a clean abstraction and enough leverage, and they will still find a cliff.

But the refactor improves the conditions under which strategy research can be interpreted.

That is a more modest claim, and therefore a more useful one.

What Cognaptus infers for business use

For trading teams, fintech builders, or AI-assisted research workflows, the business value of this kind of refactor is not cosmetic cleanliness. It is operational leverage.

A layered library allows different people—or different agents—to work on different parts of the system without corrupting each other’s assumptions. A feature engineer can improve volatility features. A strategy researcher can test signal rules. A portfolio engine can decide capital allocation. An execution module can handle orders. A monitoring agent can compare expected and realized behavior.

This matters even more when AI agents enter the workflow. An LLM-assisted trading system should not be allowed to freely rewrite the meaning of a signal, generate orders, change leverage, and explain the result in one breath. That is not autonomy. That is a compliance headache wearing a chatbot interface.

A cleaner package boundary gives AI agents less room to improvise in the wrong layer. It lets the system say:

• generate features here;
• propose position intent there;
• send orders only through this engine;
• evaluate performance using that module;
• log every boundary crossing.

That is where the “intent” in the title becomes practical. Intent is not merely a philosophical word. It is a software object that should be inspectable before money touches the market.

Where the boundary still matters

The refactor does not remove the hard problems. It relocates them.

A feature-and-intent library still depends on good data. It still needs careful handling of missing bars, exchange-specific timestamps, corporate actions where relevant, liquidity constraints, and transaction costs. It still needs evaluation systems that avoid look-ahead bias and survivorship bias. It still needs live execution modules that handle partial fills, rejected orders, fee schedules, slippage, and API failures.

Those problems should not be hidden inside strategyr. They belong in adjacent layers.

The main boundary is this: strategyr can make trading research more legible, but it cannot make a trading idea true. A better architecture can expose weak assumptions earlier. It cannot rescue a weak assumption from being weak.

This distinction matters for ROI. The return on this refactor is not “higher Sharpe by package design.” That would be adorable. The return is lower debugging cost, clearer experiment comparison, safer AI orchestration, and a cleaner path from research code to production systems.

The appendix is the architecture

The quiet achievement of the strategyr refactor is that it treats software structure as part of trading methodology.

That sounds obvious until one looks at how many trading libraries quietly collapse indicators, signals, orders, and execution into the same conceptual bucket. The result is usually a tool that is pleasant for demos and painful for serious research.

strategyr is growing up by becoming less eager. It does not need to be a strategy cookbook. It does not need to be a broker interface. It does not need to generate heroic orders from every indicator twitch.

It needs to produce reliable market features and clear expressions of intent.

In trading software, that is not minimalism. It is risk control.

Cognaptus: Automate the Present, Incubate the Future.