Hypothesis
Software engineering organizations preserve artifacts better than they preserve reusable understanding.
Rationale
Engineering work produces durable traces: commits, pull requests, issues, logs, incidents, documents, chats, dashboards, and releases. These traces show that work happened, but they often do not explain what should be learned, reused, avoided, or improved next time.
The result is weak compounding. Teams can have abundant artifacts and still repeatedly rediscover the same boundaries.
Testable Questions
- Can a future engineer or agent find the lesson without replaying the whole artifact trail?
- Does the lesson point back to the owning source of truth?
- Is there a clear reuse path for the next workflow, incident, review, or implementation?
- Can the lesson be revised when the operational reality changes?