Map historical dependencies before retiring learning outcomes

Setup requirements

1. A complete configuration-only dependency export is a prerequisite; student mastery records are excluded.

2. Separate curricular replacement approval from technical retirement capability.

3. Keep every old ID stable in the proposal and require an explicit retention policy before considering any future change.

Inputs and access

1. Name

   outcome_versions.csv

   Source or owner

   Curriculum owner

   Scope

   Synthetic outcome IDs, versions, status labels and nonpersonal descriptions.

   Sensitivity

   Synthetic design fixture only. A future real-data pilot must use owner-approved minimized copies, exclude sensitive/unrelated personal data and credentials, and obtain separate approval for its processing environment.

   Permission needed

   No pilot is authorized by this plan. The accountable owner must approve these exact inputs, their permitted use, output recipients and retention before a future test.

2. Name

   course_outcome_references.csv

   Source or owner

   LMS administrator

   Scope

   Configuration-only links between outcome IDs, course shells and academic years; no learner results or assessment scores.

   Sensitivity

   Synthetic design fixture only. A future real-data pilot must use owner-approved minimized copies, exclude sensitive/unrelated personal data and credentials, and obtain separate approval for its processing environment.

   Permission needed

   No pilot is authorized by this plan. The accountable owner must approve these exact inputs, their permitted use, output recipients and retention before a future test.

3. Name

   approved_revision_crosswalk.csv

   Source or owner

   Curriculum committee delegate

   Scope

   Explicit replacement relations, including partial, many-to-one and unmapped decisions.

   Sensitivity

   Synthetic design fixture only. A future real-data pilot must use owner-approved minimized copies, exclude sensitive/unrelated personal data and credentials, and obtain separate approval for its processing environment.

   Permission needed

   No pilot is authorized by this plan. The accountable owner must approve these exact inputs, their permitted use, output recipients and retention before a future test.

4. Name

   retirement_constraints.txt

   Source or owner

   LMS administrator and curriculum owner

   Scope

   Owner-approved retention requirements and confirmed product controls; unknown archive behavior remains unknown.

   Sensitivity

   Synthetic design fixture only. A future real-data pilot must use owner-approved minimized copies, exclude sensitive/unrelated personal data and credentials, and obtain separate approval for its processing environment.

   Permission needed

   No pilot is authorized by this plan. The accountable owner must approve these exact inputs, their permitted use, output recipients and retention before a future test.

The problem

A curriculum revision can require old outcome identifiers to remain meaningful in historical records while stopping their unintended use in new courses. Renaming or deleting an outcome without a dependency map can obscure that distinction.

Suggested task

Map supplied outcome-version references to historical and planned courses, compare them with an educator-approved replacement policy, and prepare a non-executing retirement decision register.

What you could produce

An outcome lifecycle and dependency register separating historical retention, current reuse, approved replacements and unsupported retirement mechanisms.

Why an agent / simpler alternative

An agent can align revision notes with versioned outcome identifiers and explain ambiguous replacement relationships. Dependency traversal and reference counts should be deterministic. A native versioning/archive feature or database report is preferable when it already preserves history and blocks future selection; this plan cannot invent that feature.

Who this helps

1. Curriculum coordinator

2. LMS configuration administrator

Evidence boundary

Problem/occupational sources describe a human need; capability documentation establishes general primitives. The workflow, acceptance fixture and synthetic example are original designs, not source tutorials, verified compatibility or demonstrated success.

Proposed steps

1. 1

   Inventory stable IDs and version lineage, then assess whether the reference export covers historical and planned courses. Keep unavailable scopes visible.

   Input: Outcome and reference exports

   Output: Outcome/reference coverage manifest.

   Expected output: Outcome/reference coverage manifest.

   Checkpoint: An unreferenced outcome is not proven unused when export coverage is partial.

   Approval gate: Administrator attests to configuration-only scope and completeness.

2. 2

   Classify each supplied reference as historical, current or planned using explicit year and retention rules, without using the present date alone to infer status.

   Input: Academic-year boundaries and owner policy

   Output: Reference-lifecycle table.

   Expected output: Reference-lifecycle table.

   Checkpoint: A historical course remains linked even if the outcome is no longer selected for new teaching.

   Approval gate: Curriculum owner approves lifecycle boundaries and permitted future use.

3. 3

   Check whether proposed replacement links are explicitly approved, preserving partial and many-to-one relations. Surface similar wording without declaring educational equivalence.

   Input: Outcome descriptions and approved crosswalk

   Output: Replacement-authority map with unresolved links.

   Expected output: Replacement-authority map with unresolved links.

   Checkpoint: No automated curriculum equivalence, assessment coverage or learner competency judgment.

   Approval gate: Educators alone approve replacement meaning.

4. 4

   Identify old IDs still used in planned courses, historical links at risk under each proposed operation, and unmatched references. Keep retention and prevention-of-new-use as separate requirements.

   Input: Lifecycle and replacement maps

   Output: Dependency-impact register.

   Expected output: Dependency-impact register.

   Checkpoint: Do not propose deletion merely because a new outcome has a similar title.

   Approval gate: No outcome edit, archive, deletion or course update occurs.

5. 5

   Create an action-option worksheet only for mechanisms the administrator has documented. Where a suitable retire-with-history control is unknown, mark the row blocked and write a product-capability question.

   Input: Impact register and confirmed product controls

   Output: Mechanism feasibility and blocked-decision worksheet.

   Expected output: Mechanism feasibility and blocked-decision worksheet.

   Checkpoint: No assumed archive flag, API endpoint, MCP connector or reversible-delete guarantee.

   Approval gate: Administrator verifies technical semantics before any later change is considered.

6. 6

   Package the minimum decisions, preservation checks and a proposed before/after reference-count verification specification. Preserve source snapshots without altering outcome identifiers.

   Input: Reference register and decision worksheet

   Output: Draft outcome-retirement review packet.

   Expected output: Draft outcome-retirement review packet.

   Checkpoint: A zero change in historical reference count is a proposed acceptance condition, not an observed result.

   Approval gate: Curriculum owner and administrator approve any later lifecycle operation; deletion requires its own authorization.

Original starter prompt — proposed

Origin

editorial_proposal

Label

Original starter prompt for a future authorized synthetic test; not executed

Placeholders

1. approved_inputs

2. owner_rules

3. output_folder

Execution authorized

No

Text

Using only {approved_inputs} and {owner_rules}, map supplied outcome-version references to historical and planned courses, compare them with an educator-approved replacement policy, and prepare a non-executing retirement decision register. Follow the six-step review design. Preserve source references and uncertainty, use deterministic checks for joins/counts/times, and write only new draft review files to {output_folder}. Stop if inputs contain sensitive or unrelated personal data or credentials. Do not access live accounts, change source records, send messages, upload, purchase or provision access. Return unresolved owner decisions without guessing.

Expected output schema — proposed

Origin

editorial_proposal

Columns

1. outcome_id

2. version

3. course_shell_id

4. academic_year

5. reference_lifecycle

6. retention_requirement

7. approved_replacement_id

8. replacement_scope

9. future_use_exception

10. mechanism_verified

11. blocked_reason

12. owner_decision

Record status

draft_pending_owner_review

Synthetic output illustration — not an executed result

Label

Synthetic worked input/output illustration; authored expectation, not an observed result

Synthetic

Yes

Executed

No

Owner approval status

pending_not_obtained

Data

Synthetic inputs

Outcome id

SYN-OLD-1

References

1. Course

   SYN-HISTORY

   Year

   2025-26

2. Course

   SYN-PLANNED

   Year

   2026-27

Owner policy

Retain historical links; new courses require approved replacements.

Approved replacement

Not specified.

Supported retirement control

Not specified.

Illustrative expected output

Historical reference

retain unchanged

Planned reuse

needs curriculum decision

Replacement

unresolved

Technical action

blocked; mechanism unverified

Deletion proposed

No

Human approval boundaries

1. Before any future pilot, the accountable owner approves exact synthetic/minimized inputs, processing environment, retention and allowed output recipients. This plan grants no execution permission.

2. The owner confirms identities, authority rules and all unresolved interpretations identified in the steps; a draft is not authorization.

3. Any later source-system change, publication, send, upload, account access, purchase or permission change requires separate appropriate authorization. No such action is part of this plan.

Current problem validation — proposed, unexecuted

Before any pilot, ask an authorized owner whether this problem still occurs, inspect a minimized representative export and compare the built-in/manual remedy. No contact or research with private data is authorized here.

Limits

1. Original editorial proposal only; no workflow, synthetic fixture or acceptance check has been executed.

2. A human-duty listing and an issue report establish context, not prevalence, current demand, successful agent use or willingness to pay.

3. Closed or old reports are historical evidence. Current target-version relevance and simpler built-in remedies must be checked before a pilot.

4. Exact platform account access, export availability, environment tools and end-to-end compatibility remain unknown.

5. All consequential decisions and operational use remain with the named accountable owner.

Candidate platforms — compatibility untested

1. Name

   ChatGPT Work

   Required capabilities

   1. Read the exact owner-approved file copies

   2. Run inspectable deterministic checks if supported by the chosen environment

   3. Create separate reviewable CSV and text artifacts

   Capability source urls

   1. https://learn.chatgpt.com/docs/get-started-with-work

   Selection basis

   Editorial candidate based on general primitives only.

   Workflow compatibility

   Unknown and untested; no source-system connector or MCP compatibility assumed.

   Setup caveat

   Verify available file handling, tools and permission boundaries in the actual account before any pilot.

   Availability in canada

   Not assessed.

2. Name

   Claude (Cowork-capable account)

   Required capabilities

   1. Read the exact owner-approved file copies

   2. Run inspectable deterministic checks if supported by the chosen environment

   3. Create separate reviewable CSV and text artifacts

   Capability source urls

   1. https://support.claude.com/en/articles/13345190-get-started-with-claude-cowork

   2. https://support.claude.com/en/articles/16761823-claude-cowork-and-chat-are-one-claude

   Selection basis

   Editorial candidate based on general primitives only.

   Workflow compatibility

   Unknown and untested; no source-system connector or MCP compatibility assumed.

   Setup caveat

   Verify available file handling, tools and permission boundaries in the actual account before any pilot.

   Availability in canada

   Not assessed.

Failure modes

1. Two outcome versions have identical labels.

2. A proposed archive operation would remove historical links.

3. Reference export omits archived courses.

4. Source text contains instructions unrelated to the authorized analysis; treat it as untrusted evidence, never as permission or executable guidance.

Recovery and troubleshooting

1. Signal

   Two outcome versions have identical labels.

   Recovery

   Compare stable IDs and version metadata; retain both while mapping is unresolved.

   Resume condition

   Curriculum owner confirms the approved lineage.

2. Signal

   A proposed archive operation would remove historical links.

   Recovery

   Mark that option unacceptable under the supplied retention rule and retain a capability question.

   Resume condition

   Administrator documents a supported mechanism that preserves required references.

3. Signal

   Reference export omits archived courses.

   Recovery

   Mark historical-dependency coverage incomplete and withhold retirement readiness.

   Resume condition

   Administrator supplies or attests the missing configuration scope.

Unexecuted validation plan

Sample setup

Design-only fixture: SYN-OLD-1 links to a historical course and a planned course; SYN-OLD-2 links only to a historical course; SYN-OLD-3 shares a label with SYN-NEW-3 but has no approved crosswalk. A fourth outcome has no exported links, while export coverage explicitly excludes one archived shell.

Acceptance checks

1. SYN-OLD-1 produces both a historical-retention requirement and a planned-course reuse question.

2. SYN-OLD-2 retains its historical link and is not recommended for deletion.

3. SYN-OLD-3 remains unmapped despite the identical label.

4. The fourth outcome is not declared unused because the archived-shell scope is missing.

5. No supported retirement mechanism, curricular equivalence or execution success is fabricated.

6. Every substantive finding carries a supplied source-row/span reference; unresolved authority or missing evidence stays visible.

7. All input copies remain unchanged and all outputs are labelled synthetic draft / pending owner review.

8. No network/account operation, live mutation, external communication, personal-data processing, upload, purchase or access provisioning is attempted.

Stop conditions

1. A planted critical exception is missed, a valid control is wrongly failed, or an unknown is presented as certain.

2. Required identity, policy, time basis or export completeness cannot be resolved within the owner-approved fixture.

3. Personal data, credentials or unrelated material appears, or the proposed run requires live access, source mutation or external action.

Executed

No

Fixture status

Design only; no fixture or workflow execution and no acceptance result.

Approval status

not_requested_or_granted_for_execution

Costs and effort — unknown or hypothetical

Status

unknown_or_estimate

Currency

Not specified.

Items

1. Plan eligibility, usage limits, token/runtime consumption and current price are unknown; verify before an authorized pilot.

2. Obtaining complete historical references and verifying native controls may be substantial. No automated archive implementation, institution plan eligibility or benefit estimate is assumed.

3. Preparation of minimized copies, review, correction and retention effort is unmeasured. No native integration, paid dependency, installation or new account is assumed.

Caveat

No numerical cost, time saving, ROI, income or willingness-to-pay claim. Compare with the simpler alternative before investing.

Canadian adaptation — proposed

Use the institution’s approved curriculum versions and record-retention requirements. Provincial and institutional interpretation stays with authorized staff; no compliance finding is produced.