Add RFC-0014: Cross-workspace MLflow asset copying for fork-and-iterate workflows by Al-Pragliola · Pull Request #51 · mlflow/rfcs

Al-Pragliola · 2026-09-17T17:31:41Z

Teams maintaining approved AI assets in a shared workspace need a supported way to reuse them in team workspaces, customize them, and promote approved changes back.

This RFC proposes cross-workspace sharing and copying for prompts, registered models, and MCP server registry entries through the MLflow UI, Python SDK, and REST APIs.

The proposal supports four operations:

Sync makes an asset available under a local name as a read-only view that follows source changes.
Fork creates an editable snapshot while retaining the source relationship.
Copy creates an independent snapshot or promotes changes back through an explicit overwrite.
Detach removes a sync or fork relationship, materializing the current content when needed.

Operations cover the complete asset and its version history. Replacing an existing destination requires explicit confirmation and permission to update and delete its contents. Source deletion preserves dependent content, with explicit detachment required for synced assets.

Model artifact references are preserved without copying the underlying files. MCP access bindings are excluded and configured separately in the destination.

The RFC includes user journeys, API and SDK contracts, authorization rules, storage design, and lifecycle behavior.

…te workflows (#1) * Add RFC-0014: Cross-workspace MLflow asset copying for fork-and-iterate workflows Signed-off-by: Alessio Pragliola <seth.pro@gmail.com>

mprahl · 2026-09-17T17:35:31Z

+---
+start_date: 2026-09-02
+mlflow_issue: TBD
+rfc_pr: https://github.com/Al-Pragliola/rfcs/pull/1


Could you update this to the current PR?

done, you beat me to it 😁 75fadd7

mprahl

I had reviewed this internally previously, so just forwarding my approval here.

Addresses mlflow#51 (comment).

rrrkharse · 2026-09-17T22:36:12Z

+
+The unique target identity lets detach resolve the relationship from workspace, name, and the route's resource type. The association and lineage identifiers remain internal; they are not exposed in requests or resource responses.
+
+The target index supports search joins filtered by destination workspace, resource type, and `SYNC` relationship. The unique target constraint supports exact destination-identity lookups.


Any concerns with order by and pagination across multiple index joins? I think worst case some data could be omitted if data in one table mutates but probably fine since the page could be refreshed / query made again so more of a minor concern.

Yes, concurrent changes could cause items to move between pages. That’s why the RFC limits the no-duplicates/no-omissions guarantee to an unchanged result set. We still need consistent ordering across native and synced assets, with a stable tie-breaker, before applying pagination. Otherwise, results could be incorrect even without concurrent changes

rrrkharse · 2026-09-17T22:40:37Z

+forked_prompt = client.fork_prompt(
+    prompt,
+    target_workspace="team-search",
+    target_name="support-assistant-team",
+)
+```


Am I correct in assuming that all fork_xyz APIs take the same args (resource id, target_workspace, target_name) ? If so could we make the client more minimal like so:

fork(resource_type, resource_id, tgt_wspc, tgt_name) ... same for sync/copy/detach

?

You’re right that the signatures have the same shape across asset types. One detail: the proposal takes the source object rather than an ID, so its workspace and name travel together.

I was leaning toward methods like fork_prompt because they make the expected input and return type clear and are easy to discover in the client. We can still share the implementation underneath. A generic fork would be useful for code handling several resource types, though.

My preference is to keep the typed methods, but I’m open to consolidating them.. wdyt @mprahl ?

rrrkharse · 2026-09-17T22:53:13Z

+| Operation | Destination content | Relationship to source |
+| :--- | :--- | :--- |
+| Sync | Read-only, live view of source metadata | `SYNC` |
+| Fork | Editable snapshot | `FORK` |
+| Copy | Editable snapshot | None |
+| Detach | Materializes current synced content in place, or preserves existing fork content | Removes the `SYNC` or `FORK` relationship |


Some meta questions:

Can a forked resource be forked? Also can a resource be forked to any N number of other workspaces?

Can the same resource be forked, synced, and copied at the same time, or only one state at a time is allowed?

Seems like destination workspace users can discover where the resource was synced or forked from, but can target workspace users tell where their resource was forked to? Can they break a link from their end?

Yes to both. A fork can be forked again: if B forks A, makes changes, and C forks B, C gets B’s current content and its source relationship points to B. One source can also be forked into multiple workspaces.

Yes, the same source can be synced, forked, and copied to different destinations at the same time. These aren’t exclusive states on the source. Each destination identity can have at most one incoming relationship; independent copies have none.

On the source side, the proposal doesn’t currently include an API to list or individually detach outgoing links. It handles dependents when deleting the source, but I’d suggest leaving general link management outside the initial scope. Detaching would preserve destination content: a fork keeps its data, and a sync becomes a snapshot that stops receiving updates. Independent copies aren’t tracked.

Do you think we should spell out these cases in the RFC?

rrrkharse · 2026-09-17T22:59:01Z

+| Copy | Editable snapshot | None |
+| Detach | Materializes current synced content in place, or preserves existing fork content | Removes the `SYNC` or `FORK` relationship |
+
+`SYNC` stores a relationship without creating destination asset or version rows. `FORK` and `COPY` materialize destination metadata. Sync and fork fail if the destination identity is already occupied by a native asset or another link, including a sync to the same source. Ordinary asset creation also rejects names occupied by links. These name checks and destination creation must be atomic so concurrent requests cannot create duplicate identities.


Will this still mean that only READ in the destination workspace is needed to access the resource, especially in the (READ, resource_name) case?

I think the auth model could be updated to use target_workspace from the link to handle these cases but wanted to check if this scenario is covered otherwise.

Yes, that’s the intent, including READ on a specific destination resource. Authorization should use target_workspace and target_name from the link, without requiring source access.

Do you think we should state this explicitly in the RFC’s authorization section?

Add RFC-0014: Cross-workspace MLflow asset copying for fork-and-itera…

23e8104

…te workflows (#1) * Add RFC-0014: Cross-workspace MLflow asset copying for fork-and-iterate workflows Signed-off-by: Alessio Pragliola <seth.pro@gmail.com>

mprahl reviewed Sep 17, 2026

View reviewed changes

mprahl approved these changes Sep 17, 2026

View reviewed changes

docs(rfc-0014): link to the public RFC PR

75fadd7

Addresses mlflow#51 (comment).

rrrkharse approved these changes Sep 17, 2026

View reviewed changes

B-Step62 self-requested a review September 22, 2026 07:31

Navigation Menu

Add RFC-0014: Cross-workspace MLflow asset copying for fork-and-iterate workflows - #51

Add RFC-0014: Cross-workspace MLflow asset copying for fork-and-iterate workflows#51
Al-Pragliola wants to merge 2 commits into
mlflow:mainfrom
Al-Pragliola:main

Al-Pragliola commented Sep 17, 2026 •

edited

Loading

Uh oh!

mprahl Sep 17, 2026

Uh oh!

Al-Pragliola Sep 17, 2026

Uh oh!

mprahl left a comment

Uh oh!

rrrkharse Sep 17, 2026

Uh oh!

Al-Pragliola Sep 18, 2026

Uh oh!

rrrkharse Sep 17, 2026

Uh oh!

Al-Pragliola Sep 18, 2026

Uh oh!

rrrkharse Sep 17, 2026

Uh oh!

Al-Pragliola Sep 18, 2026

Uh oh!

rrrkharse Sep 17, 2026

Uh oh!

Al-Pragliola Sep 18, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants


		The unique target identity lets detach resolve the relationship from workspace, name, and the route's resource type. The association and lineage identifiers remain internal; they are not exposed in requests or resource responses.

		The target index supports search joins filtered by destination workspace, resource type, and `SYNC` relationship. The unique target constraint supports exact destination-identity lookups.

Conversation

Al-Pragliola commented Sep 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mprahl left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Al-Pragliola commented Sep 17, 2026 •

edited

Loading