The same three frustrations keep coming up in conversations with portfolio leaders, product executives, and engineering directors.

The first is forward-looking. They are about to greenlight an investment, and they cannot tell whether the thing being built will deliver the value they need it to deliver. They have estimates, business cases, and roadmap slides. None of those tell them what the world will look like if the release succeeds.

The second is downward-looking. They have already made the strategic call. The portfolio is set, the priorities are clear, the funding is allocated. What they cannot see is whether those choices are being operated on faithfully down the chain, or whether the work that emerges six months later resembles the intent that started it.

The third is backward-looking. Something shipped. Was it worth it? The deploy happened, the dashboard turned green, the team moved on. The executive is left trying to attribute outcomes to causes across a window of time long enough that everything has changed at least twice.

I have spent the last several years at LaunchDarkly, where releasing software in production is the entire job. I have watched these three pains show up in nearly every customer conversation, regardless of company size or industry. They are not measurement problems in the usual sense. They are not problems of “we don’t have the right dashboards.” They are problems of frame.

Here is the frame most of us are working with, and the one I think we need to move to.

Release as a step

For the last decade, the most influential measurement work in our industry has been DORA (the DevOps Research and Assessment program). DORA gave us four metrics, deployment frequency, lead time for changes, change failure rate, and time to restore service, that captured how well an engineering organization was performing as a delivery engine. They were the right metrics for the question they asked, and the question they asked was important: how fast and how reliably can this team get code from commit to production?

But notice what that question treats release as. It is the moment the code crosses the line. The metrics start when work begins and end shortly after deploy. Everything before the commit and everything after the deploy is outside the frame.

This is fine if you accept that release is a step in a longer process. Most of our tooling, our team structures, and our planning rituals do accept that. Product decides what to build, engineering builds it, release ships it, and someone, somewhere, eventually figures out whether it worked.

Release as the lifecycle

The frame I am arguing for is different. Release is not a step. Release is the entire arc from the moment someone forms an intent (“we should build X to produce outcome Y”) through the moment that intent has been deployed, rolled out, evaluated, and either confirmed or refuted by the world.

Under this frame, the deploy is not the end of the release. It is roughly the midpoint. What comes after the deploy, the controlled rollout, the measurement of adoption, the comparison of outcome against the original hypothesis, is as much a part of the release as the build that preceded it.

This is the reframe I have been calling RIVER (Release Impact and Value Evolution Reporting). It is a framework for measuring the full release lifecycle, from ideation through learning, with a vocabulary for declaring intent, a taxonomy of intent types, a maturity ladder for organizations to locate themselves on, and a set of metrics that travel across the whole arc rather than concentrating around the deploy.

I want to be careful about how I position this next to DORA, because the relationship is genuinely additive. DORA measures one slice of the lifecycle, and it measures it well. RIVER extends the measurement frame across the slices DORA was not built to address. If your organization has invested in DORA, that investment is preserved. RIVER picks up where DORA’s frame ends.

Why this resolves the three pains

The forward-looking pain resolves because RIVER requires intent to be declared before work begins, in a form that is later measurable. The backward-looking pain resolves because the intent declared at the start becomes the ground truth against which outcomes are evaluated. The downward-looking pain, the one about whether decisions are being operated on faithfully, resolves because intent becomes a contract that travels with the work, not a slide that lives in a portfolio review deck.

None of this is free. The framework asks more of the organization than DORA does, because it asks for measurement across stages where most organizations currently have no measurement at all. The maturity ladder exists for that reason. Most teams will not start at the top, and that is fine.

What comes next

I have written up the framework in full at river-framework.dev. The canonical page describes what RIVER is, the thesis explains why I think the category needs this, and the glossary defines the terms. Phase 1 is open for practitioners who want to work with the framework and contribute to its evolution.

One last note. RIVER is about defining clear intent and measuring our ability to deliver against it. That work has always mattered. It will matter more as agentic workflows become a larger part of how software gets built, because an agent can only be bound by context that has been made explicit. I will write about that in a future post.

If you read the canonical page and have a reaction, positive, skeptical, or somewhere in between, I want to hear it. Reply here, comment, or reach out directly. The framework is in a phase where the most useful thing it can do is collide with the experience of people who have lived these three pains.