Announcements（公告）¶

REMINDER: Sign up for the Foundry Newsletter to receive a summary of new products, features, and improvements across the platform directly to your inbox. For more information on how to subscribe, see the Foundry Newsletter and Product Feedback channels announcement.

Share your thoughts about these announcements in our Developer Community Forum ↗.

¶

Date published: 2026-01-29

Develop and test object views safely with Foundry Branching¶

Object views are now supported in Foundry Branching, enabling you to develop and test object view changes in isolation before deploying them to production.

Object views are critical interfaces between your ontology and end users. Branching enables safer iteration by allowing you to test changes in isolation, collaborate with multiple teams without conflicts, and ensure quality before deployment—using the same workflows you already use for Workshop modules and Ontology resources.

Key features:

Branch-based development: Add, remove, and modify object views on branches to safely iterate on structural changes (tabs, visibility conditions) and content changes (Workshop modules) without affecting production.
Cross-application testing: Embed branched object views in Workshop applications and preview them in Ontology Manager to validate changes before merging.
Conflict resolution: Rebase your object views when changes occur on main, with an intuitive dialog that automatically resolves non-conflicting changes and guides you through resolving conflicts.

Example of object views and their associated modified Workshop modules on a Foundry branch. Here we have a single Object Type named Museum modified on the branch. The Full Object View Tabs resource represents structural changes to the object view itself. The Full Object View Museum History and Panel Object View resources represent changes to Workshop modules used by the object view.

Example of object views and their associated (modified) Workshop modules on a Foundry branch. Here we have a single Object Type named "Museum" modified on the branch. The "Full Object View Tabs" resource represents structural changes to the object view itself. The "Full Object View • Museum History" and "Panel Object View" resources represent changes to Workshop modules used by the object view.

When conflicts are detected between your branch and main you will be prompted to rebase and be shown this dialog to resolve any conflicts.

When conflicts are detected between your branch and main , you will be prompted to rebase and be shown this dialog to resolve any conflicts.

Known limitations:

Approvals are not yet supported, so all object view changes on branches are automatically approved.
Legacy object view tabs cannot be edited on branches.

Getting started¶

To add an object view to a branch, save an object view version while on a branch in the Object View editor, accessed through the Ontology Manager. For detailed guidance on working with branched object views, refer to the documentation.

What's next in the development roadmap?¶

Full approvals integration with reviewers, policies, and resource protection on the main branch.

New run history filtering in Workflow Lineage¶

Date published: 2026-01-29

You can now filter run history in Workflow Lineage to quickly find specific executions of functions, actions, automations, and logic. The Run history tab provides a complete view of all executions over the past seven days, and filtering by multiple criteria makes it faster to debug issues or audit workflows in high-volume environments.

Available filters¶

Filter run history by any combination of the following criteria:

Status: Successful or failed executions
Timestamp range: Executions within a specified date range
User: Executions triggered by a specific user
Run time range: Executions within a specified duration range
Version: Executions for a specified version (functions only)
Caller: Executions originating from a specified resource
Failure type: Executions that failed for a specific reason

The run history for a function execution filtered by timestamp runtime and caller RID.

The run history for a function execution filtered by timestamp, runtime, and caller RID.

The run history for a logic execution filtered by status and failure reason.

The run history for a logic execution filtered by status and failure reason.

When you specify multiple filters, results will include only executions that match all specified filters. For example, find failed executions triggered by a specific user within the last 24 hours, or identify long-running executions that exceeded a certain duration threshold.

This feature is available across all enrollments. Review the documentation for more information on filtering run history.

Automatically package resources in DevOps by tracking a source folder¶

Date published: 2026-01-29

Tracking a source folder in DevOps allows you to automatically package all resources within a Compass project or folder. Instead of manually maintaining individual resources, DevOps will automatically include resources from the source folder every time you release a new version.

Tracking a source folder is useful for streamlining releases of new products when you have a well-defined project that reflects the resources you want to include in your product.

DevOps new product landing page now gives the option to track a source folder.

DevOps new product landing page now gives the option to track a source folder.

Configurations options¶

For files that are not present in the Compass filesystem, you can use folder settings to additionally track related resources. For example, you can track all health checks that exist on datasets in the folder or functions that are defined in Code Repositories in the folder. You can also exclude resources by configuring ignored sub-folders for outputs that should not be packaged, such as experimental work.

For added flexibility, you can combine both manually added outputs and folder tracked outputs. This allows you to manually add resources that do not exist within the Compass filesystem and are not covered by settings.

Several configuration settings are available when tracking a source folder.

Several configuration settings are available when tracking a source folder.

Migrate an existing product to track a source folder¶

If you have an existing product where resources were added manually, you can perform a one-time migration to configure your product to track a source folder, if your resources share a common Compass project. The migration dialog will show you a preview including resources that will now be tracked as part of the folder, as well as resources that will continue to be manually tracked because they are not within the Compass filesystem or brought in by folder tracking settings.

If you decide that folder tracking is no longer suitable for your product, you can switch back to manual output management using the Disable folder tracking option.

The folder tracking migration modal allows you to migrate existing products to track a source folder.

The folder tracking migration modal allows you to migrate existing products to track a source folder.

Learn more about tracking a source folder in DevOps.

Monitor usage with rate limit hit tracking in Resource Management¶

Date published: 2026-01-27

The Resource Management application now includes rate limit hit tracking in the AIP usage and limits view. Rate limit hits provide visibility into when users, projects, or applications reach their assigned rate limits in Foundry. This feature enables administrators to proactively monitor usage, identify capacity constraints, and troubleshoot issues related to rate limiting.

Key benefits¶

Proactive capacity management: Identify where and when rate limits are being reached across resources.
Faster troubleshooting: Quickly pinpoint usage bottlenecks and root causes of failures related to model consumption.
Improved planning: Make informed decisions about capacity requests and model usage based on real-time data.

Access rate limit hits¶

To view rate limit hit information, navigate to Resource Management > AIP usage and limits > View usage. Select the model, project, or resource, and view the associated rate limit hits in the table. If rate limit hits are not visible, the feature may not yet be available in your environment.

Your feedback matters¶

We want to hear about your experiences using reserved capacity in the Palantir platform and welcome your feedback. Share your thoughts with Palantir Support channels or on our Developer Community ↗ using the language-model-service tag ↗.

GPT-4.1 mini now available in additional regions¶

Date published: 2026-01-27

GPT-4.1 mini is now available from Azure OpenAI for georestricted enrollments in Australia, Canada, Japan, and the United Kingdom.