A framework at this stage has to disclose its evidentiary basis.
Intellectual honesty requires naming the epistemic status of the framework's claims. The research program is what moves them from grounded to calibrated.
Three kinds of claim, three different standings.
Staged on purpose.
Each phase corresponds to a different level of evidentiary claim the framework can defensibly make.
A framework that overstates its evidentiary basis is a framework that collapses under its first published benchmark.
Where the pattern recognition and the methodology come from.
I am a Staff Solutions Architect at LaunchDarkly. Before that, most of my career was spent in vendor professional services working with large enterprise clients: roughly two years at MITRE and a longer stretch at Red Hat as both an architect and a consultant in their professional services organization.
At MITRE I was part of a consultative IT organization that built rapid-prototype infrastructure for government research programs; short engagements with rotating teams forced me to align quickly to each contract's goal and let that alignment inform the technology choices I made for the developers I was supporting. At Red Hat I worked with IT organizations adopting open-source platforms, where the recurring conversation was about helping those organizations locate themselves in the value flow so they did not build things their parent organizations would not use. My current role is closer to the developer side of the same problem than the previous ones.
Across all of those engagements, the pattern I kept picking up is the same. Teams are routinely unaware of where they sit in the flow of value, which means their motivations and their problem-solving instincts drift out of alignment with the larger company initiative. Teams that produce real value but cannot articulate that value get defunded, with downstream consequences for the organization that defunded them. Cultural change initiatives stall not because the ideas are bad but because nobody can answer the question how does this make us more money in language the people who decide funding can use. RIVER is my attempt to formalize the instincts and institutional knowledge that consultative roles produce, and to give the industry a shared way of asking and answering that question.
She holds a PhD in Psychology. Her research practice spans behavioral measurement, emotional intelligence, and applied data analysis.
Her field experience includes statistical data collection with the U.S. Census Bureau in the Virgin Islands through the Eastern Caribbean Center. Her current qualitative research examines how individuals interpret and express emotions across cultural and environmental contexts, on the premise that behavior, emotional expression, and decision-making are shaped by lived experience, environmental stressors, and social context. She works from a culturally responsive frame in research design.
Her methodological orientation is mixed-methods: qualitative depth paired with quantitative measurement. The RIVER program's three phases are that orientation applied to release-era organizations.
What changed, and what I am trying to do about it.
Field observation across more than a decade has produced trends I am confident enough about to write down. It has not produced trends I am confident enough to publish as established findings.
What changed is that the trends became urgent. AI agents are entering software workflows now, and that arrival makes a long-implicit fact unavoidable. An enormous amount of organizational knowledge passes through humans implicitly: the guardrails, the routing, the value-context that human workers carry without being asked to articulate it. Agents do not carry that context. When they take over a piece of work, what gets lost is exactly the thing consultative roles exist to surface and make explicit.
I built RIVER to make those flows, and the value-context they carry, explicit. To define them precisely enough that they can be tracked, communicated, and operated on, and explicit enough that AI agents working alongside human teams can be bound by the same context the humans are. The framework's measurement claims are one surface of that work. The operating discipline of declaring release delta, attaching hypotheses, scoping success, and evaluating outcomes against declared cohorts is the deeper substrate. If AI workflows are going to inherit the value-context human teams currently carry, that substrate is what they need to be embedded in. What began here as authorial motivation is now a framework-level claim: the acceleration argument is made in full on the Why page and in the canonical statement.
I have spent my career in consultative work, not in research. The trends I have picked up are anecdotal in the strict methodological sense, and proving them out requires what I cannot build alone: structured research, a wider participant pool, and the kind of methods rigor I do not have. Dr. Parsons Willis leads the research program that anchors Phase 1; her mixed-methods practice supplies the rigor my pattern recognition lacks, and her role is what pulls me from practitioner toward researcher.
Field observation, then formalization.
The framework's six delta types, seven metric families, five maturity levels, and the central release-delta artifact were observed across software organizations operating in the release era, then named.
Each named element of the framework corresponds to a phenomenon I have watched teams either produce, struggle to produce, or operate without. The release delta is the artifact that cross-functional teams keep accidentally inventing under different names when they get serious about declaring what a release is for. The maturity ladder is the trajectory I have watched teams climb, and stall on, and skip steps in. The asymmetry between the four metrics from DORA (the DevOps Research and Assessment program) and the seven metric families in RIVER is the asymmetry of what the modern stack actually produces in operational data.
Pattern recognition is not the same as evidence. The framework's coherence across the sample of organizations I have observed is high, and consistent enough that I am confident writing it down. It is not yet empirically formalized. That is what the research program produces.
The framework, and the affiliation.
A measurement framework's credibility depends on its independence from any single vendor's product. RIVER's tool-neutrality, stated in the canonical page and built into the thesis, is what allows it to function as industry vocabulary rather than as a marketing asset.
LaunchDarkly's product is built on the operational separation of deploy from release, and watching that separation play out across customer organizations is what made it clear to me that the deploy-to-release boundary, important as it is, does not capture the whole shape of what release means in practice. In RIVER's framing, release is the full measure of value from ideation through adoption and iteration, not the moment a flag flips on. The framework extends from that observation.
The vantage point that made RIVER visible is LaunchDarkly's. The platform makes RIVER instrumentation materially easier; it is not required, and the framework is portable by construction.
DORA originated at Puppet. It became an independent firm. Google acquired it in 2018. Across all three vendor homes the framework retained credibility, because the methodology and the longitudinal data were independent of any one vendor's product. The framework's portability across platforms was a structural property, not a marketing claim.
RIVER is positioned to follow the same pattern. The research program is designed to produce data that does not depend on any single platform's instrumentation, and the framework's portability is enforced at the definitional level. The independence question matters more for RIVER than it did for DORA, because LaunchDarkly's commercial position benefits from the framework in a way Google's did not, and the framework's structure has to make that benefit incidental rather than load-bearing.
The research program is led by Dr. Parsons Willis, who has no commercial affiliation with any platform vendor. The methodology, the data collection, and the analysis are hers. RIVER's independence does not rest on its structural portability alone; it rests on who runs the empirical program. That separation is what makes commercial neutrality enforceable rather than asserted.
What RIVER is for.
RIVER exists to give software organizations a rigorous, shared, and portable way to answer the central business question their current measurement practices cannot answer: is the value we generate equivalent to, or greater than, the cost of our staff and platform?
Channels, by purpose.
-
Email
-
Sitecortsystem.dev. Personal profile and writing. RIVER lives at river-framework.dev.
-
LinkedIn
-
Phase 1 / InterviewsIf you lead engineering, product, or SRE/operations at an organization operating in the release era and want to be interviewed for Phase 1, the participation page has the details.