Comment by vector_spaces

> Our other tool, HyperTwin, tackles the “tribal knowledge” problem. It learns directly from subject-matter experts, observing workflows, analyzing screen interactions, and conducting AI-driven interviews to capture how they debug and reason about their systems. The goal is to build digital “twins” of the experts on how they debug, architect, and maintain these systems in practice.

How do you consolidate this knowledge across disparate teams and organizational silos? How will you identify and reconcile subtle differences in terminology used across the organization?

Perhaps I misunderstood, but on your website you primarily identify technical implementors as SMEs. IME modernizing legacy data systems in high-stakes environments, the devil is more on the business side -- e.g. disparate teams using the same term to refer to different concepts (and having that reflected in code), or the exact stakeholders of reports or data systems being unknown and unknowable, and discerning between rules that are critical to a particular team or workflow that are opaque to you because e.g. you don't know who all relies on this data or are missing business context, or because the rule is not actually used anymore, or because the implementation of the rule itself is wrong.

Besides, both technical and non-technical stakeholders and SMEs lean heavily on heuristics to decision with the data they are looking at, but often struggle to explicitly articulate them. They don't think to mention certain conditions or filters because for them those are baked into the terminology, or it doesn't occur to them that the organization deals with broader data than what they interact with in their day-to-day.

And unfortunately in these settings, you don't get many chances to get it wrong -- trust is absolutely critical.

I am skeptical that what you will end up with at the end of the day will be a product, at least if your intent is to provide meaningful value to people who rely on these systems and solve the problems that keep them up at night. My feeling is that you will end up as primarily a consultancy, which makes sense given that the problem you are solving isn't primarily technical in nature, it just has technical components.