From cbd5b11ebb25ce738f4b8c051d31fdd99812debf Mon Sep 17 00:00:00 2001 From: "@jaydenOoOo" Date: Sun, 9 Aug 2026 21:45:43 +0800 Subject: [PATCH] Correct the findings count, the cut table, and DELPHI's place in the portfolio Three things a reviewer meets early and none of them were right. The README headed four numbered findings 'The three findings'. Q13's negative was added as a fourth and the heading was not. docs/ROADMAP.md carried a blank line inside the 'Cut, and why' table, which ends a table in GitHub-flavoured markdown: M18, M19 and M24 rendered as literal pipe-delimited text rather than rows, so the three cuts that most need explaining were the three that did not render. The four sibling repositories cross-reference each other and none of them names DELPHI, so the newest project sat outside the portfolio it belongs to. It now states the relationship and, more usefully, the distinction: those four are detection systems, this one is a decision system. --- README.md | 11 ++++++++++- docs/ROADMAP.md | 1 - 2 files changed, 10 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index 46a7396..fcd670e 100644 --- a/README.md +++ b/README.md @@ -8,13 +8,22 @@ series and get a verdict. On a free tier, so the first request after an idle per about a minute to wake the container; the snapshot is baked at image build and the badge says `demo` because it is. +> **The infrastructure lane of the portfolio.** Sibling to +> [SENTINEL](https://github.com/jadoon200/sentinel) (cyber threat intelligence), +> [ARGUS](https://github.com/jadoon200/argus) (all-source fusion), +> [PHAROS](https://github.com/jadoon200/pharos) (maritime) and +> [HORUS](https://github.com/jadoon200/horus) (air). Those four are detection systems: +> signal → anomaly → incident → human review. DELPHI is a decision system: forecast → +> uncertainty → cost-weighted choice → plan → measured consequence. The evaluation problem +> differs in kind, because you have to reason about an action you did not take. + DELPHI set out to show that a calibrated forecast beats conventional autoscaling. Measured against the recommender Kubernetes actually ships, it mostly does not. The useful result is the boundary: forecasting pays when capacity is committed for hours at a time *and* demand has real daily structure, and a single number you can compute in seconds tells you which side of that boundary you are on. -## The three findings +## The four findings 1. **In the autoscaling regime, forecasting loses to a trailing percentile.** Demand is ~0.98 autocorrelated at one minute on every workload measured here, so recent load diff --git a/docs/ROADMAP.md b/docs/ROADMAP.md index f0bc237..90d515b 100644 --- a/docs/ROADMAP.md +++ b/docs/ROADMAP.md @@ -31,7 +31,6 @@ marketing document. | Milestone | Decision | Reason | |---|---|---| | M9–M13 — specialist agents | **Cut** | The pre-registered cut order chose the GPU lane over the agent layer when the two competed for the same days. The agent layer's own pre-registered expectation (Q5) was that it would *not* improve decision quality, only auditability — so cutting it removes a likely-null result rather than a likely finding. The decision ledger it would have written is not claimed anywhere in the product. | - | M18 — Alibaba spot-GPU | **Cut** | No licence file at the repository root; the zero-cost audit will not redistribute or depend on unclearly licensed data. | | M19 — carbon-aware deferral | **Cut** | Elegant, not load-bearing. First on the pre-registered cut list. | | M24 — live Wikimedia lane | **Cut** | Replay carries the argument; a live arrival process is presentation, not evidence. |