UNOFFICIAL/EXPERIMENTAL - maintenance and data-retention NOTE.
This note records how the catalog is maintained: the basic service level for the free public data and tests, how public data is retained over time, and where the free/paid boundary sits.
1. Free-tier SLA: a daily refresh
The basic commitment for the free public catalog is a daily update to all free public data and tests.
- Deterministic surfaces - daily. Every generated data view, index, and the public site is regenerated and verified daily (the
--generate/--verifygenerator family). These are a pure function of committed inputs, so a daily regenerate-and-verify is cheap and provable. - Tests / verifies - daily. The scoped verifiers run daily; the aggregate
npm run verifygate runs as the release check. - Live / cluster evidence - on a stated cadence, with freshness shown. Lanes that need a real cluster (local-live, GitOps/OCI, live Helm-vs-ConfigHub parity, two-cluster) cannot honestly be claimed "fresh daily" by a cheap job. They are refreshed on a stated cadence, and every row shows its freshness, so a daily data refresh never implies daily live re-proof.
Freshness is already observable: data/doc-freshness/, generated-at stamps, and the "as of commit" markers make the refresh date and staleness legible. The SLA is therefore enforceable and auditable, not just a promise.
2. Perpetual retention: keep all public data and all its changes
We retain all public data sets and all changes made to them, in perpetuity.
- Git history is the ledger. Every change to every public data set is a commit; the full history is preserved and never rewritten. The public corpus is append-only over time.
- Retire, don't delete. When a current view is rationalized away (see corpus-rationalization-plan.md), its history is retained. Rationalization keeps the live surface legible; it does not erase the past. The two are complementary: a small, legible current set plus a complete historical record.
- Why. A longitudinal corpus is itself the asset. How charts, quirks, dispositions, evidence, and upstream versions change over time supports regression detection, "what changed since" intelligence, and trend analysis that a single snapshot cannot.
Git history is the guarantee. Dated public snapshots or tags on top of it are an optional convenience for cheap time-travel, not a substitute.
3. Free vs paid boundary
The line is drawn at what is shown in the free public charts.
- Free. The public catalog: the public charts, their daily-refreshed data and tests, and the full retained public history. The free tier stays fully honest about what it shows.
- Sign-up / paid. Anything not shown in the free public charts may be available by signing up or paying. This is backed by a larger private corpus, updated daily, including new lessons, customizations, and patches - more charts and versions, deeper lifecycle and quirk work, private catalogs, and faster or SLA-backed support.
This complements the broader commercial model in verified-install-commercial-model.md; this note is specifically the maintenance, retention, and free/paid-data piece.
4. Principles
- The daily SLA is automated and verifiable, not manual goodwill.
- Retention is append-only: never rewrite public history.
- Tiering is additive: the free tier is complete and honest on its own scope; the paid tier is "more," never "the free tier with the truth removed."
- Freshness is always shown, so daily-data never implies daily-live-proof.
5. Open questions
- The automation mechanism for the daily job (scheduled CI / cron) and where it runs.
- Where the private corpus lives, and how the free→private split is enforced per data family.
- Stated cadence targets for each live lane.
- Whether to add dated public snapshots/tags on top of git history for easy time-series access.