PERSONAL MASTER PRESENTATION / V0.2
Research. Strategy. Infrastructure.
Pengyi Peng / a four-lens conversation about building systems that make decisions testable.
01 / FOUR ROLE LENSES
Four roles expose one connected problem-solving system.
Research discovers signal; Strategy and Product frames firmwide decisions; TDOE protects desk flow; Infrastructure Automation improves the operating substrate.
- Quantitative Researcher / model and experiment
- Strategy and Product / structured cross-functional decisions
- Trading Desk Operations Engineer / desk systems and workflows
- Infrastructure Automation Specialist / process, data, and tooling
02 / SHARED METHOD
My throughline is turning uncertainty into an inspectable loop.
Question -> Model -> Experiment -> Decision -> System -> Feedback
- Make assumptions explicit
- Encode state and failure boundaries
- Run the smallest useful experiment
- Use evidence to decide the next change
03 / QUANTITATIVE RESEARCH
A signal is credible only when its full path can be challenged.
Data -> Feature -> Signal -> Portfolio -> Risk -> Execution -> Attribution
- Experiment design and dataset construction
- Time-series and factor reasoning
- Robustness across regimes
- Research-to-system handoff
04 / STRATEGY AND PRODUCT
The product is often the decision system around the code.
A strong generalist connects market context, technical constraints, operating workflows, and the people who own the outcome.
- Structure an unfamiliar problem
- Map stakeholders and constraints
- Translate analysis into an executable change
- Measure whether the workflow improved
05 / TRADING DESK OPERATIONS
Desk infrastructure is where urgency meets correctness.
The TDOE lens requires fast diagnosis, reliable data queries, workflow ownership, and clear coordination with traders, developers, and counterparties.
- Observe and locate the operational bottleneck
- Patch the smallest safe boundary
- Validate the behavior under time pressure
- Communicate the operational consequence
06 / INFRASTRUCTURE AUTOMATION
Automation is valuable when it removes work without hiding risk.
The infrastructure lens combines process discovery, data handling, tool building, monitoring, and ownership across group boundaries.
- Model the process before automating it
- Preserve auditability and failure visibility
- Build narrow tools with clear owners
- Measure reliability, latency, and Human rework
07 / ONE SYSTEM
The four lenses meet at interfaces, feedback, and ownership.
Research produces a hypothesis; strategy chooses a direction; desk systems operationalize it; infrastructure keeps the loop reliable.
- Shared data and state definitions
- Explicit interfaces and escalation paths
- Evidence attached to decisions
- Feedback returned to the model
08 / ENGINEERING EVIDENCE
Maintainer review is my external test of engineering judgment.
The strongest contribution is not the largest diff; it is a real problem, a clear boundary, a verified fix, and a useful discussion.
- LightRAG #3607 / token-limit boundary
- NautilusTrader #4637 / deterministic request tests
- Tencent WeKnora #2549 / archived-page statistics
09 / WORKING ARTIFACTS
I use deployed artifacts to make the conversation concrete.
The portfolio is not one monolith; each system makes a different claim testable.
- Rates Bond Quant / fixed-income research laboratory
- PWEB / typed full-stack system and deployment surface
- PPPT / evidence-to-presentation production loop
- PCV Package 004 / role-specific evidence packaging
10 / FIT AND GAPS
A credible fit case includes the gaps that still need proof.
The evidence is strongest in mathematical systems thinking, AI-native engineering, deployed research tools, and bounded open-source work.
- Prove deeper timed probability and market reasoning
- Increase production-scale data and systems evidence
- Test desk workflow judgment through realistic scenarios
- Select one role and office before external delivery
11 / NEXT BUILD
The next evidence should connect research logic to operating reality.
Build one market-data-to-decision workflow with explicit invariants, failure handling, tests, and a measurable operational interface.
- Research baseline in Python
- Performance path in C++
- Typed reference model in OCaml
- Differential tests across implementations
12 / NEXT CONVERSATION
Which boundary would you test first?
Quantitative Research / Strategy and Product / Trading Desk Operations / Infrastructure Automation
- pengyi-peng.pages.dev
- github.com/pengpengyi92
- pengpengyi92@gmail.com