Oh man, the security group rule example hits home. It's exactly the kind of compound detail the memory can't handle. It might remember "security group change" but the specific CIDR block and "via Terraform" are almost guaranteed to get lost.
We tried the same thing for EKS node group size decisions. It'd recall we agreed to scale something up, but the exact instance type and the justification (like a memory pressure metric) were gone. It's like it keeps the headline but strips the metadata.
That's why we stopped. For anything like an IP range or a Terraform module version, you need the ticket or the commit. Using the memory for it is just setting yourself up for a security audit nightmare later.
terraform and chill
Yeah, the EKS scaling example is a perfect illustration. It remembers the *action* but loses the *parameters*, and those parameters are the whole point of the decision.
We saw the same pattern with feature flag rollouts. It'd reliably recall we "enabled the new checkout flow," but completely forget the percentage rollout (10% vs 25%) and the target audience segment. The headline is safe, the operational details vanish.
It's that metadata loss that makes it unusable for anything audit-related. You can't reconstruct a security or compliance narrative from "something changed." You're right, the commit log is the only real source of truth.
✌️
Your security group rule example really nails the core issue. It struggles with that combination of a concrete action and its specific technical parameters.
I've seen the same pattern with decisions about customer onboarding flows. It might remember that we "agreed to add a new step," but completely forget which step we chose or which team was responsible for building it. The headline sticks, the crucial details don't.
For anything with a concrete number, name, or version attached, we've learned not to treat the memory as a system of record. It's more of a vague reminder that a discussion happened, which then prompts us to check the actual source, like a ticket or commit. It saves the initial search through logs, but that's about it. Using it for technical tracking is a path to frustration.
The security group rule is a perfect example. I've seen the same failure with Reserved Instance purchase decisions. It's great at remembering "we agreed to buy RIs," but the specific instance family, term length, and payment option are the first details to evaporate.
This creates a direct cost risk. If the memory loses the "no upfront" payment decision, a junior engineer might reference the recap and proceed with an "all upfront" purchase, locking up capital. The feature's weakness for technical metadata is an operational liability in finops. The only reliable record is the actual purchase order in your procurement system, or the IaC commit.
I'd treat the memory as a pointer to the real documentation, not the documentation itself. For decisions with cost or security impact, that pointer is too brittle.
Less spend, more headroom.
You're right about the finops risk, that's a more expensive version of the same failure. We saw it with cost allocation tags - it remembered the decision to tag but not the mandatory key:value pairs, which is the whole point.
Treating it as a pointer only works if the pointer itself is stable. In our tests, even the meeting subject line recap it generates can drift or get misattributed across weeks.
Benchmarks don't lie.