diff --git a/future-plans.md b/future-plans.md
index 0926a7e..dc658f7 100644
--- a/future-plans.md
+++ b/future-plans.md
@@ -424,7 +424,7 @@ This also enables filtering/grouping bins by type, and makes it easy to re-proce
 all bins of a type if the corner algorithm improves.
 
 ### Generic fields on bins and bin types
-Bins and bin types should support the same generic field system as components —
+Bins and bin types should both support the same generic field system as components —
 arbitrary key/value pairs from the shared field definitions. Examples: color, material,
 manufacturer, max load, purchase link. Bin types carry the "template" fields (e.g.
 nominal dimensions from the datasheet) while individual bins carry instance-specific
@@ -435,10 +435,14 @@ the system, they will quickly span unrelated domains. Field grouping (see Field
 section) becomes important here so the field selector can be filtered to show only
 relevant fields for the current entity type.
 
-### Duplicate bin type
-Bin types should be duplicatable — common when you have the same physical container
-in different colors, sizes, or configurations. Duplicating copies all fields and
-dimensions; the user then adjusts what differs.
+### Duplicate any entity
+All objects in the system should be duplicatable: components, bin types, bins, grids,
+templates, inventory entries, and eventually source images. The duplicate operation
+creates a new record with all fields copied, then opens it in an edit dialog so the
+user can adjust what differs. Bin type duplication is especially common — same
+physical container model in different colors or configurations. Source images are a
+later case since they reference uploaded files; duplication there would mean creating
+a new metadata record pointing to the same underlying file (or an explicit copy).
 
 ## Grids