What Westraynham actually does, feature by feature
Every capability below exists to support one outcome: a documented, checkable view of how a model arrives at an output — not a black box and not a promise.
A model, a dataset, and a record you can inspect
Westraynham is organised around three connected parts. Each is a feature in its own right, and each is designed to be checked rather than taken on faith.
Data inputs the model is trained on
The model works from a defined set of inputs rather than an unlabelled firehose of data. Knowing what goes in is part of knowing what the output means.
- On-chain transaction and liquidity data across tracked assets
- Historical price and volume series at multiple time intervals
- Order book depth snapshots from supported venues
- Volatility and correlation measures across asset pairs
How an output is produced
Each output passes through a fixed sequence of steps. The sequence does not change case by case, which is what makes the logic repeatable and auditable.
A performance log, not a highlight reel
Instead of curated case studies, Westraynham maintains a continuous log of model outputs and their recorded results. Every entry — favourable or not — stays on the record. This is the feature that lets a prospective user check claims directly rather than rely on marketing copy.
The log is organised by timestamp, asset, and outcome, so a reviewer can trace a specific call back to the conditions that produced it.
Constraints built into the model, not bolted on after
Risk handling is a feature of the model's logic, applied before an output is logged — not a disclaimer added afterward.
What this feature controls
- Caps on position sizing relative to asset volatility
- Automatic exclusion of thinly traded or illiquid pairs
- Defined exit conditions attached to every tracked position
- Rejection of outputs that fall outside set confidence bounds
Current operating thresholds
Thresholds are part of the model configuration and are documented in the account area available after access is granted.
Features in context
How these pieces come together depends on how a given user intends to use the model's output.
Check the record before you check anything else
Because the performance log is public and continuous, a reviewer can assess the model on its own history rather than on a summary written by Westraynham. This is the feature most often used before any other decision is made.
Watch new outputs land against the same fixed logic
The four-step process described above runs the same way for every new output. Watching it operate over time, rather than reading about it once, is how most users come to trust — or discount — the model.
Compare stated thresholds to logged behaviour
The threshold table above states what the model is configured to do. The performance log shows what it actually did. Comparing the two is a deliberate feature of the system, not an afterthought.
Request access to see these features applied
Access includes the live performance log, current threshold configuration, and the full input/output record described above.