Alex’s research labOpen questions. Reproducible work.

Open research / Open

Cheaper corrections to historical aggregates

Can a corrected historical record update affected aggregates exactly without recomputing entire reporting periods?

#incremental-computation#reporting#aggregations

The question

Can a corrected historical record update affected aggregates exactly without recomputing entire reporting periods?

This is a proposed research direction. No novel algorithm, completed benchmark or performance gain is claimed.

Why it matters

Reporting and analytics platforms could process corrections faster and with less compute.

Search space

Dependency indexes, reversible aggregate state and partitioned incremental maintenance.

What would count as progress?

  • Agreement with full recomputation after inserts, updates and deletes
  • correction latency
  • data touched
  • state size.

A useful result improves a measured trade-off against strong baselines on held-out workloads, with reproducible code and documented limitations.

Baselines and boundaries

Start with exact sums and counts, then separately examine non-invertible aggregates. Include updates that move records between groups or periods and corrections to old data.

Where you could contribute

Help define representative, legally shareable workloads; critique the correctness contract; implement baselines; propose candidates; or reproduce measurements. Negative results and failure cases are useful contributions.

A detailed research brief is being prepared. Access requests will become available when that brief and the request service are ready.

Think out loud

A discussion for this problem.

Questions, alternative approaches and thoughtful critiques are welcome. GitHub sign-in is needed to post. This discussion is public: do not copy restricted materials or personal data into comments. Loading comments connects to giscus and GitHub.

The discussion thread for this problem has not been opened yet. Please check back once it is linked.