This article is based on an interview with Matthew Wimberly, CTO and co-founder at Chiri.
Chiri talks about “company memory” and “ontology” often. The idea did not start in a product meeting. It started on a wastewater plant in Maricopa, Arizona, in 2019.
Matthew Wimberly, Chiri’s CTO and co-founder, spent part of his career running that plant before he built software. The path from a physical digester to an organizational ontology runs through a personal note-taking habit. It runs through a client conversation Wimberly never forgot. That path explains why Chiri builds what it builds, and why business continuity sits at the center of it.
A digester, not a dashboard
Wimberly’s first digital twins had nothing to do with knowledge work. They tracked a piece of physical equipment, and the margin for error was small.
“Our digital twin was for a 6.25 million gallon digester. We had six of them,” Wimberly said. The stakes were physical, not abstract. “We had to really care about those digital twins because if the digital twin was wrong, then there’s hydrogen sulfide, and I die at two parts per million, or whatever the number is, when I’m walking around.”
Matthew Wimberly
A wrong model on a plant floor is not an inconvenience. It is a safety failure. That standard shaped how Wimberly thought about accuracy long before he applied the idea to companies.
The twin also protected equipment. A $500,000 grinder processed everything that came through the plant, including cow magnets. A cow magnet is a small magnet farmers place inside cattle to catch swallowed metal. “Those cow magnets get stuck in grinders, and then they start to rip apart these $500,000 machines,” Wimberly said. “And it was very expensive.”
The plant built digital twins for preventative maintenance, to catch that kind of failure before it happened. The twin existed to prevent a costly or dangerous surprise, not to keep a record for its own sake. That distinction carries forward into how Chiri defines the term today.
From personal notebooks to company memory
The next stop on this path was not industrial. It was personal, and it came before Wimberly connected the idea to artificial intelligence at all.
Wimberly built his own Zettelkasten system, a note-linking method popularized by tools like Obsidian. The method asks a person to capture every note, then link related notes together over time. A structure builds one entry at a time. He used it to capture ideas and connect them as he worked. “I had 400 blog posts in the span of about a year and a half,” he said. “I really did have all my knowledge at my fingertips.”
That personal system was an early, individual version of a digital twin: a record detailed enough to represent one person’s thinking, searchable in a way memory alone is not. It only covered what Wimberly chose to write down, which is the same limit every personal knowledge system carries.
Wimberly connects that experiment directly to what large language models made possible later. “What I was realizing with AI is that the digital twin side comes out when you have enough contextual grounding in work that you’ve done,” he said. A model needs history to represent a person or a company accurately. Wimberly’s own notes needed a year and a half of entries before they became useful.
He is careful about what that grounding is for. Writing in someone’s voice is a small use of it. “Could it do marketing in our brand voice? Yeah, we could do that with a single prompt. You don’t even really need ontology for that,” Wimberly said. The real use of an organizational digital twin sits elsewhere, past style and into the structure of the work itself.
What an ontology actually maps
An ontology, in Chiri’s use of the word, is a structured map of how work moves through a company. It does not just store outputs. It stores the path each piece of work took, and who touched it along the way.
Wimberly described the kind of chain an ontology can trace: “The Slack message that started up me looking at the contract, that started the revisions, that then went to finance, that then went back to the SDR team, that then got approved and signed the client.”
That chain crosses departments, tools, and individual employees. Mapped correctly, it turns scattered activity into a structured record a company can search, hand off, and build on. “The company now has this value accretive intellectual property,” Wimberly said.
Most companies do not have that record today. Work happens, gets approved, and moves on to the next stage, but the path itself is rarely captured anywhere durable. A contract gets signed and everyone moves to the next deal. What remains afterward is not a record. It is the memory of the people who did the work, scattered across inboxes, chat threads, and individual recollection.
The internal Rain Man
Wimberly points to one client conversation to make the risk concrete. The client had an employee approaching retirement, someone whose knowledge no one else in the company held.
The client described him this way: “We’ve got this guy that’s retiring, and he’s our internal Rain Man.”
Wimberly’s reaction to that phrase was immediate. “Rain Man scares me, and the reason Rain Man scares me is because you have no idea what that guy does all day,” he said. “You know what his output looks like. You know the value he produces, because you pay him a salary. But the intangible value, that tacit knowledge that lives within his mind, is going to go away.”
The company knew the salary. It did not know the process. Years of decisions, shortcuts, and judgment calls existed only in one employee’s head, with a retirement date already set. “We’ve got a clock on the wall, and it’s a couple months,” Wimberly said.
Nothing about that employee’s knowledge was written down anywhere the company could search. His salary was a line item. His method was not documented anywhere. When he left, the company would lose a working method it never fully understood. No amount of notice would recover it afterward.
Business continuity is the point
Wimberly names the actual reason Chiri builds ontology systems, and it is not a productivity pitch. It is risk management, stated in plain terms.
“When you start thinking about what’s the purpose of an ontology, it’s for business continuity, because business continuity is the most important thing when it comes to running a business,” he said. “You’re there to generate revenue.”
An ontology, in this framing, is not primarily a tool for speed or automation. It is a record that lets a company keep operating when a person holding critical knowledge is unavailable. That covers retirement, illness, and departure. Speed and automation can follow from that record, but they are not the reason it exists.
One HR department, three people, one scramble
The Rain Man story describes a single point of failure building toward a known date. Wimberly also described a version of the same problem, arriving without warning and spread across a team.
“We heard this yesterday. We’ve got three people that are out on medical leave in an HR department,” he said. “They don’t have access to stuff, and they don’t know what that work was, or the workflows that they were doing.”
The result was not a paperwork delay. It stopped normal department function. “They’re now in a scramble for a period of months,” Wimberly said. “That means that an entire department of a company is currently hobbled, hopping on one leg.”
No single person in that story did anything wrong. The workflows lived only in three individual minds, with no shared record anyone else could act on. When those three people became unavailable at once, the gap became visible immediately. It surfaced at the exact moment the company could least afford to close it.
Wimberly frames the fix as advance mapping, not crisis response. “You could plan ahead better. You could start to map those workflows ahead of time, so that you know exactly what job function every single person is doing, and what work is being done,” he said.
Mapped workflows also guide growth
Wimberly extends the same mapping to growth decisions, not just risk. A company that has already mapped its workflows can use that map to plan hiring, beyond surviving a departure.
“It comes time to upscale your team, you say, we’re growing this year, excellent, great problem to have, we need to now go from 10 staff to 20 staff. How many of every job function do we need to hire?” he said.
A mapped ontology gives a company evidence for that decision, instead of a guess based on who seems busiest. “You’d be able to make decisions based on what the ontology is telling you, and what the agents are capable of recommending, based on the workflows that you’ve mapped within the system,” Wimberly said. The same record that protects a company against loss also tells it where to add people next.
This lands differently depending on where you sit
For a CEO or founder: the Rain Man story is a balance-sheet risk with no line item. A company can pay a salary for years without ever recording the knowledge that salary produces.
For an HR or operations leader: the medical-leave story is a preview of a normal event, not a rare one. People take leave, retire, and change roles regularly. Workflow mapping done in advance turns a scramble into a handoff.
For an IT or data leader: Wimberly describes a shift from a mechanical digital twin to an organizational one. That shift reframes ontology work as infrastructure for continuity, not a knowledge-base project layered on top of existing tools.
For a hiring manager planning growth: a mapped ontology answers a staffing question with evidence. It shows which job functions carry which workflows, instead of leaving headcount decisions to instinct.
For a new employee or a successor: the same record is the difference between inheriting a role and inheriting a blank slate. A documented workflow can be handed over. A retired colleague’s memory cannot.
The question underneath the story
Wimberly’s path ran from a digester in Arizona to a personal notebook to an organizational memory system. The question at the center never changed: what happens to the work when the person who did it is gone.
What would your organization lose if one person did not come in tomorrow?