Pod Documentation Packet
Read the pod system without going through the website repo
This packet is the public guide to how pods run. AggieQuant's main GitHub is for the website and shared club systems. Each pod keeps its own repo, write-up packet, and handoff trail for pod-specific work.
Distribution Model
Public packet here, pod ownership elsewhere
The model is simple: the site explains the system, pod teams own their own repos, and polished pod write-ups live in Overleaf, PDFs, or another pod-owned docs surface.
System Guide
How the pod system actually works
A pod is a small team that inherits a starting point, ships one semester-bounded artifact, and leaves the next cohort a cleaner restart path.
Pod family
The family is the broad domain: prediction markets, volatility, microstructure, data infrastructure, or another durable lane of work.
Starter kit
The starter gives members a first runnable path so the semester begins from inherited structure instead of blank-page paralysis.
Semester deliverable
Each pod still needs one bounded artifact: a memo, demo, notebook, dashboard, simulator, or benchmark result that proves the pod moved.
Handoff
The handoff is the real continuity mechanism. Without it, even a strong semester output gets lost on turnover.
First Semester
How underclassmen ramp without getting lost
New members should not be asked to invent structure on day one. The right first semester is inheritance, one narrow contribution, and a better trail for the next person.
Read the current state
Start with the README, the last handoff, and the last successful run before proposing new directions.
Own one narrow slice
Good first work is one importer, one metric, one baseline, one chart, one setup fix, or one cleaner demo surface.
Update the trail
Research logs, README fixes, and short assumption notes are what keep the pod from resetting next semester.
Leave a restart kit
By semester end, a new member should be able to see what worked, what failed, and what to do first next time.
Repo Model
What should live in the main repo, and what should spin out
AggieQuant's main repo owns the website and shared club infrastructure. Pod teams own sibling repos for pod-specific code, research, tests, and documentation.
Main Repo
Website and shared club systems
The AggieQuant repo owns the public site, shared member-facing tools, and lightweight starter patterns that explain the system clearly.
Pod Repos
Separate sibling repos for real pod work
Pod teams create sibling repos similar to the prediction-markets repo model. Pod-specific work does not live permanently in the website repo.
Doc Surfaces
Packets, PDFs, and Overleaf write-ups
Polished pod write-ups live in Overleaf, exported PDFs, or another pod-owned docs surface. The site links to those packets instead of sending members into the website GitHub repo to read them.
Worked Example
The prediction-markets pod is a strategy example, not the product roadmap
Use prediction markets to teach scoring, calibration, contract wording, and event-market discipline. Keep the online prediction exchange separate as its own AggieQuant product.
Prediction Markets
Why this pod is still a strong model
The starter is useful because the evaluation standard is obvious. Members learn proper scoring, compare model probabilities against market probabilities, and work on systematic event-market research without confusing that work with the club's separate exchange product.
Teach the scoring loop
Start with question wording, probability forecasts, resolution discipline, and honest evaluation against a baseline or market.
Improve research depth
Add real data, better importers, and cleaner separation between paper edge and tradable edge.
Spin out mature work
When the pod has real depth, it should live in its own sibling repo with its own tests, write-up, and roadmap.
Documentation Flow
The packet is the public index
The site introduces the system, pod packets hold the polished write-ups, and sibling repos hold the pod-specific code. That is the default documentation model.