[Out of scope - Arch] guardrails for editing or deleting a graded assignment used in a mastery calculation

Out of scope. Recorded so the idea is not lost, not scheduled for build. Product asked for this to be documented as a future nice-to-have rather than built as part of the guardrails work.

User Story

As a course author, I want to be warned before I change or delete a graded assignment that learners have earned competency mastery through, in order to not silently invalidate the basis of mastery those learners have already been credited with.

Acceptance Criteria

Scenario: Editing a graded assignment used in a mastery calculation warns the author
  Given a graded assignment that a competency criterion is attached to
    And learners have earned mastery through that criterion
  When the author edits that assignment in a way that changes how it is graded
  Then a warning is shown explaining the effect on competency mastery
    And the change is not applied until the author confirms

Scenario: Deleting a graded assignment used in a mastery calculation warns the author
  Given a graded assignment that learners have earned competency mastery through
  When the author deletes it
  Then a warning is shown explaining the effect on competency mastery
    And the deletion is not applied until the author confirms

Scenario: An assignment nothing depends on behaves as it does today
  Given a graded assignment with no competency criterion attached
  When the author edits or deletes it
  Then the action behaves exactly as it does today with no additional warning

Description

The guardrails work protects competency configuration: tags, taxonomies, tag associations, criteria, and criteria groups. It does not protect the graded content underneath them. An author can still change an assignment's grading policy, restructure it, or delete it outright, and nothing warns them that learners have earned competency mastery through it.

Deleting such an assignment is the sharper case. The tag association pointing at it would be retired rather than destroyed, so learner mastery survives, but it would then reference content that no longer exists, and nothing in the authoring experience would have said so.

Technical Details

This section is background and a suggested approach, not the ticket's source of truth. The User Story and Acceptance Criteria define what must be true when the work is done.

In short

Why this is harder than the rest of the guardrails work, and why it was deferred. Everything else in this use case guards records that live in this library, where a lock can be set and a delete path can branch. A graded assignment is course content, owned by the platform, edited through the Course Outline and the problem editors. Guarding it means either the platform asking this library whether a given block matters before allowing an edit, or this library pushing something into the platform's content model. Neither exists, and choosing between them is an architecture decision rather than an implementation detail.

Deciding what counts as a consequential edit is a product question. Deleting the assignment is clear. Changing its grading policy or its weight plausibly matters. Fixing a typo in a problem's text plausibly does not. Warning on every edit to any block a competency touches would be noise; warning on the right subset needs someone to define the subset.

The tag association survives, which changes what the warning should say. Because a depended-upon association is retired rather than destroyed, learner mastery is not lost when the content goes away. So the honest warning is not "learners will lose their mastery" but something closer to "learners have earned mastery through this and it will refer to content that no longer exists." That framing needs design.

Implementation specifics

• Requires an architecture decision first on which side asks the question: the platform consulting this library before an edit or delete, or this library pushing a marker into the platform's content model. The deletion-lock design in 10.4 is push-based for records inside this library, but content blocks are not this library's records, so that pattern does not transfer directly.
• Requires a product decision on which edits are consequential enough to warrant a warning, and which are not.
• The affected surfaces are in the platform and the authoring frontend, not in this library: the Course Outline page, the problem and assignment editors, and whatever delete path the outline uses.
• Out of scope even within this placeholder: any automatic re-evaluation or invalidation of learner mastery when the underlying content changes, which is a separate and larger question.
• Context The approved implementation approach on #655, which lists gradeable subsection behavior as out of scope for the guardrails work.
• 10.6 explains why a depended-upon tag association is retired rather than destroyed, which is what determines the honest wording for any warning here.
• #699 and #643 describe how a graded assignment's result becomes competency mastery.

Open Questions

• Which side owns the question, the platform asking this library before an edit, or this library pushing a marker into the platform's content model? This needs an architecture decision before the ticket can be written properly. Owner: architect.
• Which edits to a graded assignment are consequential enough to warrant a warning? Owner: BA, with product.
• Should there be any warning at all for an edit, given that no edit invalidates already-earned mastery, or only for a delete? Owner: BA.

No implementation files or tests are identified; the affected surfaces are the Course Outline, problem and assignment editors, and the outline's delete path. Start by resolving the architecture decision and consequential-edit scope with the owners, using #655, 10.6, #699, and #643 for context. Done means the agreed warning behavior and confirmation flow satisfy the acceptance scenarios.