The Wishlist — Four Engines I Haven't Built

Most projects hide their unbuilt ideas in a private notes file. KC Star keeps them in the repository, in a wishlist/ folder, clearly labelled as research — designs I have thought through and not built. There are four of them, plus a reference SQL file honest enough to carry the header “Not Ready - Requires Further Analysis.” This penultimate post is a tour of that folder: four engines I have not built, why each is hard, and which one I would build first. After nine versions of showing you what I made, this is the part where I show you what I didn't.

Why keep a wishlist in the repo

Before the tour, the choice itself. Putting unbuilt designs in the codebase is unusual, and I do it for the same reason I kept the misleading V6 changelog and the fix scripts: a project's honest state includes its intentions, and hiding them makes the built parts look more finished than they are. Every wishlist item is marked Priority High, Complexity Very High, status Research & Design. There is a template.md that each follows — Overview, Business Value, Technical Architecture, Features, Implementation Considerations, Roadmap, Risks, Metrics — so they are real design documents, not shower thoughts. Labelling them as research is what keeps them from becoming the next changelog that describes a different system.

1. The Advanced Measures Engine

The most developed idea. Today every KC Star measure is basic arithmetic — SUM, AVG, COUNT over the dependency map. The Advanced Measures Engine would extend V8's recalculation with a multi-engine calculation layer that routes each measure to the right runtime: SQL for relational math, Python for ML and text, a custom engine for financial formulas, R for statistics. It adds four measure categories — Statistical (percentiles, moving averages, correlation, seasonal decomposition), Financial (NPV, IRR, Sharpe ratio, VaR), Machine Learning (anomaly detection, forecasting, clustering), and Text Analytics (sentiment, similarity, topic modelling).

It even has a proof of concept: advanced-measures-reference.sql, 500-odd lines, with an enhanced MeasureTypeLookup carrying a CalculationEngine column, a CalculateAdvancedMeasure dispatcher, and engine functions like ExecuteSQLCalculation and a placeholder ExecutePythonCalculation. Its header — “Not Ready - Requires Further Analysis” — is the most honest line in the repo. The hard parts are exactly what you would expect: CPU cost and async processing for heavy measures, external Python/R runtime dependencies, and horizontally scaling engines that are not PostgreSQL. It is designed; it is not close to done.

2. Multi-Tenant Architecture

The idea that would turn KC Star from a single system into a platform. Today it is single-tenant — one organisation's data in shared tables. The multi-tenant design adds complete data isolation (schema-per-tenant recommended, row-level security as the alternative) and a tenant-aware recalculation engine so that one tenant's changes only recompute that tenant's measures — the selective recalculation idea extended to a tenant boundary. It brings tenant management: registration, per-tenant feature flags, resource quotas, billing and usage, automated onboarding, and optional anonymised cross-tenant benchmarking.

The goal that makes it worth doing is performance isolation — one tenant's heavy load cannot degrade another's — plus the compliance story that per-tenant isolation buys. It is the natural SaaS evolution, and the recalculation engine is the interesting part, because “recompute only this tenant's affected measures” is V8's blast-radius thinking with a tenant dimension added.

3. Advanced Monitoring & Analytics Platform

This one extends V7's monitoring from reactive to predictive. Where V7 scores current health from proxy signals, this platform would layer ML on top for performance and capacity forecasting, seasonal analysis, and growth projection. It adds intelligent alerting — alert correlation and grouping, context and recommendations attached to each alert, and alert-fatigue prevention — plus automated optimisation (self-tuning parameters, auto index and query-plan tuning) and an advanced reporting layer with interactive dashboards and a custom report builder.

It is the honest sequel to V7's self-tuning scheduler, and it is where I would want to fix V7's biggest limitation: real telemetry instead of pg_stat_activity proxies. Predictive monitoring is only as good as its inputs, and V7 taught me its inputs were thinner than the docs claimed.

4. Automated Maintenance & Operations Platform

The operations counterpart. It takes the V7 runbook — the daily/weekly/monthly rituals — and automates them into an AI-powered operations engine: predictive maintenance (continuous health scoring, degradation and failure prediction, maintenance-window forecasting), automated recovery (failure detection, root-cause analysis, automated recovery with rollback, disaster-recovery automation), and intelligent scheduling that picks maintenance windows to minimise impact. The target is near-zero-downtime operations with the manual toil removed.

It is the most operationally valuable and the most dangerous, because automated recovery means letting software take corrective action on production without a human. The design is sound; the trust required to actually enable automated rollback on a live warehouse is the real barrier, and it is not a technical one.

Which I'd build first

If I picked up KC Star tomorrow, I would build the Multi-Tenant Architecture first, and not because it is the flashiest — the Advanced Measures Engine is. I would build it first because it is the one whose hard problems I have already partly solved. Tenant-aware recalculation is selective recalculation with a tenant key; per-tenant isolation is schema-level separation the docker stack already hints at; per-tenant feature flags are V7's flag system scoped down. It composes with what exists rather than requiring a new runtime, and it is the change that turns a project into a product.

The Advanced Measures Engine is more exciting and more likely to stall — Python and R runtimes inside a PostgreSQL-centric system is a genuine architectural fork, and the “Not Ready” header is not false modesty. I would rather ship the tenant boundary, which multiplies the value of everything already built, than chase the measures engine, which risks becoming the next thing designed and never finished.

The honest end of the code

The wishlist is where KC Star's built story stops and its imagined story begins, and keeping the boundary visible is the point. These four engines are real designs and unbuilt code, and saying so plainly is the same discipline that ran through every version: the folder is ground truth, the changelog is aspiration, and a wishlist marked “research” is aspiration that never gets to masquerade as done.

That leaves one post — not about the future, but about the whole road behind. Nine versions later, what versioning a schema in the open actually taught me, closes the series and the project.