Hello HN! I built Interlock because I kept seeing the same architectural issue arise in backend code at work, where a state change starts as one update, then slowly accumulates features until the transaction logic is spread everywhere. This has been exacerbated in the AI era of hyper iterative development, and it confuses devs and agents alike.Interlock is my attempt to make that transition a single explicit unit and commit all of its durable effects together in PostgreSQL.PostgreSQL is the only supported backend right now. I was torn about some of the packaging stuff, especially the separate core and Postgres packages.The guarantees, reference app, concurrency tests, failure cases, and implementation details are all in the repo. There are plenty of powerful tools for modeling state and running workflows; Interlock is aimed at the narrower case where you want something lightweight for atomic, database-backed transitions.I’d be interested to hear whether the abstraction feels useful, where the boundaries seem wrong, or stuff I’ve overlooked.Thank you!