Hey community! Chris here from the Palantir product documentation team. We’re launching monthly AMAs with our product teams to share what’s happening behind the scenes and hear from you about your experiences with our products.
This AMA will run asynchronously from Wednesday, September 24 through Wednesday October 8, with Ontology Manager and Frontend team members monitoring this thread daily and responding to your questions and comments.
For our first AMA, I sat down with Tomasz, team lead for Ontology Frontend. We talked about performance improvements, surprising user creativity, and what’s coming next.
Feel free to drop your thoughts in the comments below, and know that we’re capturing your feedback to help shape what gets prioritized and built next. Without further ado, here’s Tomasz:
-
Hi Tomasz, how long have you been at Palantir, what is your team, and what do you do within your team?
- I’m currently a team lead of Ontology frontend. By next month, I’ll have been at Palantir for 4 years. Our team manages the Ontology Manager application and how frontend ontology components work across the platform. We guide where ontology primitives are headed, striving to keep them useful for developers. I do a bunch of things - manage feature prioritization and help other teams contribute to the ontology, as well as mentor junior devs on the team, make contributions to the product, and finally, I try to do some coding if I find time.
-
What is the main problem Ontology Manager aims to solve?
- Ontology Manager is meant to be a default home for management, editing, and discovery of your ontology. It also serves as the exhaustive source of truth for the ontology, since you can also use other Palantir platform applications to interact with the ontology, such as editing it through Pipeline Builder, installing it through Marketplace, and more. In short, you’re meant to be able to edit and visualize your ontology in Ontology Manager.
-
How did Ontology Manager change from its initial design (story from development)?
-
It was largely different from when I joined. While I wasn’t on the team at the very beginning of the Ontology frontend team’s history, I can share that Ontology Manager was not accessible to customer users when I was interning here. At that time, the ontology was managed by Palantirians only. Similarly, it only supported object types and link types back then, with the linkage being called “relations”. There was also only one ontology. This meant that you had no option of having multiple ontologies within a single enrollment to organize and separate different use cases. And lastly, the ontology was loaded at the time of the application start up - as at the time, ontologies were super small and not as in wide use as today. To scale up both in number of ontology resources, and different primitives that ontology have (actions, interfaces, shared properties, etc), different data source types, and storage - the scope of the application has grown a lot since then.
-
You can see some old screenshots of the Ontology Manager below (The Object type panel and Sync management screen):
-
-
Can you share a real-world success story where a developer or team achieved something notable using your product?
-
While I’d say that Ontology Manager is not that ground breaking as a part of the Foundry suite of applications, Palantir’s ethos is that the ontology is the crux of an organization, and we do see that 99% of the problems solved in-platform are solved through the ontology.
-
One funny story I can share about how far we’ve come: A developer at a client site told us he used to treat himself to a cup of coffee with every Ontology Manager edit. It was his way of staying productive while the system processed his changes. As much as we love coffee ourselves (and trust me, we do), this feedback drove us to prioritize major performance improvements:
-
Rebuilt the architecture for scale: Ontology started small, but as usage grew, we realized the original design couldn’t handle loading large amounts of information to the frontend. We re-architected the application to use lazy loading and strategic pre-loading for optimal performance.
-
Moved processing to the backend: We invested in improved APIs to handle heavy operations on the backend instead of burdening the frontend, creating a smoother user experience.
-
Ongoing optimization: We continue identifying and addressing performance bottlenecks as the product evolves.
-
-
-
What’s the biggest technical challenge your team has solved in the past year, and what did you learn from tackling it?
-
We’ve tackled some major architectural challenges recently. The biggest one was our lazy loading migration last year. We completely changed how Ontology Manager handles data, moving from fully loading everything upfront to only loading what’s actually needed for display. This sounds straightforward. Spoiler: It wasn’t. It broke a lot of fundamental assumptions in our codebase. Historically, ontologies were small enough that we could just load everything at once, so developers wrote code assuming all data was already available. We had to go through the entire system and convert synchronous operations to asynchronous ones, which was a massive undertaking.
-
Another significant project was migrating type groups from being type classes to becoming first-class features. This was a large-scale migration, but it was worth it because it enabled us to use search effectively and improved performance across other applications like Object Explorer. The tricky part was making this an automatic migration while preserving security. We wanted users to seamlessly transition without any manual work, but we had to ensure that type groups maintained exactly the same restrictive security domains as the old system. There were significant security implications to consider, so we had to be extremely careful about how we handled that migration.
-
-
What’s the most creative way you’ve seen developers use our product that made you think “wow, we never intended that, but that’s cool”?
- People are building meta-ontologies, essentially creating ontologies about their own ontologies. They’ll create object types that represent “all object types” or “all objects on the platform” and then push this metadata to Workshop for analysis. This gives them insights into their own Foundry system: how many object types they have, who owns them, and usage patterns. It’s fascinating, almost like building a programming language and then creating a compiler for that same language. What surprises me is how often this happens. Clients are building sophisticated apps that no longer rely on our standard ontology creation tools. For example, while Foundry has built-in access request workflows, one client’s needs were so advanced that they built their own custom workflow and Workshop app to handle access requests. They’ve essentially created their own system within our system. And we love to see inspired usage like this.
-
What’s something that really shows you how passionate developers are about building on our platform?
- Often when we get feature requests, we also hear about the ingenious problems-solving approaches they’ve developed in the meantime. One of the most impressive examples, shared with me by another peer, goes back about 8 years when we didn’t yet support array properties (the “allow multiple” feature). There were developers who built an incredibly sophisticated product that not only used arrays extensively but even had support for nested arrays by creating an elegant encoding system. They developed a method where they’d encode specific IDs to indicate array types, essentially building their own array infrastructure on top of our platform. That’s probably the most foundational feature I can think of where users managed to architect their own solution. It really showcases the resourcefulness and technical creativity of our developer community.
-
Which feature do you think is most underutilized, and what’s your elevator pitch for why developers should give it another look?
- I think object type groups, statuses, and visibility settings are hugely underutilized. Most developers don’t realize how much these features can transform their search experience and help them find the right resources quickly. I get it, setting up metadata isn’t exactly thrilling, but hear me out… You’re already creating metadata for your objects anyway, so why not leverage that existing work to dramatically improve discoverability? By properly setting up object type groups, statuses, and visibility, you’re essentially creating a smart filtering system that makes search results actually useful. Instead of wading through hundreds of irrelevant results, you get exactly what you need. The best part is how easy it is to implement. You can set this up directly from the overview page and apply it immediately. There’s no complex configuration or additional tooling required. Really, it comes down to discipline. If teams just make it a habit to set statuses and organize their object types properly, they’ll save themselves countless hours of searching through cluttered results. It’s one of those small investments that pays big dividends.
-
Can you share an example where community feedback was positively enacted?
- Honestly, there are tons of examples. We work hard to capture the issues reported by our users, with the developer community being one form of input, which is then documented into a list and we work on fixing them on company-wide allocated “hack days”. We also capture feature request information from the community to understand what features we can introduce to benefit the most users. We keep our eyes on the community for the most part, and we’re grateful to be recognized for our speed in providing fixes by the public, sometimes through a tweet!
-
Can you tell me about a time when user feedback challenged your assumptions about what would be valuable to them?
- Here’s a story that initially felt counterintuitive but made perfect sense once I understood the user perspective. When we rolled out our new link type creation wizard and demoed it to customers, we expected positive feedback on the clean, polished interface. Instead, users told us they’d never actually use it. Their reasoning was brilliant: “If the configuration page still uses the old UI, there’s no point learning this new wizard since we’ll only see it once. We’d rather just go straight to the configuration page and learn that interface instead.” This feedback was a lightbulb moment for our design team, who immediately worked to bring the new UI to the configuration page as well. It taught me that what seems like a simple improvement (adding a nice wizard) isn’t valuable to users unless the entire workflow is consistent. Users think holistically about their experience, not just individual touchpoints.
And finally, our Ontology Frontend team wants to hear from you! Help us shape the future of Ontology Manager by sharing your thoughts on these questions:
-
-
Where should the Ontology Manager team focus its energy? Right now, Ontology Manager is the source of truth for ontology management, but Workflow Builder handles graph views and Object Explorer is great for exploration. What do you think Ontology Manager should own versus what other applications do better? Tell us where you want us to double down, or whether you want us to smoothly transfer you to the other applications that are specialized for certain applications.
-
How should we handle feature overlap? When Ontology Manager shows object type dependencies and Workflow Builder shows the same info as a graph with lineage, should we build lightweight or full versions of the same feature in Ontology Manager for quick reference, or should we focus on seamless navigation between apps? Do you prefer having everything in one place or specialized tools that work well together?
-
As ontologies get more complex, how can we help you succeed? With shared value types, interfaces, and growing feature sets, are the concepts clear when you’re setting things up? Should Ontology Manager be more educational and guide you through best practices, or do you prefer learning through our documentation and Palantir Learn? What kind of in-app guidance would help you best to reach your goals?
-
Drop your thoughts in the comments below - your real-world experience using these tools is exactly what we need to hear to build better products for everyone!
