Automation

This page describes how automation is applied across the project — both in the software we're building and in our own development workflow. These are our initial plans for the semester; they are expected to evolve as we learn more.

1. Automation within the solution (product-level)

The core of this product is autonomous decision-making, so automation isn't a side feature — it's the point:

• Scheduled agent execution — a scheduler (e.g. APScheduler, or a Compose sidecar running cron) triggers the full pipeline (Context Assembler → Math Engine → Reasoning Orchestrator → Risk & Execution Engine) automatically every 5–15 minutes during US market hours. No human kicks off a trading cycle manually.
• Deterministic indicator computation — RSI(14) and SMA(20) are computed automatically from fetched price bars every cycle, with no manual recalculation.
• Automated safety enforcement — every LLM-proposed decision is automatically checked against hardcoded rules (max 10% capital exposure, trading-hours restriction) before anything reaches Alpaca. This check runs unconditionally, with no manual override path.
• Automated audit logging — every decision (approved or blocked) is written to PostgreSQL automatically as part of the pipeline, with no manual logging step.

2. Automation of our development workflow

• Continuous Integration — GitHub Actions A workflow triggers on every push and pull request to run our PyTest suite automatically, including targeted tests for the safety-guardrail logic (since that's the highest-risk code in the system). This gives fast feedback before code merges to main.
• Containerized builds — Docker Compose All services (dashboard, backend/agent, database) are defined in a single docker-compose.yml, so any team member — or a grader — can bring up the full system with one command, without manually installing or configuring dependencies.
• Environment consistency Environment variables (API keys, DB connection strings) are managed via a .env file pattern, kept out of version control, so automated builds behave identically across machines.

3. Planned but not yet implemented

• Automated deployment — we have not yet set up continuous deployment (e.g. auto-deploy on merge to main); for now, running the Compose stack locally/on a single host is sufficient for grading and demo purposes. This may be revisited later in the semester.
• Automated test-coverage reporting — we plan to add coverage reporting to the CI workflow so we can track how well the safety-critical code paths are tested over time.

Why this approach

Given the risk profile of this project (an LLM initiating real API calls, even in a paper environment), we prioritized automating the safety and audit path first — that's where a manual step could introduce human error, and it's also the code with the highest consequences if it silently breaks. Deployment automation is lower priority for an academic MVP than build/test automation, so we're deferring it.