This repository contains the architecture documentation for the CanonicalFlow trading system. It is the canonical reference for the system's concepts, architectural decisions, implementation-facing stack descriptions, and operational model.
The goal of this repository is to make the structure, reasoning, and constraints of the system explicit and durable. It captures:
- canonical system concepts and semantic models
- architectural boundaries and design decisions
- implementation-facing stack realizations
- operational behavior and runtime model
- system evolution context
Documentation here is organized to remain accurate over time by separating what the system is conceptually from how it is realized in implementation.
This documentation is intended for:
- system architects and quantitative developers working on or reasoning about the system
- infrastructure and platform engineers who need to understand subsystem boundaries
- contributors who need shared vocabulary and design context before making changes
.
├── docs/
│ ├── 00-guides/ # Orientation, vocabulary, reading aids
│ ├── 10-architecture/ # Architecture views, principles, and ADRs
│ ├── 20-concepts/ # Canonical semantic models
│ ├── 30-stacks/ # Implementation-facing stack documents
│ ├── 40-operations/ # Operational model and runbook-facing material
│ ├── 50-evolution/ # Roadmap, milestones, and development history
│ ├── assets/ # Logos and static assets
│ ├── overrides/ # MkDocs theme overrides
│ ├── stylesheets/ # Custom CSS
│ └── javascripts/ # Custom JavaScript
├── mkdocs.yml # Site configuration
├── requirements-dev.txt # Python dependencies
├── CONTRIBUTING.md
└── README.md
The documentation is numbered to encode reading flow from foundational orientation toward implementation and operational detail.
| Section | Role |
|---|---|
00-guides |
Entry point — architecture map, documentation structure, terminology, and philosophy. Start here. |
10-architecture |
System-level architecture views, logical and physical structure, system flows, and Architecture Decision Records (ADRs). |
20-concepts |
Canonical semantic definitions — the Event model, State model, Determinism model, Time model, Order lifecycle, Queue semantics, and related invariants. This is the authoritative source for exact meaning. |
30-stacks |
Implementation-facing realizations of the conceptual model, organized by Stack. Stack documents describe what each subsystem does, how it is structured, and what its boundaries are, without redefining canonical semantics. |
40-operations |
Operational model, monitoring, recovery, and runbook-facing material. |
50-evolution |
Roadmap, milestones, and development history. |
The 20-concepts section defines what the system means. The 30-stacks section documents how those meanings are realized. Other sections orient, record decisions, or describe operational and evolutionary context.
Each Stack in 30-stacks follows a standard document structure: overview, scope and role, interfaces, internal structure, operational behavior, and implementation notes.
The site is built with MkDocs and the Material for MkDocs theme.
pip install -r requirements-dev.txtmkdocs serveThen open http://127.0.0.1:8000.
mkdocs buildThe site is published to GitHub Pages as a versioned documentation site using mike.
Documentation is deployed from Git tags, not from every push to main.
Typical flow:
- Create your documentation changes in a feature branch.
- Open and merge a pull request into
main. - Create and push a version tag, for example:
git checkout main
git pull
git tag 0.1.0
git push origin 0.1.0Pushing the tag triggers the GitHub Actions workflow, which deploys that documentation version with mike, updates the latest alias, and sets latest as the default version.
To deploy a version manually from your local environment:
mike deploy --update-aliases <version> latest
mike set-default latestExample:
mike deploy --update-aliases 0.1.0 latest
mike set-default latestTo preview the versioned site locally:
mike serve- Use version strings like
0.1.0rather thanv0.1.0for documentation versions unless you intentionally want your documentation version names to match Git tag names with avprefix. - The GitHub Pages site is published from the
gh-pagesbranch managed bymike.
See CONTRIBUTING.md for full guidance.
In brief:
- Contributions should improve clarity, correctness, or completeness of the documentation.
- Canonical semantic definitions live in
20-concepts. Stack and operational documents should apply those definitions, not redefine them. - Architectural decisions of significant scope should be documented as ADRs under
10-architecture/adr/. - Keep commits small and well scoped. Pull requests should explain what changed and why it improves the documentation.
Documentation content is licensed under CC BY 4.0 unless otherwise stated.
This repository documents system architecture and engineering concepts. It does not constitute financial advice.