@@ -768,88 +768,6 @@ on an Egeria Server capability that doesn't exist yet — but the pyegeria/
 Dr.Egeria-side work each will need once that capability ships is written
 into the entry now, so it isn't rediscovered from scratch later.
 
-### ISSUE-48: No OMVS wrapper exists for the `SchemaAttributeDefinition` relationship (physical `SchemaAttribute` ↔ logical `DataField`)
-
-**Status:** deferred 2026-08-15 — user's decision: wait until Egeria ships
-the actual REST endpoint for this relationship before building a pyegeria
-wrapper or Dr.Egeria command against it. Both options considered below
-remain valid candidates once that lands; no implementation work done here.
-
-**Re-checked 2026-08-19, still deferred, still valid — but Option 2 now
-confirmed to actually work.** Fetched the live server's full `/v3/api-docs`
-OpenAPI spec (1.77 MB, successfully retrieved) and grepped both the URL
-paths and the schema component names for `SchemaAttributeDefinition`:
-**zero hits in either.** No bespoke REST endpoint has shipped — the wait
-condition from 2026-08-15 hasn't been met, so the deferral stands as-is.
-Separately, live-tested Option 2 (the generic
-`MetadataExpert`/`NewRelatedElementsRequestBody` path,
-`typeName: "SchemaAttributeDefinition"`) end-to-end against a real
-`DataField`/`SchemaAttribute` pair — **it works today**: created the
-relationship (`GUIDResponse` with a real guid), then cleaned it up via
-`_async_delete_related_elements`. Previously this was listed as a
-considered-but-untested option; now confirmed viable, so if the team
-wants to unblock a Dr.Egeria command without waiting further, Option 2 is
-ready to use as-is — no new pyegeria SDK surface required, same
-mechanism `CurationLinkProcessor` already uses for `ResourceList`/
-`MoreInformation`.
-
-**Original status:** open — SDK gap to validate with the team, not yet a confirmed
-bug. Raised 2026-08-07 while triaging a request to add three "missing"
-Dr.Egeria Data Designer commands (SemanticAssignment, DataClassAssignment,
-SchemaTypeImplementation). Two of the three turned out not to be gaps at
-all once checked against the real type system and existing compact specs:
-
-- **SemanticAssignment** (schema/field → glossary term) already exists —
-  `Link Semantic Assignment` / `Unlink Semantic Assignment` in the
-  **Curation** family (`commands_curation_compact.json`, `OM_TYPE:
-  SemanticAssignment`, wired to `ClassificationExplorer.
-  _async_setup_semantic_assignment` in `CurationLinkProcessor`). Its
-  `Target Element` is a generic GUID, so it already works against a data
-  field or schema attribute today.
-- **DataClassAssignment** on a physical schema attribute is also already
-  covered — and the type name itself is stale. The old `DataClassAssignment`
-  relationship was replaced in this Egeria version by
-  `DataValueAssignmentRelationship` (0540 —
-  `OpenMetadataTypesArchive1_2.java`), whose end 1 is `Referenceable` (any
-  element, including a schema attribute). Data Designer's existing `Assign
-  Data Value Specification` command (`OM_TYPE: DataValueAssignment`)
-  already covers this generically via its `Element Id` attribute.
-
-**The third one is a real gap, at the SDK level, not just the Dr.Egeria
-command-spec level.** "SchemaTypeImplementation" isn't a real type name in
-this Egeria version at all. The type that actually connects a physical
-`SchemaAttribute` to a logical `DataField` is `SchemaAttributeDefinition`
-(0580, `OpenMetadataTypesArchive5_3.java` —
-`getSchemaAttributeDefinitionRelationship()`), ends `derivedFromDataField`
-(on `DataField`, AT_MOST_ONE) / `equivalentSchemaAttribute` (on
-`SchemaAttribute`, AT_MOST_ONE). Confirmed via grep across `pyegeria/omvs/`
-and `pyegeria/http clients/*.http`: **no bespoke wrapper method exists**
-for setting up or clearing this relationship — no `_async_link_*`/
-`_async_setup_*` method, no `.http` worked example, in `data_designer.py`,
-`data_engineer.py`, or `classification_explorer.py`.
-
-**Options considered, not yet decided:**
-1. Add a bespoke wrapper (e.g.
-   `DataDesigner._async_link_schema_attribute_definition`/
-   `_async_detach_schema_attribute_definition`) mirroring
-   `_async_setup_semantic_assignment`'s shape, then wire a Dr.Egeria
-   `Link/Unlink Schema Attribute Definition` command to it. Most
-   consistent with how other bespoke-family relationships are handled, but
-   requires new SDK surface first.
-2. Skip the bespoke wrapper and drive it through the existing generic
-   `MetadataExpert._async_create_related_elements`/
-   `_async_delete_related_elements` (typeName-based) — the same mechanism
-   `CurationLinkProcessor` already uses for other Tier-2 gaps with no
-   dedicated method (`ResourceList`, `MoreInformation`). No new SDK method
-   needed, but less discoverable/typed than a bespoke wrapper.
-
-No command has been added to the compact JSON for this yet — deferred
-pending the team's input on which approach (or whether the relationship
-is even meant to be user-authorable via Dr.Egeria, vs. only ever
-system-derived from a physical→logical mapping tool).
-
----
-
 ---
 
 # Quick reference: which OMVS client class for which purpose
@@ -881,6 +799,65 @@ system-derived from a physical→logical mapping tool).
 
 ## Fixed / Resolved
 
+### ISSUE-48: No OMVS wrapper exists for the `SchemaAttributeDefinition` relationship (physical `SchemaAttribute` ↔ logical `DataField`)
+
+**Status:** implemented 2026-08-19 via Option 2 (the generic
+`MetadataExpert` relationship mechanism) — deferred 2026-08-15, re-checked
+2026-08-19 (still no bespoke Egeria endpoint, confirmed against the full
+`/v3/api-docs` spec; Option 2 confirmed viable live), then built the same
+day per the user's go-ahead.
+
+**What shipped:** a new Dr.Egeria command family, `Link/Detach Schema
+Attribute Definition` (`Data Designer` family,
+`commands_data_designer.json`, new `Schema Attribute` attribute alongside
+the existing `Data Field`), backed by a new
+`LinkSchemaAttributeDefinitionProcessor`
+(`md_processing/v2/data_designer.py`):
+- **Link/Attach/Add:** calls
+  `MetadataExpert._async_create_related_elements` with a
+  `NewRelatedElementsRequestBody` (`typeName: SchemaAttributeDefinition`),
+  captures the returned relationship GUID into
+  `parsed_output["guid"]`, and displays it in the result markdown.
+- **Detach/Unlink/Remove:** looks the relationship up by its element pair
+  via `_async_find_relationships_between_elements`
+  (`end1EntityGUIDs`/`end2EntityGUIDs`) rather than requiring a separate
+  GUID attribute — safe because `SchemaAttributeDefinition`'s
+  `relationshipCategory` is `UNI_LINK` with `AT_MOST_ONE` cardinality on
+  both ends (confirmed live via
+  `ValidMetadataManager.get_all_relationship_defs()`), so there's no
+  multi-instance ambiguity to resolve. Then deletes via
+  `_async_delete_related_elements(relationship_guid, ...)`.
+- `supports_target_element_lookup()` overridden to `False` (relationship-
+  only processor — see ISSUE-68's `AsyncBaseCommandProcessor` upsert-
+  rewrite-bug fix for why this matters; avoids the same latent Update-verb
+  hazard flagged there for any future relationship processor).
+
+**No new pyegeria SDK surface required** — `_async_create_related_elements`/
+`_async_find_relationships_between_elements`/`_async_delete_related_elements`
+all already existed on `MetadataExpert`.
+
+**Verified live**, full round trip against a real `DataField`/
+`SchemaAttribute` pair: `Link Schema Attribute Definition` via
+`--process` created the relationship and displayed its GUID; a direct
+`_async_find_relationships_between_elements` query confirmed it existed;
+`Detach Schema Attribute Definition` via `--process` removed it; the same
+query afterward returned "No elements found", confirming clean deletion.
+
+**Tests:** `test_link_schema_attribute_definition.py` (5 tests, fake
+client, no live server needed).
+
+**Explicitly temporary, per the user's own framing** ("implement Option 2
+... and we'll replace it once the new endpoint is available") — re-check
+this issue's own "still deferred" 2026-08-19 OpenAPI-spec check
+periodically; once Egeria ships a bespoke `SchemaAttributeDefinition`
+endpoint, migrate `LinkSchemaAttributeDefinitionProcessor` to a dedicated
+`DataDesigner._async_link_schema_attribute_definition`/
+`_async_detach_schema_attribute_definition` wrapper (Option 1) instead —
+same compact-spec command, same attributes, just a different
+implementation underneath.
+
+---
+
 ### ISSUE-55: Desired enhancement — true "exclude type" / NOT semantics for `findMetadataElements`
 
 **Status:** fixed 2026-08-18 — Egeria shipped it. Raised 2026-08-05
 
@@ -3264,6 +3264,25 @@
       "max_cardinality": 1,
       "level": "Domain",
       "Journal Entry": ""
+    },
+    "Schema Attribute": {
+      "variable_name": "schema_attribute",
+      "inUpdate": true,
+      "attr_labels": "",
+      "examples": "",
+      "default_value": "",
+      "valid_values": [],
+      "existing_element": "SchemaAttribute",
+      "description": "A physical schema attribute (e.g. a TabularColumn). Preferably a qualified name.",
+      "generated": false,
+      "style": "Reference Name",
+      "user_specified": true,
+      "unique": false,
+      "input_required": true,
+      "min_cardinality": 1,
+      "max_cardinality": 1,
+      "level": "Domain",
+      "Journal Entry": ""
     }
   },
   "bundles": {
@@ -3880,6 +3899,28 @@
         "Element Id"
       ],
       "Journal Entry": ""
+    },
+    "Link Schema Attribute Definition": {
+      "display_name": "schema_attribute_definition",
+      "qn_prefix": "",
+      "alternate_names": [],
+      "family": "Data Designer",
+      "description": "Link a logical Data Field to the physical Schema Attribute that implements it (e.g. a TabularColumn), or the reverse lookup. Implemented via the generic MetadataExpert relationship mechanism (typeName: SchemaAttributeDefinition) -- no bespoke Egeria REST endpoint exists for this relationship yet (PYEGERIA_ISSUES.md ISSUE-48); will be migrated to a dedicated wrapper once Egeria ships one.",
+      "verb": "Link",
+      "upsert": false,
+      "attach": true,
+      "level": "Basic",
+      "find_method": "",
+      "find_constraints": "",
+      "extra_find": "",
+      "extra_constraints": "",
+      "OM_TYPE": "SchemaAttributeDefinition",
+      "bundle": "Link Command Base",
+      "custom_attributes": [
+        "Data Field",
+        "Schema Attribute"
+      ],
+      "Journal Entry": ""
     }
   }
 }
@@ -315,6 +315,7 @@ def reg(base, cls):
         DataValueSpecificationProcessor, DataClassProcessor, DataStructureProcessor, DataFieldProcessor, DataGrainProcessor,
         LinkDataFieldProcessor, LinkFieldToStructureProcessor, LinkDataValueDefinitionProcessor, LinkDataValueCompositionProcessor,
         LinkDataClassCompositionProcessor, LinkCertificationTypeToStructureProcessor,
+        LinkSchemaAttributeDefinitionProcessor,
         AssignDataValueSpecificationProcessor
     )
 
@@ -332,6 +333,7 @@ def reg(base, cls):
     reg("Link Data Value Composition", LinkDataValueCompositionProcessor)
     reg("Link Data Class Composition", LinkDataClassCompositionProcessor)
     reg("Link Certification Type to Data Structure", LinkCertificationTypeToStructureProcessor)
+    reg("Link Schema Attribute Definition", LinkSchemaAttributeDefinitionProcessor)
     # "Assign Data Value Specification" (verb Attach/Link/Add) and "Detach
     # Data Value Specification from Element" (verb Detach/Unlink/Remove) both
     # route to the same AssignDataValueSpecificationProcessor, which branches
 
@@ -922,6 +922,110 @@ async def fetch_element(self, guid: str) -> Optional[Dict[str, Any]]:
         return None
 
 
+class LinkSchemaAttributeDefinitionProcessor(AsyncBaseCommandProcessor):
+    """
+    Processor for Link/Detach Schema Attribute Definition commands.
+
+    PYEGERIA_ISSUES.md ISSUE-48: no bespoke Egeria REST endpoint exists yet
+    for the SchemaAttributeDefinition relationship (DataField <->
+    SchemaAttribute) -- confirmed live via the server's full /v3/api-docs
+    OpenAPI spec, zero hits for this type in either the URL paths or the
+    schema components. This processor uses Option 2 from that issue: the
+    generic MetadataExpert relationship mechanism
+    (_async_create_related_elements/_async_delete_related_elements,
+    typeName-based) rather than a dedicated wrapper method. Replace this
+    with a bespoke DataDesigner._async_link_schema_attribute_definition/
+    _async_detach_schema_attribute_definition (Option 1) once Egeria ships
+    a real endpoint -- re-check ISSUE-48 before assuming it hasn't.
+
+    SchemaAttributeDefinition's relationshipCategory is UNI_LINK (at most
+    one instance between a given pair -- confirmed live via
+    ValidMetadataManager.get_all_relationship_defs(), both ends are
+    AT_MOST_ONE cardinality), so Detach can safely look the relationship
+    up by its element pair via _async_find_relationships_between_elements
+    rather than requiring a separate GUID attribute -- there's no
+    multi-instance ambiguity to resolve.
+    """
+
+    def get_command_spec(self) -> Dict[str, Any]:
+        return get_command_spec(f"{self.command.verb} Schema Attribute Definition")
+
+    def supports_target_element_lookup(self) -> bool:
+        # Relationship-only processor -- see GovernanceLinkProcessor's
+        # identical override (md_processing/v2/governance.py) for why this
+        # matters: without it, AsyncBaseCommandProcessor.execute()'s
+        # Create<->Update upsert-transition logic can silently rewrite the
+        # verb (ISSUE-68 follow-up).
+        return False
+
+    async def fetch_as_is(self) -> Optional[Dict[str, Any]]:
+        return None
+
+    async def _find_relationship_guid(self, data_field_guid: str, schema_attribute_guid: str) -> Optional[str]:
+        result = await self.client.metadata_expert._async_find_relationships_between_elements({
+            "class": "FindRelationshipRequestBody",
+            "relationshipTypeName": "SchemaAttributeDefinition",
+            "end1EntityGUIDs": [data_field_guid],
+            "end2EntityGUIDs": [schema_attribute_guid],
+        })
+        # _async_find_relationships_between_elements returns the raw
+        # {"relationships": [...], "mermaidGraph": ...} envelope (not a bare
+        # list) whenever a match is found -- see
+        # metadata_expert.process_related_element_list()'s final `return
+        # elements` (the outer envelope dict, not the unwrapped list it
+        # just validated non-empty).
+        if not isinstance(result, dict):
+            return None
+        relationships = result.get("relationships") or []
+        for rel in relationships:
+            if isinstance(rel, dict) and rel.get("relationshipGUID"):
+                return rel["relationshipGUID"]
+        return None
+
+    async def apply_changes(self) -> str:
+        verb = self.command.verb
+        object_type = getattr(self, 'canonical_object_type', self.command.object_type)
+        attributes = self.parsed_output["attributes"]
+
+        data_field_guid = attributes.get('Data Field', {}).get('guid')
+        schema_attribute_guid = attributes.get('Schema Attribute', {}).get('guid')
+        if not (data_field_guid and schema_attribute_guid):
+            missing = []
+            if not data_field_guid: missing.append("'Data Field'")
+            if not schema_attribute_guid: missing.append("'Schema Attribute'")
+            raise ValueError(f"Cannot {verb.lower()} Schema Attribute Definition: resolution failed for {', '.join(missing)}")
+
+        if verb in ["Link", "Attach", "Add"]:
+            body = {
+                "class": "NewRelatedElementsRequestBody",
+                "typeName": "SchemaAttributeDefinition",
+                "metadataElement1GUID": data_field_guid,
+                "metadataElement2GUID": schema_attribute_guid,
+                "properties": {"class": "SchemaAttributeDefinitionProperties"},
+            }
+            new_rel_guid = await self.client.metadata_expert._async_create_related_elements(body)
+            logger.success(f"Linked Data Field {data_field_guid} to Schema Attribute {schema_attribute_guid}")
+            if new_rel_guid:
+                self.parsed_output["guid"] = new_rel_guid
+                return f"\n\n## {verb} {object_type}\n\nLinked {data_field_guid} to {schema_attribute_guid}. Relationship GUID: {new_rel_guid}"
+            return f"\n\n## {verb} {object_type}\n\nLinked {data_field_guid} to {schema_attribute_guid}"
+
+        elif verb in ["Detach", "Unlink", "Remove"]:
+            relationship_guid = await self._find_relationship_guid(data_field_guid, schema_attribute_guid)
+            if not relationship_guid:
+                raise ValueError(
+                    f"Cannot {verb.lower()} Schema Attribute Definition: no existing relationship found "
+                    f"between {data_field_guid} and {schema_attribute_guid}."
+                )
+            await self.client.metadata_expert._async_delete_related_elements(
+                relationship_guid, {"class": "DeleteRelationshipRequestBody"}
+            )
+            logger.success(f"Detached Schema Attribute Definition {relationship_guid}")
+            return f"\n\n## {verb} {object_type}\n\nDetached relationship {relationship_guid} between {data_field_guid} and {schema_attribute_guid}"
+
+        return self.command.raw_block
+
+
 class AssignDataValueSpecificationProcessor(AsyncBaseCommandProcessor):
     """
     Processor for Assign/Attach Data Value Specification to Element commands,
 
@@ -0,0 +1,48 @@
+___
+
+## Link Schema Attribute Definition
+> Link a logical Data Field to the physical Schema Attribute that implements it (e.g. a TabularColumn), or the reverse lookup. Implemented via the generic MetadataExpert relationship mechanism (typeName: SchemaAttributeDefinition) -- no bespoke Egeria REST endpoint exists for this relationship yet (PYEGERIA_ISSUES.md ISSUE-48); will be migrated to a dedicated wrapper once Egeria ships one.
+
+### Data Field
+>	**Input Required**: True
+
+>	**Attribute Type**: Reference Name
+
+>	**Description**: A data field  name. Preferably a qualified name.
+
+
+### Schema Attribute
+>	**Input Required**: True
+
+>	**Attribute Type**: Reference Name
+
+>	**Description**: A physical schema attribute (e.g. a TabularColumn). Preferably a qualified name.
+
+
+### Label
+>	**Input Required**: False
+
+>	**Attribute Type**: Simple
+
+>	**Description**: A label used to identify or categorise a relationship link.
+
+>	**Alternative Labels**: Wire Label
+
+
+### Journal Entry
+>	**Input Required**: False
+
+>	**Attribute Type**: Simple
+
+>	**Description**: A text entry into a journal.
+
+
+### Description
+>	**Input Required**: False
+
+>	**Attribute Type**: Simple
+
+>	**Description**: A description.
+
+
+___