From 57ffb6697e307e74d395531d707eb86be4b002f7 Mon Sep 17 00:00:00 2001 From: John Coffey Date: Fri, 4 Sep 2026 16:39:54 -0700 Subject: [PATCH] Frame the Status section so its candour reads as rigour The Status section went from a table of "Shipped" straight into three paragraphs of caveats, with nothing in between telling a reader what standard was being applied. Read cold, that is a project confessing. Read with the standard stated first, it is a project that refuses to call something done because the tests pass. So the section now opens by saying what stage this is -- pre-1.0, no production workload -- and what "shipped" means here: verified against real infrastructure with a runbook recording how, including what the verification could not reach. And it says plainly why the caveats are long, which is that they are disclosed rather than discovered. A shorter Status section would not mean a more finished product, only a less careful one. It closes with what would actually close the gap: a second IdP, a real cluster, the Windows agent on Windows, sustained load, and somebody else's data. None of that is research, it is time on real infrastructure -- which makes it the list a pilot works through, and makes a 1.0 tag the wrong next milestone to reach for. Written because the risk of a public repo at this stage is not a competitor reading the roadmap, it is a prospect reading unusual honesty as immaturity. The fix for that is context, not privacy. --- README.md | 42 ++++++++++++++++++++++++++++++++++++++++-- 1 file changed, 40 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index b8bbb4a..a408a2a 100644 --- a/README.md +++ b/README.md @@ -115,8 +115,25 @@ Kubernetes deployment via the Helm chart in [`deploy/`](deploy/README.md). ## Status -Built in phases; each has a runbook in `docs/` recording how it was verified. -Full per-phase detail is in [`docs/status.md`](docs/status.md). +**Read this before the table.** Cairn OBS is pre-1.0 and has not run a +production workload. What it has done is get built in phases, with each phase +verified against real infrastructure and a runbook in `docs/` recording +exactly how — including what the verification found, and what it could not +reach. + +That last part is why the caveats below this table are unusually long. They +are disclosed, not discovered: nothing here is called *shipped* on the +strength of passing tests alone, and anything that has only been proven in one +environment, against one vendor, or not at all says so by name. A shorter +Status section would not mean a more finished product, only a less careful +one. If you are evaluating this, the honest summary is that the capability is +real and the operational mileage is not there yet — every phase has run +somewhere, none of it has run anywhere for a year under load. + +Full per-phase detail, including the verification record for each, is in +[`docs/status.md`](docs/status.md). Where the project is going, and why it is +positioned against both Splunk and Cribl, is in +[`docs/positioning.md`](docs/positioning.md). | Phase | Scope | Status | |---|---|---| @@ -154,6 +171,27 @@ because `alerting` exposes no `PUT /rules/{id}` or `PUT /targets/{id}` to update against. Tenant and RBAC resources are disclosed future work — [`terraform/README.md`](terraform/README.md) accounts for exactly what exists. +### What would close the gap to production-ready + +Named here so the list above reads as a plan rather than an apology, and so +anyone evaluating this knows what they would be waiting for: + +1. **A second identity provider.** SSO works against Auth0 for both OIDC and + SAML; one vendor is an implementation, two is a standard. +2. **A real cluster.** The Helm chart has been installed against a local + `kind` cluster, which proves the manifests and nothing about scheduling, + storage classes or node failure. +3. **The Windows agent on Windows.** The code is written and reviewed; no + Windows toolchain has ever compiled it, let alone run it. +4. **Sustained load.** Every phase was verified functionally. Nothing here has + been run at volume for long enough to find the failures that only show up + after a week. +5. **Somebody else's data.** Every deployment so far has been ours. + +None of that is research; it is time on real infrastructure. It is also +exactly the list a pilot deployment would work through, which is the honest +next step for this project rather than a 1.0 tag. + ## Contributing - Conventional commits. Every change should be a logically complete,