**Research Platform — Phase 1 Build Brief** *For PO and Tech Lead* Quant Fund — VN Index & Crypto Markets 1\. Executive Summary We are building a centralized research platform to institutionalize the fund's IP — moving knowledge out of individual researchers' notebooks and into a system. This brief covers Phase 1: the foundational three components that everything else depends on. **Phase 1 scope:** - P1 — Unified Data Layer (Months 1–2) - P2 — Canonical Backtester (Months 2–4) - P3 — Signal Library with Tiered Access (Months 4–6) Total Phase 1 duration: \~6 months. End state: any researcher can pull point-in-time data, run a reproducible backtest, and reference signals from a versioned library — with access controlled by role. 2\. Context the Platform Must Serve - Markets: VN Index equities and crypto. Two very different market microstructures must be handled in one platform. - Data: multiple external feeds per market. Sources can disagree, drop, or correct historical data. - Output: signals are pushed to Telegram for human-in-the-loop execution. Provenance of every signal must be traceable to a strategy version and data snapshot. - Team: small quant team + PO tech team. Knowledge is currently concentrated in individuals. Reducing key-person risk is a primary goal. - Sensitivity: model logic is IP. Access must be tiered from day one. Documentation cannot be open by default. 3\. Operating Model — How the Two Teams Work Together This is the most common failure point in research platform builds. Get this right before writing code. Roles - Platform Product Owner (quant side): senior researcher who defines interfaces, accepts deliverables, and prioritizes tradeoffs. Without this role filled, the platform will drift toward what is easy to build, not what is needed. - Tech Lead (PO tech side): owns architecture, technology choices, and delivery. Reports progress weekly. - Embedded engineers: 2 PO tech engineers sit with the quant team full-time. One owns data and infrastructure; one owns the research workbench and backtester. - Security/access engineer: part-time, owns identity, permissions, and audit logging. Working principles - Quants own interfaces. Engineers own implementations. Quants define what a 'signal' or 'tear sheet' must contain; engineers build the systems that enforce those contracts. - Ship thin slices. Each phase migrates one real strategy end-to-end before widening scope. Resist the urge to design the perfect system upfront. - Weekly demo, biweekly retrospective. Researchers must see progress they can use, not just architecture diagrams. - Versioned everything. Every backtest result reproducible from a git SHA plus a data snapshot ID. 4\. Access Tiers — Enforced from Day One Access tiering must be designed in from the start. Backfilling permissions onto an open system is painful and usually leaks first. | | | | | | -------- | --------------------------------------- | ------------------------------------------------------------------------- | --------------------------------------------------------------------------------------- | | **Tier** | **Who** | **Can See** | **Cannot See** | | **T0** | Investors, auditors, external reviewers | Aggregate performance, risk metrics, process integrity reports | Signal definitions, code, positions | | **T1** | Junior researchers, interns | Data layer, run assigned backtests, author research in sandboxed branches | Full signal library source, production strategy code, other researchers' in-flight work | | **T2** | Senior researchers | Full signal library, propose strategies for production | Unilateral deployment, infrastructure modification, deal-level financials | | **T3** | Principals (Eric, C, Head of Research) | Everything, including production deployment approval and access grants | (audit log applies to all T3 actions) | **Critical boundary: T1 → T2. That is where IP exposure lives. Strong controls at that line; lighter controls elsewhere.** Enforcement points - Single sign-on (SSO) via Okta, Auth0, or Keycloak. Every action carries a user identity. - All data and signal queries route through a platform API. No direct database credentials issued to users. - Tear sheets watermarked with viewer identity. PDF exports logged. - Signal library source restricted to T2+. T1 sees only signal names and high-level descriptions for assigned projects. - Immutable audit log on all access and changes. Unusual patterns (bulk downloads, off-hours access) trigger alerts. 5\. P1 — Unified Data Layer **Timeline: Months 1–2** **Owner: PO tech (data engineer lead) with quant input on schema** 5.1 Why This Comes First Every signal, backtest, and decision downstream is only as good as this layer. Bad data produces convincing but wrong backtests, which is worse than no backtest at all. VN equity has its own quirks (foreign room limits, ceiling/floor prices, ATC/ATO sessions, corporate actions). Crypto data is messy — exchange outages, bad ticks, different symbol conventions across venues, 24/7 with no clean session boundaries. A unified layer that normalizes both is the foundation. 5.2 Required Features Storage and ingestion - Immutable data lake on object storage (S3-compatible). Parquet format, partitioned by date and asset class. - Ingestion pipelines per source, scheduled and monitored. Each pipeline produces a dataset manifest with source, ingestion timestamp, schema version, row counts, and checksum. - Point-in-time integrity: when data is corrected after the fact, the original version is preserved and the correction is recorded as a new version with the correction timestamp. Backtests can replay history as it was known at any past date. - Corporate actions handled as first-class data: splits, dividends, mergers, index reconstitutions, ticker changes, foreign room adjustments. Schema coverage - VN equities: daily and intraday bars, fundamentals (as-reported, with reporting timestamps), corporate actions, foreign ownership room, index membership history, ceiling/floor prices per day. - Crypto: spot and perpetual futures bars, funding rates, exchange-level liquidity, symbol mapping across venues. - Cross-asset: reference data (calendar, holidays, sessions), FX rates, macro indicators if used. Source reconciliation - When two sources disagree, both values are stored. A configurable reconciliation rule picks the canonical value (e.g., 'prefer Source A unless missing'). Reconciliation decisions are logged. - Daily reconciliation report: divergence between sources flagged for review. Quality monitoring - Nightly checks: missing data, outliers (price moves beyond plausible thresholds), schema drift, corporate action consistency. - Failed checks alert before the next research day starts. No researcher should waste a day on bad data. Access - Single Python client library. Researchers query by symbol, date range, and field — never by file path. - Client carries user identity. Queries are logged with user, dataset, and time range. - Read-only by default for all tiers. Ingestion writes only through pipeline service accounts. 5.3 Acceptance Criteria - A researcher can query the full VN30 universe as of any past date with no survivorship bias and no look-ahead bias. - A researcher can query crypto OHLCV across at least 2 exchanges, with funding rates available. - Two researchers running the same query at the same time get byte-identical results. - Data quality dashboard shows ingestion status and failed checks for the last 7 days. - Onboarding a new data source requires a documented pipeline; no ad-hoc CSV loads anywhere. 5.4 Suggested Technology Stack - Storage: S3-compatible object store (MinIO if self-hosted, or AWS S3). Parquet files. - Query layer: DuckDB for interactive queries, or Trino/Presto if scale demands it. - Orchestration: Airflow or Prefect for ingestion pipelines. - Catalog: a lightweight metadata service (Postgres-backed) for dataset manifests and lineage. - Identity: Okta, Auth0, or self-hosted Keycloak. These are suggestions, not mandates. The tech lead should choose based on team familiarity and operational cost. 6\. P2 — Canonical Backtester **Timeline: Months 2–4** **Owner: PO tech (backend engineer lead) with quant defining strategy specification and tear sheet contract** 6.1 Why This Comes Second Today, every researcher probably has a slightly different backtester. Results are not comparable across researchers, assumptions are buried in code, and migrating a strategy to production is a manual re-implementation that often introduces bugs. One canonical backtester, owned by infrastructure, fixes this. It also forces explicit documentation of every assumption (cost model, fill assumptions, sizing logic) that is currently implicit. 6.2 Required Features Strategy specification format - Researchers submit a strategy spec — not arbitrary code — describing: universe filter, entry rules, exit rules, position sizing, rebalance frequency, cost model, capital constraints. - Spec format is structured (YAML or JSON-like) with a defined schema. The schema is versioned and reviewed by quant leadership before changes. - Signal references in the spec point to entries in the signal library (P3). Until P3 is built, signals are defined inline with the understanding they will be migrated. Execution engine - Vectorized for speed where possible; event-driven where path-dependence is required. - Same code path for VN equity and crypto. Market-specific behavior (sessions, costs, constraints) configured through the strategy spec. - Realistic cost model per market: VN brokerage fees, tax, slippage, ceiling/floor constraints, foreign room; crypto exchange fees, funding rate impact, slippage by venue. - Capacity-aware: backtester estimates achievable size based on average daily volume / order book depth. Results include capacity warnings. Reproducibility - Every run produces a unique run ID. - Run ID resolves to: code SHA, strategy spec, data snapshot ID, configuration, runtime environment. - Any past run can be re-executed and must produce byte-identical results. Standardized tear sheet - Performance: Sharpe, Sortino, CAGR, max drawdown, drawdown duration, hit rate, profit factor. - Risk: volatility, downside deviation, tail metrics, factor exposures. - Operational: turnover, average holding period, capacity estimate, cost drag breakdown. - Robustness: regime decomposition (bull/bear/sideways), parameter sensitivity, walk-forward results. - Tear sheets are watermarked with viewer identity and exported as PDF with logging. 6.3 Acceptance Criteria - One currently-live strategy is migrated onto the new backtester and produces results within an agreed tolerance of the original (e.g., Sharpe within 0.1, CAGR within 0.5%). - Same strategy spec run twice produces identical tear sheets. - A strategy spec written in November can be re-run in March and produces the same result it produced in November (point-in-time integrity verified end-to-end). - Tear sheets pass a quant team review for completeness and clarity. - New researcher can run their first backtest within one day of onboarding. 6.4 Migration Approach Pick one well-understood live strategy. Migrate it end-to-end. Compare results carefully — every discrepancy surfaces an assumption that was previously implicit. Document each one. This migration is the real test of the backtester and the data layer underneath it. 7\. P3 — Signal Library with Tiered Access **Timeline: Months 4–6** **Owner: Joint — quant team defines schema and reviews entries; PO tech builds infrastructure** 7.1 Why This Is the IP Vault This is where the fund's alpha actually lives. The signal library is what makes knowledge institutional rather than personal. It is also the highest-sensitivity component of the platform — access tiering matters most here. 7.2 Required Features Signal registration - Every signal stored with: name, formula or pseudocode, author, creation date, status (development/staging/production/retired), version, dependencies (data fields, other signals), decay characteristics, correlation to existing signals, review history. - Signals are versioned. Modifying a signal creates a new version; old versions remain queryable. Production strategies pin to a specific version. - Same code path for backtest and live computation. The signal that fires in Telegram is provably the same one that backtested well. This is the single most important architectural property of the library. Discovery - Searchable catalog: by market, signal family, author, status. - Correlation and overlap dashboard helps researchers avoid reinventing existing signals. Critically: only shows signals the viewer has access to. - Lineage view: which strategies use this signal, in production or in research. Access controls - T1: sees signal names and high-level descriptions only for signals assigned to their projects. Cannot enumerate the full library. - T2: full library access including source. T2 status granted explicitly by T3. - T3: controls who has T2 access, can revoke immediately. - All signal reads logged. Bulk downloads, unusual patterns, off-hours access alert. - Watermarking on any export. Migration of existing models (P2.5) - Parallel workstream starting Month 2: structured wiki documenting every existing model (live, paused, retired). - Documentation captured via interview, not self-write. 60–90 minutes per model, senior interviewer using a fixed template. - Template fields: hypothesis, economic rationale, signal definition, data dependencies, universe and filters, entry/exit/sizing, historical performance, known failure modes, status, ownership. Retired models also capture why retired and what was learned. - Wiki access tiered from day one (Notion, Confluence, or git-backed markdown with auth). - In Months 5–6, wiki documentation migrates into the structured signal library. The wiki is scaffolding; the signal library is the permanent home. 7.3 Acceptance Criteria - All currently-live signals registered with complete metadata. - All paused and recently-retired models documented in the wiki. - A new strategy proposed for production references only signals in the library — no inline signal definitions accepted. - T1 user cannot enumerate the full signal library; T2 user can; access attempts outside tier are logged and blocked. - Backtest run referencing a signal version produces results identical to live computation using the same version. 8\. Phase 1 Roadmap at a Glance | | | | | | --------- | ------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------- | | **Month** | **Workstream** | **Key Deliverables** | **Milestone Gate** | | **1** | P1: Data Layer | Identity/SSO live. Data lake stood up. First ingestion pipelines for VN equity and one crypto exchange. | Researcher can query VN30 daily bars with identity logged. | | **2** | P1 finish + P2 start + P2.5 start | Point-in-time queries working. Corporate actions ingested. Backtester spec format defined. Model documentation wiki stood up; interviews begin. | Data layer acceptance criteria met. First model documented end-to-end. | | **3** | P2: Backtester + P2.5 continues | Backtester v1 running. Cost models for both markets. Tear sheet format finalized. Live models documentation 50%+ complete. | First migrated strategy producing tear sheets. | | **4** | P2 finish + P3 start + P2.5 continues | Backtester acceptance criteria met. Signal library schema designed. All live models documented. | Migrated strategy results match originals within tolerance. | | **5** | P3: Signal Library + P2.5 finish | Signal library infrastructure live. Tiered access enforced. Paused/retired models documented. | First signals registered; T1/T2 access boundary verified. | | **6** | P3 finish + Phase 1 review | All live signals registered. Wiki content migrated into library. Phase 1 retrospective. Phase 2 planning. | Phase 1 acceptance criteria all met. Ready to begin P4–P6. | 9\. Resource Estimate **Indicative team for Phase 1:** - Tech Lead: 100% allocation - Data engineer (P1 lead): 100% for Months 1–3, 50% thereafter - Backend engineer (P2 lead): 100% for Months 2–6 - Security/access engineer: 50% throughout - Frontend engineer (tear sheets, dashboards, library UI): 50% from Month 3 - Quant Platform PO: 50% throughout - Quant team (for interviews, schema reviews, acceptance testing): \~1 day per researcher per week These are starting estimates. The tech lead should refine after architecture choices are made. 10\. Top Risks and Mitigations - Risk: scope creep on data layer. Mitigation: define schema coverage upfront and resist additions until P1 acceptance criteria are met. - Risk: backtester migration reveals deep discrepancies with current results. Mitigation: budget time for assumption reconciliation; treat discrepancies as discoveries, not failures. - Risk: quant team does not engage with documentation interviews. Mitigation: principals (Eric, C) personally schedule and attend the first round to set the precedent. - Risk: access tiering treated as optional in early build. Mitigation: identity and access are part of P1 acceptance criteria, not a later add-on. - Risk: PO tech team builds in isolation. Mitigation: embedded model with weekly demos. If researchers are not using new tooling by Month 3, escalate. 11\. Out of Scope for Phase 1 Explicitly deferred to Phase 2 (Months 7–12): - P4: Telegram signal provenance pipeline - P5: Peer review and automated validation gates - P6: Live-vs-backtest divergence monitoring - Automated execution (remains human-in-the-loop via Telegram) - LP-facing reporting layer These depend on Phase 1 foundations and should not be started until P1–P3 are in production use. *— End of Phase 1 Build Brief —*