Start with curiosity
Turn an idea into a first working prototype, using AI to help build and understand each part. A prototype is a starting point, not proof that the idea works.
An open experiment
How far can
AI take an idea?
Let’s
find out.
An open experiment in AI, automation and markets — built from scratch, documented as it evolves.
I’m building an AI trading robot to find out what one person can create with AI as a tool. The goal is to learn, share the journey, and perhaps inspire you to try an idea of your own. Whether the robot can generate returns is still an open question.
Explore the experimentA hypothesis to test. No promises of returns.
EXPERIMENT / 001IN DEVELOPMENT
The question behind the experiment
Can one person build it with AI?
Signal & noiseIllustration · not results
Learn & share
Nothing is proven
Hypotheses before convictionResults before intuitionRespect for the market
The journey
Build something.
Learn something. Share it.
The trading robot is the challenge. The wider question is what we can learn by building it: about AI, markets, risk, automation, and safety. Both progress and setbacks belong in the story.
Ask what really works
Test assumptions, look for mistakes, and be willing to change direction. A useful test can show why something fails as clearly as why it succeeds.
Make the learning useful
Explain decisions in plain language. Share the dead ends and surprises too, so someone else can learn from the attempt.
Inside the project
Beyond the idea.
Inside the system.
Here is the system I want to build, explained one piece at a time. The numbered steps show the intended flow. They are a plan, not a list of completed components.
INTENDED ARCHITECTURE
- 01 /
Market data
Gather the market information the robot needs, and check that it is usable.
- 02 /
Strategy / AI
Explore rules and AI models that might suggest when to trade — or when to do nothing.
- 03 /
Risk engine
Check how much is at risk, set limits, and stop orders that exceed them.
- 04 /
Broker connection
Connect the robot to the service that receives and processes trading orders.
- 05 /
Automated execution
Keep track of orders and positions, including what happens when something goes wrong.
- 06 /
Performance tracking
Record outcomes and costs, then ask whether the results support the original idea.
The loop matters: what the system does should feed back into what gets tested next.
The route I want to explore
- 01
Idea
What do I want to find out?
- 02
First prototype
Can I get the pieces to work together?
- 03
Paper trading
What happens with simulated trades and no real money?
- 04
Real-world tests
If justified, do controlled tests behave as expected?
- 05
Lessons
What worked, what failed, and what would I change?
A direction for the experiment, not a completed timeline. Real-money tests would only be considered after the earlier steps and risk controls have been evaluated.
What I want to share
The documentation grows with the experiment. The project notebook contains dated thoughts and decisions. Below are the topics I want to document further; trading results have not been published yet.
Project notebook ↗01ArchitectureHow the pieces fit together.
Planned documentation
Document the system’s components, how information moves between them, and why a particular design was chosen. The overview above is the starting point.
02Build logWhat changed, and why.
Planned documentation
Record meaningful changes, the question behind each one, and what the next test needs to establish. Include approaches that were tried and abandoned.
03Paper tradingTest the process before real capital.
Planned documentation
Describe simulated trading separately from live trading: the test period, assumptions, costs, and operational issues. Simulation will not be presented as a live track record.
04ResultsEvidence with context.
Planned documentation
Publish results with their timeframe, test conditions, costs, and drawdowns. Separate historical tests, paper trading, and live trading so the numbers can be understood.
05Lessons learnedKeep the findings, including the failures.
Planned documentation
Explain what I learn about AI, markets, risk, automation, and safety. Include failed ideas, mistakes, and changes of mind, with enough context for someone else to learn from them.
No verified trading results published.
Planned capability
Learning from every market cycle
Algora is being designed to remember.
The aim is to store and connect every trade, signal, position, strategy version, risk decision and market condition to the information available at that exact moment.
Combined with ongoing market and macro analysis, this would create a structured historical memory across hours, days, weeks, months, quarters and years.
The goal is to understand not only what happened, but also why a strategy performed differently in different market environments.
Over time, this history could help identify changing market regimes, detect weakening strategies, compare similar periods and improve future decision-making. These are capabilities to build and evaluate, not demonstrated outcomes.
Turn experience into data, data into insight, and insight into better decisions.
Historical memory needs boundaries: defined retention periods, appropriate access, and deletion rules. Analysis should use the information available at the time, not knowledge gained afterwards.
Security & Compliance by Design
Security & Compliance by Design
From V1, Algora Trading should include security, privacy, and compliance considerations in the design. These are requirements for the trading system being developed, not a claim that the controls are already implemented or verified.
Access & identity
Multi-factor authentication (MFA) and least privilege: give each user and service only the access it needs.
Data & credentials
Encryption and secure storage, use, and rotation of passwords, API keys, and other credentials.
Traceability & changes
Audit logs and documented change management, so decisions, actions, and releases can be traced.
Recovery & incidents
Backups, tested restoration, and a documented way to detect, handle, and learn from incidents.
Software & dependencies
Vulnerability scanning and dependency management to identify and address software risks.
Privacy & retention
Collect only needed data, define retention periods, and plan for deletion and appropriate access.
The goal is to follow GDPR principles, prepare for relevant DORA requirements, and consider NIS2-related security controls where applicable. “DORA-ready” is an ambition to assess and demonstrate, not a current compliance status. Applicability must be reviewed against the project’s actual activities and any future use.
If the experiment ever evolves into a multi-user product, the ambition is to extend a sound foundation rather than rebuild security and compliance from scratch. The current purpose remains learning and sharing.
Reference frameworks: GDPR · DORA · NIS2
What the experiment should aim for
Profitability + Risk Control + Security + Auditability + Documentation + Compliance by Design
Project notebook
Project notebook
New thoughts, planned features, decisions, and lessons will be collected here as the experiment evolves. Entries distinguish an idea or requirement from something built and tested.
A historical memory for the robot
New design goal: connect trading events, strategy versions and risk decisions to their original market context. Next steps are to define the event model, timestamps, data sources and retention rules, then test whether the history supports useful comparisons without hindsight.
Explore the planned historical memory ↗Security belongs in V1
Security, privacy, traceability, and compliance considerations have been added to the project’s V1 requirements. The next step is to turn each requirement into a concrete control and a way to test it. This entry documents the direction; it does not mark the controls as complete.
Read the security principles ↗What needs to be worked out next
- Planned
Map risks and requirements
Identify data, credentials, roles, and dependencies; assess which regulatory requirements apply.
- Planned
Define the V1 controls
Specify authentication, access, encryption, logging, recovery, vulnerability checks, and data deletion.
- Planned
Make verification part of the work
Document tests, incident procedures, and changes; record what is implemented and what still needs evidence.
Curiosity, with perspective
“If it were easy,
everyone would do it.”
If it were easy, everyone would do it. That is part of what makes the question interesting. I want to try, understand what happens, and be honest about the outcome.
This site exists to share the experiment and inspire curiosity. There is no trading product, signal service, or promise of returns for sale.