Feature Request: Allow AI FDE to Submit Internal Product Feedback
Summary
When AI FDE encounters platform limitations, missing APIs, or has to fall back to manual workarounds, it should have the ability to automatically file structured product feedback tickets to Palantir’s internal teams. This would create a continuous, high-quality feedback loop between real user workflows and platform development.
The Problem Today
AI FDE works across thousands of user sessions, building pipelines, writing functions, configuring ontologies, and more. When it hits a limitation — like a missing DSL feature, an unsupported tool capability, or an API gap — the only options are:
- Tell the user to do it manually (breaks the automation promise)
- The user files a forum post (requires effort, often doesn’t happen)
- The friction is silently absorbed (Palantir never hears about it)
Most of the time, option 3 wins. The feedback is lost.
The Opportunity
AI FDE is arguably the highest-volume, most context-rich source of product feedback Palantir has. Every time it hits a wall, it knows:
- Exactly what it tried to do (the API call, the tool, the DSL method)
- Why it failed (missing feature, unsupported parameter, tool not available)
- What the user was trying to achieve (the business goal behind the request)
- What workaround it had to use (manual UI steps, alternative approach, or giving up)
- A proposed solution (what the API/tool should look like)
This is far richer than a typical support ticket or forum post.
Proposed Design
What gets filed
A structured feedback record containing:
| Field | Example |
|---|---|
| Category | Missing DSL API / Tool gap / Documentation gap / UX friction |
| Component | Pipeline Builder, Functions, Ontology Editing, etc. |
| What was attempted | Add data expectations to Pipeline Builder output via DSL |
| What happened | No expectations parameter exists on PB.outputs.dataset() |
| Workaround given | Manual UI instructions provided to user |
| Proposed fix | Add expectations array to the output DSL (with example API sketch) |
| Frequency signal | Number of times this limitation has been encountered across sessions |
Safeguards
- Deduplication — Don’t file the same issue hundreds of times. Aggregate frequency and add “+1” signals to existing tickets instead.
- Quality threshold — Only file when there’s a clear, reproducible gap (not “I tried something weird and it didn’t work”).
- No user data — Tickets should describe the capability gap, not the user’s specific data or business context.
- Transparency — Users could see a summary like: “I noticed this platform limitation and flagged it to Palantir’s product team.”
- Feedback loop — When issues are resolved, AI FDE should be updated so it stops suggesting workarounds for fixed problems.
Why This Matters
For users: Friction points get addressed faster without requiring them to write forum posts. The tool they’re already using becomes their advocate.
For Palantir: Instead of relying on users to self-report issues (which happens rarely), the platform gets continuous, structured, high-context feedback from real workflows at scale. Product teams can prioritize based on actual frequency data rather than guessing.
For AI FDE itself: Each resolved issue makes it more capable. It’s a virtuous cycle — feedback → fix → better AI → discovers next friction point → feedback.
Real-World Example
In a single session today, AI FDE:
Built a 7-step data pipeline (dedup, primary key, type casting, HTML cleanup, null filling, schema ordering)- Deployed and validated the output dataset
Could not add data expectations because Pipeline Builder’s DSL doesn’t expose them
Had to write manual UI instructions as a workaround
With this feature, that gap would have been automatically captured, categorized, and routed — along with a frequency count showing how often it comes up across all users.
In Short
AI FDE talks to more Foundry users than any solutions architect. Let it file tickets.
