S12.3: Naive vs. point-in-time "bias delta" report

Open
#167 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
35/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
python
Domain
backend, data

Research direction

Read the roadmap story and its parent epic, then inspect the engine and results page entry points identified by the project’s roadmap. First trace how a backtest spec and point-in-time data are currently used, including dependency S12.1. Done means the same spec can run in both modes and produce a clearly labeled comparison report with a results page section; the payload names no specific files or tests.

Written by the indexing model from the issue text.

Description

area: engine priority: P0 story

Roadmap story S12.3 · Project · Roadmap

Parent epic: E12 #16

Dependencies: S12.1 #165

Priority: P0 · Size: M · Sprint: 11 · Milestone: M8 · Area: engine · Depends on: S12.1 · Reqs: FR-L3 · Status: Backlog

Story: As a researcher, I want to see how much a naive backtest would have overstated my results, so that the value of point-in-time data is concrete.

Acceptance criteria

  • A clearly labeled naive mode, never the default, uses the latest revised macro values, dates fundamentals by period end, uses today's universe, and uses adjusted prices.
  • The same spec runs both ways, and a report compares the metrics (for example, Sharpe ratio and CAGR, point-in-time vs. naive).

Tasks

  • Build the naive data view
  • Run both modes and write the comparison report
  • Add a section to the results page

Progress evidence (2026-11-08): No implementation or completion evidence for these acceptance criteria is present in the audited commit. This remains planned work.

Audited against committed main at 0c32c57. Local, staged, and untracked work is excluded.

Dominant language
Python
Stars
0
Forks
0
Avg merge
3h 33m
Merged PRs (30d)
50

Getting set up

  • No Dockerfile or Docker Compose file
  • Has a pull request template
  • No contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from nfiasco/Quant-Time-Machine

All issues in nfiasco/Quant-Time-Machine

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.