CIEL Lab MCP: Support update and retirement operations in Propose Bulk Edit

[filiperochalopes]

User story

As a CIEL curator, I want MCP to propose updates and retirements of existing names and descriptions so that I can review and apply terminology changes conversationally instead of being limited to adding new resources.

Use case

propose_bulk_edit currently supports proposals that add data to concepts.

The workflow should support three distinct operation types:

• INSERT — add new resources.
• UPDATE — modify existing resources.
• RETIRE — logically remove existing resources using OCL retirement.

A single proposal/table must contain only one operation type. Operations must never be mixed within the same Propose Bulk Edit table.

If a user request requires inserts, updates, and retirements, MCP should create separate proposals for each operation.

The same concept may therefore appear in multiple proposals when different resources or operations are involved.

MVP scope

• Preserve the existing INSERT behavior.
• Add UPDATE support for:
  • Names.
  • Descriptions.
• Add RETIRE support for:
  • Names.
  • Descriptions.
• Allow multiple concepts/resources in a proposal as long as every row represents the same operation type.
• Clearly identify the operation represented by the proposal/table.

Update behavior

• Retrieve and identify the existing resource being updated.
• Present the proposed new value in the editable Propose Bulk Edit table.
• Preserve the resource identity required to update the existing OCL resource rather than creating a new one.
• Allow the curator to edit the LLM-generated proposal before applying it.

Retirement behavior

• Treat removal requests as OCL logical retirement rather than physical deletion.
• Identify the existing name or description that will be retired.
• Include a required retirement reason for each proposed retirement.
• Allow the LLM to generate the retirement reason from the user's request and conversation context.
• Keep the generated reason editable by the curator before applying the proposal.
• Do not execute retirement without a reason.

Operation separation

• A proposal must be exclusively INSERT, UPDATE, or RETIRE.
• If the user's request requires multiple operation types, generate separate Propose Bulk Edit proposals.
• Never combine operation types into a single editable table.
• Different proposals may reference the same concept when necessary.

Acceptance criteria

• A curator can request an update to an existing name through MCP and receive an UPDATE proposal.
• A curator can request an update to an existing description through MCP and receive an UPDATE proposal.
• A curator can request retirement of an existing name or description and receive a RETIRE proposal.
• Retirement proposals always contain an editable reason.
• Applying an UPDATE modifies the existing resource rather than inserting a duplicate.
• Applying a RETIRE marks the existing resource as retired according to OCL semantics.
• A single proposal never contains mixed operation types.
• A request requiring multiple operation types results in separate proposals/tables for each operation.
• All proposed values and retirement reasons remain reviewable and editable by the curator before execution.

[filiperochalopes]

@askanter

Two concrete use cases for the proposed UPDATE and RETIRE operations should be highlighted:

1. Clean up duplicated Spanish names

During previous Spanish terminology work, some concepts ended up with duplicated Spanish names, particularly duplicated Fully Specified Names.

This is a good use case for MCP-assisted curation because the curator could ask MCP to:

• Identify the affected resources.
• Propose UPDATE when an existing name needs correction.
• Propose RETIRE when a duplicated name should be logically removed.
• Generate the retirement reason from the context while keeping it editable before execution.

This allows cleanup to remain explicit and curator-reviewed instead of performing automatic destructive normalization.

2. Normalize and structure existing descriptions

A second important use case is preparing existing CIEL descriptions for deterministic fragmentation into structured description properties.

The attached analysis identified 43 descriptions requiring some form of normalization/review. The cases include:

• 10 descriptions with markers requiring case normalization.
• 16 descriptions containing URLs that are not explicitly marked as references.
• 10 descriptions containing unmarked citation patterns.
• 6 descriptions containing definition cues that may need explicit structural treatment.
• 1 description containing an unmarked DOI.

There are also descriptions where markers already exist but are not in their canonical representation. Examples include ref, Ref, and Caption, which should be normalized according to the canonical property/marker convention.

The MCP workflow could therefore propose UPDATE operations that transform existing descriptions into their canonical structured form while presenting every change in the editable Bulk Edit table before execution.

For example, descriptions containing an implicit reference could be transformed from:

<description text> https://...

into the canonical representation expected by the description-property parser, with the reference explicitly identified as REF.

Likewise, existing variants such as ref, Ref, or non-canonical Caption markers could be normalized consistently.

This is particularly valuable because these are semantic transformations of existing resources rather than additions. They therefore provide a concrete reason for extending propose_bulk_edit beyond its current insert-only behavior.

[ocl-automation]

Automated Triage — 2026-09-18

Dimension	Score
Complexity	4
Scope	3
Clarity	5
Dependency	2
Risk	4

Decision: decision/human-review
Type: type/feature
Signals: signal/high-risk, signal/well-specified

Complex feature requiring significant design decisions for three distinct operation types (INSERT/UPDATE/RETIRE) with different behaviors, resource identification, and OCL semantics. Scope is contained within the MCP module but touches multiple components. Fully specified with comprehensive acceptance criteria and detailed requirements. High risk because incorrect updates or retirements could corrupt terminology data used by OpenMRS implementations.

---

Generated by ticket-triage pipeline v3. Model: anthropic/claude-sonnet-4 (openrouter).