Preserve section-specific materials before course cross-listing

Setup requirements

1. The owners identify intentional differences before the agent considers any consolidation.

2. Use configuration and teaching-material copies only; exclude enrolment lists, submissions, grades and accommodations.

3. Record planned destination audience as intent, never as proof that the LMS will enforce it.

Inputs and access

1. Name

   section_materials

   Source or owner

   Course owners

   Scope

   Synthetic or approved nonpersonal syllabus and orientation text with source shell, content IDs and versions.

   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

   destination_content_manifest.csv

   Source or owner

   LMS administrator

   Scope

   Planned destination items, containers and intended section labels; configuration metadata only.

   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

   section_content_intent.txt

   Source or owner

   Course owners

   Scope

   Which blocks must remain distinct, which may be shared, and authoritative versions.

   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

   cross_listing_scope.txt

   Source or owner

   LMS administrator

   Scope

   Named source/destination shells and documented transfer scope; no enrolments or learner information.

   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

Combining course administration can leave two approved section variants with no clear destination. The administrator needs a retention map that protects intentional differences rather than assuming that similarly titled materials are interchangeable.

Suggested task

Compare supplied section materials and the planned destination inventory, mapping each approved content block to its intended section and flagging omissions or unintended shared variants.

What you could produce

A section-content retention matrix, source-labelled preservation packet and unresolved destination questions, ready for educator and administrator review.

Why an agent / simpler alternative

An agent may compare syllabus meaning and organize intentionally different blocks across multiple sources, producing understandable retention questions. Identity, coverage and destination joins should be deterministic. For two short documents, manual saved copies and an educator checklist may be simpler; a native cross-listing guide remains authoritative for actual product behavior.

Who this helps

1. LMS administrator

2. Academic program coordinator

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 content with stable IDs, source shell, version and section label, recording which transfer behavior is documented and which remains unknown.

   Input: Scope, source materials and destination inventory

   Output: Pre-change content inventory.

   Expected output: Pre-change content inventory.

   Checkpoint: No enrolment data is needed or accepted.

   Approval gate: Each course owner approves the authoritative nonpersonal material copies.

2. 2

   Separate genuinely shared content from owner-designated variants; compare materially different requirements even when file titles are identical.

   Input: Section intent and source blocks

   Output: Section-by-content intent matrix.

   Expected output: Section-by-content intent matrix.

   Checkpoint: Do not decide which syllabus rule is academically better or reconcile conflicting policies by invention.

   Approval gate: Educators determine intended variants and shared blocks.

3. 3

   Trace every required source block to a planned destination item and intended section, detecting omissions, one section receiving another’s variant and undesired shared defaults.

   Input: Intent matrix and destination manifest

   Output: Retention and misrouting findings.

   Expected output: Retention and misrouting findings.

   Checkpoint: A destination file’s presence does not prove its audience configuration or student visibility.

   Approval gate: No access-control, course membership or publication change is made.

4. 4

   Assemble separate source-labelled preservation copies and a proposed container/name map, retaining differences verbatim where authorized rather than synthesizing one universal policy.

   Input: Approved original blocks and findings

   Output: Draft preservation packet and placement map.

   Expected output: Draft preservation packet and placement map.

   Checkpoint: Preservation copies are separate local artifacts, not uploads or new LMS records.

   Approval gate: Owner approves any wording change; otherwise source content remains intact.

5. 5

   List the administrator checks needed to verify correct section presentation after any separately authorized change. Identify where a generic preview cannot establish section-specific behavior.

   Input: Placement map and known configuration limits

   Output: Section-aware verification checklist.

   Expected output: Section-aware verification checklist.

   Checkpoint: No student test account, real learner impersonation or permission adjustment is assumed.

   Approval gate: Administrator chooses and authorizes a supported nonpersonal verification method.

6. 6

   Deliver a block-level reconciliation showing retained, shared-by-approval, missing and unresolved destinations, with source references and pending academic decisions.

   Input: Inventory, variants and verification questions

   Output: Draft cross-listing content-retention packet.

   Expected output: Draft cross-listing content-retention packet.

   Checkpoint: Dates are preserved as content; this job does not shift term dates or run a clone check.

   Approval gate: Educators approve the content plan; administrator separately authorizes cross-listing or publication.

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}, compare supplied section materials and the planned destination inventory, mapping each approved content block to its intended section and flagging omissions or unintended shared variants. 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. source_shell_id

2. section_code

3. content_id

4. version

5. block_id

6. intent_shared_or_distinct

7. planned_destination

8. retention_state

9. variant_conflict

10. visibility_evidence_status

11. verification_question

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

Source block

SYN-B-SYL-WEIGHTS

Section

SYN-B

Approved text

Project 60%; exam 40%.

Destination item

SYN-SHARED-SYL

Destination text

Project 40%; exam 60%.

Shared permission

No

Illustrative expected output

Finding

section_variant_not_retained

Preserve source block

Yes

Proposed destination

pending educator/administrator decision

Visibility verified

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 different syllabi share the same filename.

2. A shared destination silently inherits one section’s requirements.

3. A generic preview appears correct.

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 different syllabi share the same filename.

   Recovery

   Use shell/content/version identity and preserve both variants.

   Resume condition

   Owners confirm which source is authoritative for each section.

2. Signal

   A shared destination silently inherits one section’s requirements.

   Recovery

   Mark the other section’s variant unretained; do not merge contradictory requirements.

   Resume condition

   Educator chooses a supported section-specific presentation plan.

3. Signal

   A generic preview appears correct.

   Recovery

   Do not pass section visibility from that evidence alone; identify the missing configuration check.

   Resume condition

   Administrator provides an authorized section-aware verification result.

Unexecuted validation plan

Sample setup

Design-only fixture with two synthetic sections. SYN-A uses Monday seminars and a project/exam weighting of 40/60; SYN-B uses Tuesday seminars and 60/40. Both have an identical owner-approved welcome block. The proposed destination contains only A’s syllabus under a shared label and the common welcome.

Acceptance checks

1. The B-specific seminar and weighting blocks are identified as lacking their intended destination.

2. The identical welcome block may be shared only because the fixture explicitly authorizes it.

3. The agent preserves both approved grading-policy descriptions without calculating grades or choosing one policy.

4. No inferred section visibility, student data, course mutation or automatic cross-list operation is reported.

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

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

7. 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. Material segmentation and educator review are unmeasured; the target LMS may require manual preservation and unsupported presentation choices must remain blocked.

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

Retain the institution’s section terminology and approved bilingual material variants. Academic and privacy requirements require institutional review; no deployment or compliance certification is claimed.