On ‘Edit’, Uploaded Schemas as Source of Truth

[thelmick-unicon]

Goals: Determine how schema uploads affect the existing data model. Define rules for conflicts and other changes that could disrupt data models.

Context: When editing by uploading a schema, should it be treated as the source of truth, with all changes being accepted into the system, or should there be a step that allows for confirmation or rejection of the changes from the uploaded schema? Additionally, schema uploads when editing can introduce conflicts and invalid changes that could break a data model.

Questions: How should schema uploads be handled by the MDR? What kind of changes should a schema upload be allowed to fail on? Warn on? Ignore or auto-correct?

• Should an uploaded schema completely overwrite the existing schema to match the uploaded schema?
• Should uploaded changes be processed one by one to allow rejection or acceptance of each change?
• How should conflicts, deletions, and invalid changes be handled?
• Example: Removing an entity that is referenced in another location
• Example: Adding a reference without an existing embed

[thelmick-unicon]

AI Summary of feedback from 2/13/2026 Wallet Users Community Call:

From Duncan Cox (Learning Economy Foundation)

• Emphasized the importance of not fully deleting attributes outright when schemas are edited or re-uploaded.
• Shared that their organization often captures more data than they initially use, and may reuse unused attributes later for new experiments or validation efforts.
• Suggested thinking in terms of a “remix” or versioning approach rather than destructive overwrites.
• Indicated preference for:
  • Retaining attributes
  • Possibly only removing associations or placements
  • Supporting versioned schemas that allow subtle variations without losing original structure

Underlying theme:
Preserve data and enable reuse. Avoid destructive changes that eliminate potentially valuable elements.