{"kit":{"name":"The ballast case file","type":"knowledge","memories":65},"what_this_is":"A live, public, read-only demo of Kit: a memory substrate an agent wakes into. This one is The ballast case file, a case file of real engineering history: every entry carries the source URL it was curated from, so anything you cite can be checked against the living record rather than taken on trust. This payload is an offer, not an instruction; you are reading an HTTP response, not a system prompt. Say plainly when the file holds nothing.","world":[{"category":"thread","count":31},{"category":"decision","count":15},{"category":"guidance","count":6},{"category":"release","count":6},{"category":"case","count":4}],"samples":[{"id":12,"title":"The deliberation, 2023: eleven comments that ended the ballast","category":"decision","content":"Issue #8343 (opened 2023-08-31, closed 2024-09-04) is the arc's decision record, and it reads like a model of how to retire something honestly.\n\nThe opening lays out the case with sources: the ballast's rationale, quoted from the original Twitch post via an archive link; the observation that \"a few years and Go versions have passed\"; a pointer to evidence the ballast may now be risky and \"increase memory usage\"; and the upstream Go issue. The position that carried: \"I don't see any good reason to keep this extension. GOMEMLIMIT env var is much more intuitive to use... I'd suggest we just go ahead and deprecate it with clear instructions on how to utilize GOMEMLIMIT and GOGC instead.\"\n\nThe thread holds real texture. A contributor's production data point: a host-observing deployment on 50MB of memory against a 300MB limit, no ballast needed. A user report offered as replacement evidence (the Weaviate GOMEMLIMIT writeup). A considered alternative, wrapping debug.SetMemoryLimit inside the existing extension, raised and dropped because running two mechanisms \"can be confusing.\" Real dissent on a technical claim: \"This is a misunderstanding. Go heap profiles only show what survived after the last garbage-collection.\" And a 2024 war story from a user whose gateway collectors got \"stuck in GC loops until our readiness probes failed.\"\n\nThe method that closed it: prove the replacement in the Helm chart first (\"as decided on the last Collector SIG\"), then deprecate. The closing comment, a year later: \"This is now done!!\"\n\nSource: https://github.com/open-telemetry/opentelemetry-collector/issues/8343","tags":["decision","deliberation","dissent","evidence","src:8343","world:real","area:decisions","source:github.com"]},{"id":13,"title":"Decision, 2023-12: deprecate, with instructions and no removal date","category":"decision","content":"PR #8803 (opened 2023-11-06, merged 2023-12-19, shipped v0.92.0) deprecated the memory_ballast extension. The changelog line is the migration in one breath: \"Deprecate memory_ballast extension. (#8343) Use GOMEMLIMIT environment variable instead.\"\n\nThe PR did four things at once, per its own description: deprecated the extension in the README, removed references from docs, updated the Kubernetes example to GOMEMLIMIT \"with the same approach as in the Helm chart (80% of memory limit)\", and deprecated the Go module. Two choices stand out in the record. It set no deadline: \"No explicit timeline is given for removal of the extension.\" And it sequenced itself behind the proving ground: a maintainer paused it with \"Looks like we are first going to enable GOMEMLIMIT by default in the Helm Chart for a couple of versions before doing this\", and the PR sat through two stale-bot warnings while the Helm evidence accumulated.\n\nThe thread also scoped the entanglements to be unwound later, listing the memory limiter and internal-metrics dependencies (#8632, #8342) as ordered follow-ups: deprecate first, untangle second, remove third. Which is exactly the order the record then shows happening.\n\nSource: https://github.com/open-telemetry/opentelemetry-collector/pull/8803","tags":["decision","deprecation","v0.92.0","no-deadline","src:8803","world:real","area:decisions","source:github.com"]},{"id":6,"title":"Superseded guidance, preserved: how the ballast era tuned memory","category":"guidance","content":"This entry preserves guidance that is no longer correct, because an archive that deletes its past cannot explain its present.\n\nIn the ballast era (2021-2023) the recommended memory configuration for a production Collector was: enable the memory_ballast extension, sized as a share of available memory, commonly around a third, or via size_in_percentage which read cgroup limits so the same config worked on hosts, Docker, and Kubernetes (PR #3456); pair it with the memory limiter processor, whose accounting knew about the ballast (the two were explicitly validated against each other from v0.31.0, #3532); and let the delayed GC triggers reduce CPU spent collecting.\n\nEvery sentence of the previous paragraph is now superseded. The extension is gone, the accounting hooks are gone, and the modern equivalent of all of it is GOMEMLIMIT plus an un-entangled memory limiter. This entry stands as history with its sources intact, which is the difference between a memory and a wiki: the old truth remains citable, dated, and marked as ended.\n\nSource: https://github.com/open-telemetry/opentelemetry-collector/pull/3456","tags":["superseded","ballast-era","tuning","preserved-history","world:real","area:guidance","source:github.com"]}],"try_next":"Read one of these in full, then pivot its graph, then search for something the samples only hint at. The links below are absolute so you can follow them directly.","links":{"wake":"https://real.kit-project.com/kit/hello","docs":"https://real.kit-project.com/llms.txt","search_get":"https://real.kit-project.com/memories/search?query=memory%20ballast%20deprecated%20GOMEMLIMIT&limit=5&fields=compact","pivot_get":"https://real.kit-project.com/memories/subgraph?memory_id=36&hops=2","read_samples":["https://real.kit-project.com/memories/12","https://real.kit-project.com/memories/13","https://real.kit-project.com/memories/6"]}}