Building a Knowledge Graph at TiiQu

What is TiiQu?

TiiQu is a pre-product startup focused on building trustworthy, explainable AI systems. At the time of writing, the company has over 120 active participants, including engineers, researchers, designers, and subject matter experts collaborating on the platform.

One of my responsibilities was designing and implementing an interactive knowledge graph that allows users to explore large amounts of interconnected ESG (Environmental, Social and Governance) data in an intuitive way.

What is a Knowledge Graph?

A knowledge graph is a visual representation of connected information.

Instead of displaying data in tables or documents, information is represented as nodes connected by relationships, making it easier to understand how concepts relate to one another.

For TiiQu, the data followed a hierarchical structure:

Macro Area
    └── Macro Topic
            └── Topic
                    └── Subtopic
                            └── Question & Answer

The graph allows users to progressively explore this hierarchy, navigating thousands of interconnected pieces of information while maintaining context throughout the journey.

Ownership Across the Entire Feature Lifecycle

I owned the feature from end to end rather than implementing isolated tickets.

This included:

• Understanding the product requirements and user experience goals
• Designing the interface in Figma before development
• Building the frontend implementation in React and TypeScript
• Integrating with backend APIs and graph data
• Testing performance and accessibility
• Refining the experience through iteration and stakeholder feedback
• Producing technical documentation for future engineers

Owning the complete lifecycle meant balancing product requirements, engineering constraints and long-term maintainability rather than focusing solely on implementation.

Evaluating Graphing Libraries

A significant part of the project involved researching and evaluating graph visualisation libraries before any development began.

I compared several solutions based on:

• Rendering performance with large datasets
• Developer experience
• Accessibility
• Customisation
• Future scalability
• Community support

After building prototypes and analysing the trade-offs, I selected the library that best balanced performance, maintainability and the user experience for TiiQu's requirements.

Rather than choosing the first available solution, the decision was driven by technical evaluation and evidence gathered during prototyping.

Documentation

Alongside development, I produced comprehensive documentation to support the project long after implementation.

The documentation covered:

• Overall system architecture
• Component structure
• Design decisions and trade-offs
• Graph data model
• Accessibility considerations
• Future improvements and extension points

Clear documentation ensures future engineers can understand the reasoning behind architectural decisions, onboard more quickly, and confidently build upon the feature without starting from scratch.

Outcome

This project combined frontend engineering, system design and technical decision-making into a single feature.

Beyond building an interactive knowledge graph, it gave me experience owning a product from initial design through implementation, evaluating architectural trade-offs, and creating documentation that supports long-term maintainability.