EPOCH

Most tools judge a code change on its own. Does it build, do the tests pass, does the reviewer approve it. That works for one change. It stops working when changes pile up. Each one looks fine, and a few months later parts of the code reach into each other, the system is harder to change, and an incident shows up that nobody can explain. This gets worse as AI agents write more of our code. In the SWE-EVO study (2025), GPT-5 with OpenHands solved 65% of single issues but only 21% of tasks where a codebase has to evolve over many steps. Agents are good at the next change. Nobody is watching the whole journey. EPOCH is the missing memory. It sits next to a codebase and keeps a record of what the system has become. Every approved change is saved with its reason, who made it and who approved it. After each change, EPOCH scans the code, checks the rules the team has written down, and tracks a few simple health scores over time. When the scores drift, it raises a finding. When something breaks, it traces the earlier changes that most likely led there and says how sure it is about each link. IBM Bob does the hands-on work through EPOCH's MCP tools. Before Bob touches the code, it reads the history and the rules. Each change runs as a tracked workflow: a plan, EPOCH's checks, the edit, and a request for approval. Bob has no approve button, so a person always makes the final call. When the system is in trouble, Bob builds two possible fixes side by side, each in its own copy of the code, and EPOCH measures both like real changes. The team then chooses with numbers in front of them. Our demo follows a small payments service. Bob extends the chargeback window from 15 to 30 days. The tests pass, but EPOCH warns that a rule linking disputes to ledger retention will weaken. The business approves it anyway. Three quick AI changes follow, and each one passes its tests. Meanwhile the boundary score falls from 1.00 to 0.50 and a real incident appears. A dispute filed on day 20 can no longer find its settlement, so the customer's money is frozen. Bob asks EPOCH why and gets the likely chain of three changes. Bob then builds two futures. Keeping the current path scores 0.75. Restoring the boundary scores 1.00 with all 11 tests passing. A person adopts it, Bob takes it to the approval gate, and the approval closes the incident and brings the system back to health. What it caught: four changes made the system worse, and every one passed all 11 tests. EPOCH flagged all four. The first warning came at review, two changes before the incident. Bob got the likely chain of changes from EPOCH in about 2 seconds, and two Bob subagents built and measured both fixes in 72 seconds, against 106 seconds one after the other. What we built: the EPOCH engine and API, the MCP server Bob uses with 21 tools, a landing page that tells the story, a live console with four views (current work, history, trajectory and futures), an evolution report, Bob modes, skills, commands and hooks, a sample service with its own history, an automated test suite, and a public demo anyone can try. Try it: open the live demo, read the story on the first page, then open the live console. Go to Futures, adopt future B, run the checks to the gate and approve it. Every number in the README comes from EPOCH's own measurements.