Ask most organizations to describe how a given process runs today, and you will get several different answers depending on who you ask. That gap between how a process is documented and how it gets done is the starting point for every re-engineering engagement, and it is where this latest blog in our ProcessOS series picks up.
We have covered a lot of ground getting here, including what ProcessOS is and why we built it, what customers are asking as they evaluate it, and how two banking teams are already putting it to work. All of that work runs on discovery—the phase where ProcessOS reconstructs how a process runs—so it deserves a closer look on its own.
The problem discovery solves
Every re-engineering effort starts with the same question: what is happening in this process right now? Most organizations cannot answer that question with confidence. Documentation drifts out of date the moment someone updates it, because keeping a static document current takes ongoing effort that nobody has time for. Ownership shifts as people move roles or leave the company, and the knowledge they carried leaves with them. What remains is a patchwork of exports, spreadsheets, Word documents, and institutional memory scattered across the people who do the work every day.
Discovery exists to reconstruct the real picture from that patchwork, and it happens fast. Work that traditionally consumed two to three months of workshops now happens in one to two weeks just by feeding all existing documentation into ProcessOS.
Where does process knowledge live in most organizations?
The more unstructured data you feed ProcessOS the better it performs. That statement runs counter to decades of legacy BPMS practice, where teams spent months cleaning and structuring data before a process automation tool could use it. ProcessOS inverts that expectation. It takes advantage of what large language models (LLMs) do well, which is finding patterns and relationships across written material regardless of its original format.
In practice, that unstructured material comes from several places at once. Many organizations already have BPM tooling in place, and organizations often export their business processes with a BPMN diagram. While these diagrams are rarely perfect, ProcessOS does not need a clean import. It reads what those exports contain and extracts the process logic inside them.
Alongside those BPMN exports sit outputs from other systems, handbooks, documentation, emails, meeting notes, screenshots, and any other written record a team has produced about their process over the years, all of which becomes fuel for discovery.
The third and often most revealing source is the subject matter experts who run the process day to day. For example, asking questions of those SMEs frequently brings up discrepancies between two pieces of documentation that were never reconciled—a quick conversation provides important input on which version reflects reality.
These conversations often prompt teams to notice, for the first time, that two departments have been running the same process differently for years. This is also where the work of our Forward-Deployed Engineering team, which we detailed earlier in the series, starts to matter most: someone still needs to sit with the business and make sense of discovery inputs, even as the tooling does most of the heavy lifting.
From strategic model to executable process
The first outputs of discovery are BPMN diagrams: a visual, human-readable representation of the process as it actually runs, built for alignment rather than execution. That distinction matters. Strategic models give SMEs and stakeholders a shared reference to react to, correct, and confirm, which is a much easier task than parsing scattered documentation line by line. And, shared visual models provide a peek into subsequent ProcessOS phases..
From there, ProcessOS moves into transformation, where automated steps derive executable BPMNs from the strategic one. The strategic and executable models stay tied to each other. The executable versions can evolve as the process gets built out, but it will never represent a fundamentally different process than the one the strategic model captured. That link between the strategic and executable layers is what lets a business validate direction early, before any build work begins, and know that validation still holds once the process goes live.
Discovery does not stop at go-live
Most discovery tools treat the initial pass as a one-time event. ProcessOS treats it as a capability the business can call on again whenever something changes. If a team expands the scope of a process, encounters a new regulatory requirement, or simply wants to test a change before committing to it, they can feed that update back into ProcessOS the same way they fed in the original source material. A recorded conversation, a screenshot of a new policy, or a plain description of what needs to change is enough to trigger a fresh discovery pass grounded in what is already running in production.
Take a financial services company that needs to adapt a compliance process to a new regulation. Instead of scheduling another round of workshops, a team can share the regulatory update directly with ProcessOS and let it propose the adjustments the existing process needs to stay compliant. The system rediscovers the process, incorporates the change, and hands back a model ready for review, all without starting from a blank page.
Why discovery keeps getting faster
Because ProcessOS builds discovery on agents, the capability improves as the underlying models improve, and that trend shows no sign of slowing. The tasks these models can handle keep expanding in scope while taking less time and computing power to complete. ProcessOS is built to take advantage of that trajectory automatically, so a discovery pass run next year will draw on meaningfully more capable models than one run today—without requiring any change to how a business works with the product.
That compounding advantage is part of why the discovery timeline keeps compressing rather than holding steady. A capability that already replaces months of workshops with one to two weeks of work has every reason to keep getting faster from here.
