# Minutes of Meeting — Enterprise Brain Information Taxonomy Workshop
**Date:** February 21, 2026  
**Duration:** ~70 minutes  
**Source transcript:** [Feb 21, 2026.txt](Feb%2021,%202026.txt)

**Attendees:** Satyasri Prabhakar Mantripragada, Naveen Puttagunta, Venkatesh Tammareddy, Rajashekar G, Gopal Gottumukkala, Rakkesh Yenugudhati

## Act I — Opening agenda and constraint setting (00:00 – 05:22)

Satyasri opened the workshop by setting a long agenda: align on use cases first, then spend time on department-level planning, then come back to the table with a concrete execution path. The first correction arrived quickly from Naveen, who pushed back on the word “consolidation” because the platform is not meant to become a data lake.

> *"we are not actually going to consolidate the information at all. Information sources will be wherever they are."*
> — Naveen Puttagunta _(~00:05:22)_

That reset the rest of the session. The room moved from “move data into one place” to “build understanding across distributed sources.” Satyasri’s framing stayed useful, but the terminology changed right away.

## Act II — Knowledge versus storage (05:22 – 13:11)

Naveen clarified that the platform should connect information and infer something useful from it, not just hold copies of it. He framed the system as one that can conclude, explain, and act, rather than one that simply stores more data.

> *"consolidate is a wrong word... we are able to understand the information conclude and do something about it"*
> — Naveen Puttagunta _(~00:07:39)_

The group then separated knowledge graph from embeddings. Venkatesh explained that knowledge graph is about entity relationships, while embeddings carry semantic meaning from transcripts, emails, and similar content.

> *"knowledge graph is will talk about the relationship between the entities that we have in the system. Whereas embeddings basically what they talk about is like for example in the whatever transcript that you have described."*
> — Venkatesh Tammareddy _(~00:10:30)_

The immediate conclusion was that raw artifacts still matter as references, but the system should not confuse the artifact with the relationship model. A transcript can be embedded and linked, but the graph is what tells the system what project, feature, or person that content belongs to.

## Act III — Source families become visible (13:11 – 32:00)

After that, the discussion shifted to taxonomy. The group converged on a source split that would guide connector design and UI planning: core business applications, contextual documents, streaming or multimedia content, and contextual/personal communication such as email and meetings.

The important point was not just naming the buckets. The team kept distinguishing between source content and interpreted meaning. A meeting transcript, for example, is both a raw source and a signal about projects, decisions, and people, but those are not the same layer.

## Act IV — Complexity tiers and connector prioritization (32:00 – 50:06)

The conversation then moved into what kind of sources fit which effort class. Naveen argued that lightweight enterprise systems, packaged functional systems, and heavy ERP-style systems are not the same integration problem.

> *"if you have to look at it enterprise light will be everything associated with level one company level I can build an enterprise light for them right."*
> — Naveen Puttagunta _(~00:50:06)_

The taxonomy quickly became a planning tool. Once the team accepted that not all sources are equal, the next question was how to classify them by complexity so connector work can be prioritized properly.

The reasoning was simple: a smaller company system can be handled differently from a large ERP or a deeply structured business platform, and the product should not pretend those are interchangeable. That classification affects the promises the team can make, the effort required, and the kind of UI the system should expose.

## Act V — Shared artifact and UI planning (50:06 – 01:09:43)

In the last segment, Naveen asked for a visible connector inventory and a shared location where the taxonomy can live. The taxonomy was no longer an abstract brainstorm; it had to become a concrete artifact the team can use when deciding what to build and how to explain it.

The practical result was that the source taxonomy should help with UI planning too. If the team knows which sources belong to which family and which complexity tier, it becomes easier to decide how the dashboard should behave and how explicit the system should be about certainty and limitations.

The meeting closed with the expectation that the connector roadmap will be driven by this classification, not by ad hoc requests.

## Todos

<todo>
  Finalize the source taxonomy in a shared sheet using the four agreed families: core business apps, contextual documents, streaming data, and contextual/personal information.<br/>
  <span class="owner">Naveen Puttagunta / Satyasri</span>
  <span class="deadline">Next review</span>
</todo>

<todo>
  Map representative systems into level 1, level 2, and level 3 complexity tiers with examples for each.<br/>
  <span class="owner">Naveen Puttagunta / Rajashekar</span>
  <span class="deadline">Next review</span>
</todo>

<todo>
  Inventory the current connector coverage, especially Salesforce, Jira, SAP, and other top-priority enterprise systems.<br/>
  <span class="owner">Platform team</span>
  <span class="deadline">Next review</span>
</todo>

<todo>
  Estimate dashboard permutations for combinations of source families and complexity levels so UI planning can start from a concrete matrix.<br/>
  <span class="owner">Product / Design team</span>
  <span class="deadline">Next review</span>
</todo>