An introduction of the Knowledge Base

Your workspace's collective memory, mapped out.

That's the shortest definition of what I'm building next for Tamarind. One that I've been eager to do for a while.

I call it the "Knowledge Base".

In a nutshell, it's just a visual representation of all the subjects that you, as workspace member, have been working on recently. A network graph of interconnected, weighted accumulated knowledge where nodes represent ideas or themes, shared across multiple app entities, and the edges show the proximity between two topics inside the same asset.

For example:

• node A represents "transient errors on the checkout process"
• another node, B, shows "Stripe API misconfiguration for EMEA markets in august"
• an edge connects those two nodes because both topics where discussed at some point inside the same conversation
• a third node, C, says: "Minutes from Gamma team meeting regarding checkout bugs"
• C is connected with both A and B because, even though it comes from a page, the page was created from within the same conversation

Chart features

While edges between nodes represent deterministic proximity between ideas or topics, due to entity relationships, the location, size and color of the nodes inside the graph also matters.

Proximity among nodes indicates semantic similarity, that is, cosine similarity between embeddings. In other words: mathematically speaking these two texts have some things in common.

Size represents volume of evidences: how many times users talked about things that reinforced a specific topic. A few messages here and there can generate a new conversation topic, but it will require more for the topic itself to gain weight.

Color, or more precisely shade or tone, tells us how active this theme has been lately. A topic might have had a very strong impact among users in the past: lots of messages shared about the same things, reinforced with pages also being written with content related with the topic. But if that activity only happened months ago starts losing relevancy. A dimmed tone of color indicates the topic is old, and is been a while since no one mentioned it.

Canonical knowledge

But here's where things get tricky. The real challenge comes from the actual concept of "application idea". We need to find the way to abstract each topic's provenance into a standardized idea. And then build a solid UX/UI plan to portrait this "knowledge base" while it keeps scaling up, as users keep adding more content to the workspace.

Users care more about ideas more than provenance. We are giving them both.

Conversation might generate many topics that evolve with time, they can become more or less relevant over time as new messages are written. And pages might also have one or two themes associated. But the real problem here is harmonizing these different domains into an abstraction of a higher level. A transformation layer that reads the themes from multiple different entities and normalizes them into canonical application topics. Users care about ideas or topics at first glance. It's our job to figure out which semantic entities —across conversations and pages— reinforce each idea.

Going back to the previous example: nodes A, B and C could be all merged into a single one, blending the meaning of all of them into a single abstraction: "Checkout API issues in EMEA".

The information is all there already, this is just a way to simplify what otherwise could rapidly become a gigantic spider web of atomic concepts, some interconnected, most isolated.

Once we solve the harmonization challenge, we will be able to ship the Knowledge Base as the latest addition to Tamarind on the navigation panel's rail.