The Petrichor Protocol in relation to established frameworks and platforms — for readers weighing it against the field.
Change management is a mature field with a substantial inheritance. ADKAR, Prosci’s larger framework, Kotter’s eight steps, Bridges’ transition model — these have shaped how organizations design and execute change for decades. The platforms that operationalize them — Howspace, the Change Compass, the Digital Adoption Platforms (WalkMe, Whatfix, Userlane), and the enterprise change modules in ServiceNow and Jira Service Management — have followed. The Petrichor Protocol works in the same broad field. It is not a replacement for any of these. It answers a different set of questions.
The questions it answers are, increasingly, the questions sustainability transitions are failing on. The established frameworks were not designed for them, and the platforms — through no fault of their vendors — are not equipped to produce them. Naming the distinction precisely lets an organization deploy each tool for the work it is suited to.
Table of contents
The frameworks that constitute change management today share a common architecture. They model change as a sequence of stages. They locate the unit of analysis at the level of the individual: change happens when enough individuals move through the sequence. The intellectual roots run back to Kurt Lewin’s unfreeze–change–refreeze model in the 1940s; the field as practitioners now know it took shape in the 1990s, alongside the large enterprise software implementations that created commercial demand for structured approaches to adoption.
This architecture has worked, demonstrably, in many large initiatives. More than thirty years of Prosci practitioner research show that structured change methodologies outperform unstructured ones. ADKAR specifically — Awareness, Desire, Knowledge, Ability, Reinforcement — gives organizations a clear and teachable framework for diagnosing where individual change adoption has stalled and intervening appropriately.
None of what follows argues that the architecture is mistaken. It argues that the architecture has limits, and that those limits are increasingly consequential in the kinds of transitions sustainability now requires.
The Petrichor Protocol operates at a different unit of analysis. ADKAR and its peers locate change at the level of the individual and treat the organization as the aggregate of individual transitions. The Petrichor Protocol locates change at the level of the practice, and the relational ecology in which the practice is embedded. The individual is one element within that ecology, not the primary unit. Three operational consequences matter most.
First, the workaround becomes data. ADKAR can identify that an individual has not reached the Ability stage of a new workflow. It cannot tell you that the reason is an informal handoff two people built five years ago, which the new workflow eliminates without replacing — and that the workflow will fail until that handoff is recognized and either preserved or substituted for. The workaround is not an adoption problem. It is operational intelligence about how the work actually gets done.
Second, the relational structure becomes load-bearing. Most organizational practice is held together by relationships no document describes. Individual-level frameworks cannot see them, because the relationship is not a property of any one person. A change initiative that severs a load-bearing relationship has not failed at the Awareness or Desire stage; it has failed at the level of the organization’s actual operational substrate.
Third, the question of consent shifts. A practice-level methodology asks whether the change has been designed with the participation of the people whose practical knowledge constitutes the organization’s operational reality, or whether their knowledge has been treated as an obstacle to be managed. The distinction is between change built with the workforce and change delivered to them. The operational difference is large.
None of this makes ADKAR wrong. It is a strong psychology of individual change adoption, and the questions it answers are real. They are not the only questions a transition is asking, and they become salient once the practice-level work has been done. ADKAR-trained change managers are often excellent collaborators on a Petrichor engagement. We are not competitors — we answer different questions, in a particular sequence, and the sequence matters.
Collaborative change platforms are useful infrastructure. Howspace facilitates large-group dialogue and clusters input into themes; the Change Compass visualizes organizational change states across departments. Both solve real problems.
Methodologically, however, these platforms are neutral surfaces. They aggregate input and visualize patterns. They do not interpret what the input means. The intelligence sits in the questions the platform is configured to ask, in the methodology that gives the aggregated data meaning, and in the practitioners who decide what to do with what surfaces.
The Petrichor Protocol is not opposed to these platforms — in many engagements we deploy them. What changes is what the platform’s outputs are for. A clustered set of frontline comments about a new CSRD workflow is not a list of adoption concerns to be addressed. It is the geosmin — the dormant operational knowledge — being aerosolized by the impact of the new workflow. The platform has captured it. The methodology decides what it means, and what should happen as a result.
Digital Adoption Platforms overlay interactive instructions on enterprise applications. They guide users through workflows and capture analytics on where users get stuck or deviate. WalkMe, Whatfix, Userlane, and their peers solve genuine problems. What follows is not an argument that they should not exist. It is that DAP analytics contain a kind of information their vendors are not equipped to interpret — and that this matters more, not less, as those analytics become inputs to sustainability reporting under CSRD and ESRS.
DAPs are designed around an implicit assumption: that the prescribed workflow is correct, and that deviation from it is failure. When 70% of users deviate from a new data-entry step, the vendor-supplied interpretation is that the step needs better adoption support. The deviation is treated as friction to be eliminated. This is one possible interpretation. It is not, in many cases, the most useful one.
A 70% deviation rate is empirical evidence about the workflow. The practice is telling its designers something they did not know when they designed it. The deviation may mean the workflow’s logic does not match operational reality; that the step requires information the user does not have at that point; that an unwritten relationship between two roles is being severed; or that the metric the workflow feeds is read as adversarial, and the deviation is a protective adaptation. None of this is visible if the analytics are read as adoption metrics. All of it is visible if they are read as ethnographic data.
This is the core move of the Petrichor Protocol applied to DAP analytics: the deviation is data about the practice, not a problem to be eliminated. The vendor’s dashboard is functioning as a sophisticated ethnographic sensor — but one whose outputs are read within a framework that assumes the workflow’s authority over the practice, rather than the practice’s authority over what the workflow needs to look like. For many of our engagements, re-reading analytics that are already being collected is the highest-leverage intervention available.
Enterprise platforms that incorporate change management as a module — ServiceNow’s Change and Risk modules, Jira Service Management’s change workflows, Prosci’s Proxima and Kaiya offerings — are governance infrastructure. They manage the approval, routing, and audit trail of organizational changes at enterprise scale.
The Petrichor Protocol’s relationship to these platforms is that of an embedded assurance practice. Where a Strategic Integrity Retainer is in place, we work alongside client teams to ensure that changes flowing through these governance platforms are not simply routed efficiently — they are routed with attention to the practice-level reality the changes will land in. Continuous senior judgment at the point where decisions are codified, before they become enterprise-wide commitments that are expensive to revise. We are doing work that the platforms, by design, do not do.
The methodological distinction would matter at any point in the history of organizational change. It matters more now because of where sustainability reporting is pushing organizational practice. CSRD and ESRS require European companies to disclose operational realities they have not historically had to make visible. The reporting is happening. The operational change the reporting was supposed to drive is, in many organizations, not happening at the pace the regulatory environment now requires.
The gap between report and operation is the gap this work is about. Reporting frameworks generate data; data alone does not change practice. Change frameworks designed around individual adoption can move staff through the awareness and ability of new sustainability workflows; they cannot ensure that the workflows themselves are designed for the practice they will land in. Digital adoption platforms can drive compliance; they cannot distinguish between compliance with a workflow that produces accurate operational information and compliance with a workflow that produces accurate-looking information the workforce knows to be incomplete.
A further structural problem is worth naming. CSRD obligations cascade. Large reporting entities require their suppliers and value-chain partners to provide data, much of which falls on small and mid-sized businesses that lack the internal capacity to generate it. The methodological burden is, in practice, being shifted onto SMBs neither resourced nor equipped to do the operational work the disclosure requires — precisely the organizations where individual-level frameworks and DAP-driven compliance regimes fail most quickly. The methodological argument is not abstract. It has a market consequence, and the market is moving.
Organizations that recognize the distinction can deploy each tool for the work it is suited to. ADKAR for individual adoption. Howspace for collaborative input. DAPs for workflow guidance and, read properly, for ethnographic signal. ServiceNow for governance.
