The reasonable response to any trading platform is skepticism. The platform claims to execute strategies systematically and transparently — but what does that actually mean, mechanically? Where does your money sit? What does the platform have access to? What happens if something breaks at the wrong moment? This article answers those questions directly, without marketing language. If you evaluate Oyamori and conclude it is not right for your situation, that is a correct outcome. The goal here is clarity, not conversion.

What Oyamori Is, Precisely

Oyamori is an execution and strategy management platform. It does three things: provides a catalog of validated systematic trading edges, handles the execution infrastructure that connects to your brokerage and places orders, and surfaces performance data — per-strategy P&L, signal history, execution quality metrics.

It does not predict markets. It does not guarantee returns. It does not manage your money — it executes the strategy you configure, using the risk parameters you set. Your account remains your account. Oyamori is a layer on top of your brokerage, not a replacement for it. The distinction matters for custody: your assets are held by your brokerage, not by Oyamori. Disconnecting from Oyamori leaves your positions exactly where they are.

The Edge Catalog

Each entry in the Oyamori catalog represents a documented market inefficiency — a repeatable condition where the statistical odds tilt in the trader's favor. The documentation for each edge includes: the mechanism (what inefficiency it exploits and why that inefficiency persists), the regime conditions (market environments where the edge performs and where it does not), the historical performance parameters (win rate range, average hold time, expected drawdown range), and the configurable parameters the trader sets (position sizing, entry and exit thresholds, stop conditions).

The catalog is not a menu of guaranteed strategies. It is a menu of validated hypotheses — each one tested, explained, and made executable. The validation includes out-of-sample testing, not fitting to a single historical window. You select the edges that match your risk tolerance and configure them. The selection and configuration are yours; the execution infrastructure is Oyamori's.

The Alpaca Integration

Oyamori connects to your Alpaca brokerage account via their API. The integration uses Alpaca's OAuth flow — Oyamori never stores your brokerage credentials directly. At the end of the authorization flow, Oyamori receives a scoped API token with read and write access to trading operations: place orders, read positions, read account status.

The scope does not include fund transfers or account settings changes. Position limits, buying power constraints, and settlement rules all enforce at the Alpaca layer. Oyamori operates within whatever constraints your Alpaca account has configured. If your Alpaca account has pattern day trader restrictions, those restrictions apply to Oyamori-placed orders exactly as they would to manually placed orders. Revoking the OAuth token at any point immediately terminates Oyamori's access without requiring any action on the Oyamori side.

How a Trade Executes

A single trade follows this sequence:

Signal generation: the strategy evaluates market data on its configured schedule — at market open, on an intraday interval, or on an event trigger. The evaluation runs the strategy's logic against current data and produces a signal: enter, exit, or no action.

Sentiment filter (if configured): the signal passes through the current Newsvibe sentiment score for the ticker. If sentiment is below the configured threshold or contradicts the signal direction, the signal is suppressed and no order is placed. The suppression is logged with the sentiment score at that moment.

Risk check: position size is calculated against available buying power and the strategy's configured maximum position limit. If the risk check fails — buying power insufficient, position limit already reached — the order is not placed and the event is logged with the specific constraint that blocked it.

Order placement: a market or limit order is submitted to Alpaca via API. The order type and parameters are determined by the strategy's configuration.

Fill confirmation: Alpaca returns the fill price and quantity. Position state is updated. The fill details are logged against the signal that triggered the order, including the difference between expected and actual fill price.

Ongoing monitoring: P&L is tracked in real time against the expected behavior range from the strategy's historical parameters. Deviations outside the expected range trigger alerts.

What Happens When Something Goes Wrong

Three failure scenarios, and what the platform does in each:

API timeout: an order is submitted but not confirmed within the timeout window. The order is treated as failed; no position is assumed. An alert fires. The event is logged with full request and response data for review. The conservative assumption — no position taken — prevents the strategy from placing a duplicate order on the next evaluation cycle.

Strategy kill switch triggered: the strategy's configured maximum drawdown threshold is crossed. All open positions for that strategy are closed at market price. Strategy execution is paused and does not automatically restart. Review and manual re-enable are required. This is not a recoverable error that the platform handles silently — it requires explicit trader acknowledgment before the strategy runs again.

Daily loss limit reached: total session P&L across all strategies crosses the configured daily halt threshold. All strategy execution stops for the remainder of the session. No automatic restart at next session open — the halt persists until manually cleared. An alert is sent immediately when the threshold is crossed.

In every failure scenario, the platform takes the conservative action — no position, or position closed — rather than continuing to execute in an uncertain state. The principle is consistent: uncertain state means stop, not continue.

What Oyamori Does Not Do

For clarity:

Oyamori does not predict future prices. The edges in the catalog are statistical advantages derived from documented market structure, not forecasts.

Oyamori does not guarantee profitability. An edge with a 60% win rate still loses on 40% of trades. Drawdowns are part of the expected behavior of any systematic strategy, and drawdowns during normal operation are not platform failures.

Oyamori does not transfer funds. The API scope covers trading operations only. Moving money into or out of your Alpaca account requires your direct action in the Alpaca interface.

Oyamori does not make discretionary overrides to your configured strategy. If the strategy's logic says hold, the platform holds. The rules you configure are the rules the platform executes — no adjustments based on Oyamori's own judgment about market conditions.

Oyamori does not hold custody of your assets. Your Alpaca account is your account. If you disconnect Oyamori, your positions remain in your Alpaca account exactly where they are.

The Oyamori Approach

The platform is designed to be inspectable. Signal history is logged with timestamps and the data state at the moment of evaluation. Execution records are available: every order submitted, every fill received, every risk check that blocked an order, every sentiment suppression. Parameter changes are timestamped — if you changed a stop threshold on a given date, that change is recorded in the strategy's audit log.

The goal is that a developer should be able to reconstruct exactly what the platform did and why, for any trade, at any point in history. Not "the algorithm handled it" — but here is the signal, here is the data at that moment, here is the risk check result, here is the order that went to Alpaca, here is the fill that came back, here is the slippage from expected.

That level of auditability is not a differentiating feature. For any developer evaluating a platform that touches their capital, it is the minimum acceptable standard.

Next: Why CLI-First Trading Is the Developer's Advantage →