@@ -226,6 +226,22 @@ Several "advanced" attributes available on every Create/Update command are baked
 
 - **`Anchor ID` / `Anchor Scope ID`** — **Create-time only, by design.** Anchoring in Egeria is create-time-only plumbing; there is no supported way to change an element's anchor after creation. Setting these on an `Update` command has no effect.
 
+### For Lineage: Promise and Memento elements
+
+Egeria hides two kinds of element from ordinary requests and returns them only when a request sets `forLineage=true`:
+
+- **Promise** (0010): a placeholder for a real-world resource that has not been delivered yet (see `Classify Promise` / `Declassify Promise` in the Curation family).
+- **Memento**: an element that has been logically deleted but is kept so lineage stays complete.
+
+Dr.Egeria's defaults (added 2026-10-01):
+
+- **Editing commands** (Create, Update, Link, Classify, ...) send every request with `forLineage=true`, so a promised element can be found, updated and linked without adding `For Lineage` to each command. This covers the existence check, reference lookups, fetches and the write itself.
+- **Report commands** (`View`, `List`, `Run`) send `forLineage=false`, so promised and deleted elements stay out of reports.
+- An explicit `For Lineage` attribute (Advanced templates) overrides either default. The one exception is `Declassify Promise`, which always uses `forLineage=true`, since its target is otherwise invisible.
+- A **Memento** element found by an editing command is treated as not found. A `Create` for a deleted element's name therefore still creates a new element, as it did before, instead of updating the deleted one.
+
+In the SDK, `with pyegeria.lineage_visible():` applies the same `forLineage=true` default to every request a pyegeria client sends inside the block.
+
 ---
 
 ## Supported Command Families
@@ -242,6 +258,7 @@ Dr.Egeria organizes its commands into "families," each corresponding to a specif
 - **Solution Architect**: Manage solution blueprints, components, information supply chains, and design patterns (e.g., `Create Design Pattern`, `Link Nested Design Patterns`, `Link Specialized Design Patterns`, `Link Related Design Patterns`).
   - **Concept Models** (0571, added 2026-08-21): `Create Concept Bead`, `Create Concept Bead Attribute`, `Create Concept Bead Relationship`, and 8 relationship commands — `Link Concept Design`, `Link Concept Bead Relationship End`, `Link Typed By Concept Bead`, `Link Is A Concept Bead`, `Link Concept Bead Attribute Link`, `Link Concept Bead Extension`, `Link Solution Component Port`, `Link Solution Port Delegation` (`Detach`/`Unlink`/`Remove` variants auto-derived from each `Link` command). Routed through the existing generic `SolutionArchitectProcessor`/`SolutionLinkProcessor` (new `om_type` branches, no new processor classes needed) — auto-registered via `register_solution_architect_processors()`'s family-driven loop, same as every other Solution Architect command.
   - `Create Concept Model` (added 2026-08-21) creates the `ConceptModel` container `Link Concept Design` attaches elements to. No dedicated `/solution-architect/concept-models` REST endpoint exists yet, so this routes through the generic `Collection Manager` creation path instead — added `"Concept Model"` to `COLLECTION_SUBTYPES` (`md_processing_constants.py`), which per this repo's own convention is the entire wiring step (auto-routes to `CollectionManagerProcessor`'s existing generic-collection-subtype fallback, no bespoke pyegeria method needed). Live-verified end to end against a running 6.2-SNAPSHOT server: `Create Concept Model` → `Create Concept Bead` → `Link Concept Design`, with the `ConceptDesign` relationship confirmed present via direct fetch afterward.
+  - `Create Solution Component` carries `Deployment Status` and `User Defined Deployment Status` (0730 `deploymentStatus`/`userDefinedDeploymentStatus`, added 2026-10-01).
   - `Link Implemented By` (0737, added 2026-09-13): attaches a design object (Information Supply Chain, Solution Component, Governance Definition, ...) to its implementation via the `ImplementedBy` relationship — a cross-OMVS call to `governance_officer`'s `linkDesignToImplementation`/`detachDesignFromImplementation` endpoints (`Detach`/`Unlink`/`Remove` variants auto-derived, same mechanism as the Concept Model relationship commands above). Along the way, fixed a real latent bug: `_get_supply_chain_rel_elements()` read a nonexistent `implementedByList` field instead of the real `implementedBy` (confirmed against `AttributedMetadataElement.java` and a live element fetch) — this had silently made the `Implemented By` sync's as-is diff always see zero existing relationships.
   - **Correction, 2026-09-16:** the paragraph above's `Create Information Supply Chain`/`Create Solution Component` sync was itself wrong — `In Information Supply Chain` (on `Create Solution Component`) and `Implemented By` (on `Create Information Supply Chain`) were both syncing via `ImplementedBy` (the mechanism `Link Implemented By` legitimately uses), when `InformationSupplyChain` is a Collection subtype and these two attributes are ordinary collection membership. Reported live: 71 components each carrying `In Information Supply Chain` fanned each chain out to 143 `ImplementedBy` links, alongside the 47 correct `CollectionMembership`s from explicit `Add Member` blocks. Both sync points (`SolutionComponentProcessor._sync_all_rels`'s "Supply Chains" block and `SupplyChainProcessor._sync_rels`'s "Implemented By" block, `solution_architect.py`) now call `_async_add_to_collection`/`_async_remove_from_collection` with `CollectionMembershipProperties`, matching every other ISC membership sync in this file. Pre-existing bad `ImplementedBy` links created before this fix are not auto-cleaned — the as-is fetch now reads `collectionMembers`, not `implementedBy`, so a re-sync no longer sees or touches them; removing them is a separate one-off cleanup against affected servers.
 - **Lineage Linker** (added 2026-09-16): Create/update/detach the seven Lineage Linker OMVS relationship types (0750/0755/0770 — DataFlow, ControlFlow, ProcessCall, LineageMapping, DataMapping, UltimateSource, UltimateDestination) between two elements, e.g. `Link Data Flow`, `Update Process Call`, `Link Data Mapping`. One dedicated `Link`/`Update` command pair per type (each with only its own type's attributes — Guard/Mandatory Guard for `Control Flow`; Query/Query ID/Query Type for `Data Mapping`; One Way/Integration Style/Protocol/Frequency/Data Exchanged, reused from Solution Architect's `SolutionLinkingWire` attributes, for the rest), plus one shared `Unlink Lineage Relationship` command since detaching only needs the relationship's own GUID. Split from an earlier single generic command triple that used a `Lineage Relationship Type` selector attribute offering every type's attributes regardless of which type was picked. The split also surfaced and fixed a real gap: the pyegeria SDK's `DataFlowProperties`/`ProcessCallProperties`/`LineageMappingProperties`/`UltimateSourceProperties`/`UltimateDestinationProperties` (`pyegeria/omvs/lineage_linker.py`) were missing `oneWay`/`integrationStyle`/`protocol`/`frequency`/`dataExchanged` (and `ProcessCallProperties` was missing `lineNumber`) entirely — real fields on the Egeria DTOs (`DataLineageRelationshipProperties`/`ProcessCallProperties.java`) that had no home on the pydantic model, so a caller passing them would validate silently and have them dropped before serialization (the `PyegeriaModel` `extra='ignore'` gotcha — see the SDK section below).
 
@@ -2862,7 +2862,7 @@
         "OTHER"
       ],
       "existing_element": "",
-      "description": "Progress toward delivering the promised real-world digital resource/artifact - one of an enumerated set of values (DeploymentStatus).",
+      "description": "The deployment status of the element - one of an enumerated set of values (DeploymentStatus). On a Promise it tracks progress toward delivering the promised resource.",
       "generated": false,
       "style": "Valid Value",
       "user_specified": true,
@@ -2871,7 +2871,7 @@
       "min_cardinality": 0,
       "max_cardinality": 1,
       "level": "Basic",
-      "Journal Entry": "Added 2026-09-30 -- Promise classification (0010), Classification Explorer setElementAsPromise."
+      "Journal Entry": "2026-10-01: shared definition -- used by Curation (Classify Promise) and Solution Architect (Solution Component, Egeria 0730 deploymentStatus/userDefinedDeploymentStatus). Keep identical in both files (global attribute namespace)."
     },
     "User Defined Deployment Status": {
       "variable_name": "user_defined_deployment_status",
@@ -2881,7 +2881,7 @@
       "default_value": "",
       "valid_values": [],
       "existing_element": "",
-      "description": "Locally defined deployment status - used when Deployment Status is OTHER.",
+      "description": "A locally defined deployment status - only used when Deployment Status is OTHER.",
       "generated": false,
       "style": "Simple",
       "user_specified": true,
@@ -2890,7 +2890,7 @@
       "min_cardinality": 0,
       "max_cardinality": 1,
       "level": "Domain",
-      "Journal Entry": "Added 2026-09-30 -- Promise classification (0010), Classification Explorer setElementAsPromise."
+      "Journal Entry": "2026-10-01: shared definition -- used by Curation (Classify Promise) and Solution Architect (Solution Component, Egeria 0730 deploymentStatus/userDefinedDeploymentStatus). Keep identical in both files (global attribute namespace)."
     },
     "Start Time": {
       "variable_name": "start_time",
 
@@ -3168,6 +3168,55 @@
       "max_cardinality": 1,
       "level": "Domain",
       "Journal Entry": "Added 2026-09-13 -- ImplementedBy relationship (0737) support, requested by the user: Solution Architect had no command for governance_officer's linkDesignToImplementation/detachDesignFromImplementation, and Create Information Supply Chain had no way to record implementation elements. Confirmed live 2026-09-13 that 'Link Information Supply Chain Child' already correctly uses CollectionMembership (not ImplementedBy) -- no fix needed there. Detach/Unlink/Attach/Add/Remove variants are auto-derived by build_command_variants() from this one 'Link' definition, matching every other Solution Architect link command -- no separate Detach compact entry needed."
+    },
+    "Deployment Status": {
+      "variable_name": "deployment_status",
+      "inUpdate": true,
+      "attr_labels": "",
+      "examples": "",
+      "default_value": "",
+      "valid_values": [
+        "PROPOSED",
+        "UNDER_DEVELOPMENT",
+        "DEVELOPMENT_COMPLETE",
+        "APPROVED_FOR_DEPLOYMENT",
+        "REJECTED",
+        "STANDBY",
+        "ACTIVE",
+        "DISABLED",
+        "FAILED",
+        "OTHER"
+      ],
+      "existing_element": "",
+      "description": "The deployment status of the element - one of an enumerated set of values (DeploymentStatus). On a Promise it tracks progress toward delivering the promised resource.",
+      "generated": false,
+      "style": "Valid Value",
+      "user_specified": true,
+      "unique": false,
+      "input_required": false,
+      "min_cardinality": 0,
+      "max_cardinality": 1,
+      "level": "Basic",
+      "Journal Entry": "2026-10-01: shared definition -- used by Curation (Classify Promise) and Solution Architect (Solution Component, Egeria 0730 deploymentStatus/userDefinedDeploymentStatus). Keep identical in both files (global attribute namespace)."
+    },
+    "User Defined Deployment Status": {
+      "variable_name": "user_defined_deployment_status",
+      "inUpdate": true,
+      "attr_labels": "",
+      "examples": "",
+      "default_value": "",
+      "valid_values": [],
+      "existing_element": "",
+      "description": "A locally defined deployment status - only used when Deployment Status is OTHER.",
+      "generated": false,
+      "style": "Simple",
+      "user_specified": true,
+      "unique": false,
+      "input_required": false,
+      "min_cardinality": 0,
+      "max_cardinality": 1,
+      "level": "Domain",
+      "Journal Entry": "2026-10-01: shared definition -- used by Curation (Classify Promise) and Solution Architect (Solution Component, Egeria 0730 deploymentStatus/userDefinedDeploymentStatus). Keep identical in both files (global attribute namespace)."
     }
   },
   "bundles": {
@@ -3333,7 +3382,9 @@
         "In Solution Components",
         "Planned Deployed Implementation Type",
         "Solution Component Type",
-        "Solution SubComponents"
+        "Solution SubComponents",
+        "Deployment Status",
+        "User Defined Deployment Status"
       ]
     },
     "Solution Role Base": {
@@ -3478,7 +3529,7 @@
       "qn_prefix": "",
       "alternate_names": [],
       "family": "Solution Architect",
-      "description": "Links or unlinks two solution compoents.",
+      "description": "Links or unlinks two solution components.",
       "verb": "Link",
       "upsert": false,
       "attach": false,
@@ -3677,7 +3728,7 @@
       "qn_prefix": "",
       "alternate_names": [],
       "family": "Solution Architect",
-      "description": "Links a child compoent to a parent component.",
+      "description": "Links a child component to a parent component.",
       "verb": "Link",
       "upsert": false,
       "attach": false,