Research // Project System

Project Pods // Long-Lived Labs

Pods are where AggieQuant turns interest into work. Each pod should start from a real question, finish one useful project every semester, and leave the next cohort a better launch point instead of a reset.

We do not want a long graveyard of half-finished club ideas. Strong pods pick a lane, define the first thing to finish, and preserve memory through README quality, research logs, and handoff notes.

Current pod families
6
Research, systems, data, event markets, derivatives, and education.
Expected weekly load
3-6 hrs
Enough time to make real progress without pretending everyone has startup bandwidth.
Semester output
1 finished thing
Memo, notebook, simulator, dashboard, or documented dataset workflow.
Apply to Core Program Open Pod Packet

03// POD_FAMILIES

The families below should be broad enough to preserve memory and narrow enough that members can tell what kind of work actually lives there. Research looks strongest when the question is concrete, so the rest of this page now follows that same standard.

Strategy Research

Replicate ideas, test assumptions, and turn "interesting paper" energy into an honest notebook with failure analysis.

Cross-sectional ideas Backtests Research memos

Market Microstructure

Study liquidity, spreads, inventory risk, and execution behavior through simple simulators and careful market-structure notes.

Order books Execution logic Market making

Data Engineering

Build the workflows, schemas, and validation layers that let the rest of the club move faster with less chaos.

Ingestion Cleaning Shared datasets

Options & Volatility

Work on options intuition, term structure, surface behavior, and the gap between textbook pricing and live-market frictions.

Greeks Vol surfaces Hedging

Prediction & Event Markets

Study calibration, crowd pricing, and base rates through prediction markets, campus events, and structured forecasting questions that can actually be scored.

Prediction markets Forecasting Event scoring

Education & Reps

Turn technical ideas into drills, explainers, and practice surfaces that help the next cohort ramp faster.

Mini-guides Problem sets Training tools

04// CURRENT_CYCLE

These are the most plausible Fall 2026 lanes if we want the pod system to feel alive instead of theoretical. Each one names a clear first output so there is less dead air between "join a pod" and "here is what we are shipping."

Market Research Pod

Fall 2026 target: produce one replication memo on a simple equity pattern, including data caveats, a baseline, and why the result might fail out of sample.

Lead task: baseline notebook First output: 3-page memo

Microstructure Pod

Fall 2026 target: document spread capture, inventory risk, and order-book behavior through a manual quoting workflow and one written debrief.

Lead task: quoting rules First output: simulation brief

Data & Tools Pod

Fall 2026 target: stabilize one shared ingestion or cleaning path so future pods stop rebuilding the same infrastructure from scratch.

Lead task: schema + validation First output: setup README

Volatility Pod

Fall 2026 target: build one clean options-volatility notebook that translates Greeks and surface intuition into something members can actually study and extend.

Lead task: starter notebook First output: annotated walkthrough

Prediction & Event Markets Pod

Fall 2026 target: score one clean forecasting workflow with Brier/log-loss style evaluation, then test whether collected market odds or club forecasts are actually better calibrated.

Lead task: resolution log + scorer First output: calibration brief

Education & Reps Pod

Fall 2026 target: turn one hard topic into a reusable practice surface so new members leave with a better first week and pod leads stop rebuilding onboarding every semester.

Lead task: rep pack or drill set First output: guided practice page
Featured build path

Prediction markets are the missing events content

Treat event markets as a scored pod, not filler: forecast campus or market results, resolve them cleanly, and use the results to teach calibration.

Good first question Are our probability forecasts better calibrated than the market prices or priors we collected?
Good first output A public demo or memo with Brier score, log loss, calibration bins, and one honest write-up of what failed.
Good long-term path Build toward a campus virtual market where members forecast TAMU events using clean contract wording, settlement rules, and an saved benchmark trail.
  • Start from scoring and a resolution log before chasing product polish.
  • Use the events board as fuel for forecast questions, not as a disconnected calendar.
  • Leave the next pod a reusable dataset, rules, and benchmark notebook.
Open Prediction Markets Starter View Event Board

05// OPERATING_CADENCE

The cadence section was reading a little too airy, so the goal here is explicit weekly rhythm: a small scope, visible progress, and enough documentation that newcomers can keep moving.

Week 1: scope the question

  • Read the README, the last handoff, and the latest successful run.
  • Agree on one semester question that can be tested honestly.
  • Define one first output before adding more ambition.

Weeks 2-10: ship in narrow loops

  • One working meeting, one async checkpoint, and one documented next step.
  • Underclassmen should own narrow upgrades, not vague "help out" roles.
  • Every meeting should produce either code, notes, or a sharper question.

Weeks 11-13: finish and explain

  • Package the project so another member can understand it quickly.
  • Write down the biggest failure mode, missing data, and what to do next.
  • Leave the next cohort a better first hour than you had.

Pod leads own clarity

  • Keep the backlog short and the ask concrete.
  • Do not hide confusion inside buzzwords or overbuilt roadmaps.
  • Good pod leadership is operational: structure, pacing, and memory.

06// OUTPUT_STANDARD

This section needed a little more substance so the standards do not read like placeholders. A pod is healthy when someone outside the pod can quickly understand the repo, the project, and the next move.

Readable README

What the pod is trying to answer, how to run the current state, and what already works.

  • State the active question in plain language.
  • Document the last successful run and setup path.

Visible project

Notebook, memo, simulator, dashboard, or cleaned dataset path that can be shown and explained.

  • Make the project reviewable in one sitting.
  • Prefer one clear thing over three half-finished ones.

Honest handoff

Best result, biggest failure, missing data, and the first three actions the next team should take.

  • Write down failure modes while they are still fresh.
  • Leave the next team a sharper first hour.

07// FIT_LOGIC

Matching works better when the page tells people what "fit" actually means. The aim is practical matching, not prestige sorting.

How members get matched

  • Tell us what kind of work you want to do and what you can realistically sustain each week.
  • Leadership uses your current skill surface plus your growth goals, not prestige language, to place you.
  • If the fit is clearly wrong, we would rather fix it than let someone stall for a full semester.

What to do before applying to Core

  • Skim the pod packet so you know what "good output" actually means here.
  • Look at the current pod families and pick two that genuinely fit your interests.
  • Be ready to name one thing you want to build, test, or understand better.

Pod work should feel real.

If a pod cannot explain its question, project, and handoff path, it is not ready yet. We would rather run a smaller number of clear, durable pods than claim breadth without memory.

Read the Pod Packet Core Application