Identify unresolved course and marking-period submission statuses

Setup requirements

1. Require an expected-obligation register and a documented completion flag; no reconstruction from student gradebooks.

2. Replace staff identities with synthetic codes for the fixture and use minimum authorized identifiers in any later pilot.

3. Define export completeness, effective dates and deadline status explicitly; uncertainty must remain visible.

4. Require an explicit marking-period identifier or registrar-approved unambiguous mapping on every status row; term alone is insufficient.

Inputs and access

1. Name

   expected_submissions.csv

   Source or owner

   Registrar

   Scope

   Synthetic term_code, campus_code, course_period_id, marking_period_id and pseudonymous instructor_code with required/not-required and due-status flags. Two marking periods may occur in one term.

   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

   submission_status_export.csv

   Source or owner

   SIS administrator

   Scope

   Administrative submission flags, explicit marking_period_id, source term/campus/course-period identifiers or scoped aliases, and capture time only; no learner IDs, marks, scores, comments or individual results.

   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

   period_alias_dictionary.csv

   Source or owner

   Registrar

   Scope

   Scoped alias mappings keyed by term_code, campus_code and marking_period_id, with effective dates and explicit owner-approved exceptions. A missing or ambiguous marking-period mapping stays unresolved.

   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

   export_completeness_note.txt

   Source or owner

   SIS administrator

   Scope

   Explicit term, campus, course-period and marking-period coverage; included statuses, exclusion semantics and export snapshot date. Coverage for one marking period never attests coverage for another.

   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

An administrative completion report can use period aliases that do not uniquely identify the expected course-period submission. A registrar needs an evidence-backed exception list without reading student marks or interpreting teacher performance.

Suggested task

Reconcile owner-approved expected course-period/marking-period submissions with administrative completion flags, preserving ambiguous aliases, distinct grading windows and legitimate exemptions.

What you could produce

A course-period by marking-period completion matrix and registrar question list distinguishing submitted, incomplete, absent evidence, not yet due and unmapped statuses.

Why an agent / simpler alternative

An agent can translate inconsistent administrative labels and narrative registrar exceptions into a reviewable mapping, while explaining why some rows remain unresolved. Joins and category counts must be deterministic. A saved SIS report or spreadsheet lookup is preferable if the alias dictionary and completion semantics are already clean; the plan does not claim an agent is inherently necessary.

Who this helps

1. Registrar operations coordinator

2. Academic program 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

   Verify that the copies contain only administrative metadata and synthetic identifiers; inventory missing coverage before interpreting an absent status row.

   Input: Input schemas and completeness note

   Output: Scope and coverage manifest.

   Expected output: Scope and coverage manifest.

   Checkpoint: Any learner-level or sensitive data stops the intake; deletion or redaction is not silently delegated.

   Approval gate: Registrar separately approves exact minimized inputs before a future pilot.

2. 2

   Build each expected submission key from term_code, campus_code, course_period_id and marking_period_id. Resolve aliases only within the approved term/campus/marking-period scope and effective date; display one-to-many candidates without selecting one.

   Input: Expected obligations and alias dictionary

   Output: Expected-submission and alias bridge.

   Expected output: Expected-submission and alias bridge.

   Checkpoint: Identical course-period codes in two marking periods are distinct expected submissions. Neither matching alias text nor the same term permits collapsing the marking-period dimension.

   Approval gate: Registrar confirms mapping authority; names or similarity alone cannot establish identity.

3. 3

   Normalize documented administrative status labels while retaining raw values, timestamps and provenance. Keep submitted, partial, exempt, not yet due and unknown distinct.

   Input: Status export and owner definitions

   Output: Status vocabulary crosswalk.

   Expected output: Status vocabulary crosswalk.

   Checkpoint: A partial flag never becomes fully submitted, and an empty cell has no invented meaning.

   Approval gate: Registrar defines completion semantics; no grade value is inspected.

4. 4

   Join expected and observed sets on the full four-part submission key, retaining duplicates and conflicts within that key. Missing marking-period identity is unresolved. Mark absence as missing evidence only when completeness is attested for that exact marking period and course scope.

   Input: Expected keys, mapped statuses and coverage

   Output: Course-period by marking-period reconciliation matrix.

   Expected output: Course-period by marking-period reconciliation matrix.

   Checkpoint: Do not infer late conduct, noncompliance or teaching quality from a missing flag.

   Approval gate: No learner, teacher evaluation or eligibility decision occurs.

5. 5

   Separate data-mapping questions from genuine completion-status questions, and exclude not-required or not-yet-due records from an overdue-style follow-up list.

   Input: Exception matrix and approved administrative rules

   Output: Registrar review queue without performance ranking.

   Expected output: Registrar review queue without performance ranking.

   Checkpoint: No invented deadline, disciplinary label or automatic reminder recipient.

   Approval gate: Registrar reviews every question before any contact is contemplated.

6. 6

   Prepare a source-linked draft retaining all four key fields, snapshot time, marking-period-specific coverage caveats and owner-decision columns. Reconcile counts at full-key granularity, not distinct course-period counts.

   Input: Matrix, source references and questions

   Output: Draft submission-status administration packet.

   Expected output: Draft submission-status administration packet.

   Checkpoint: No marks are calculated, changed or transmitted; no teacher notification is sent.

   Approval gate: Registrar accepts the administrative interpretation and separately authorizes any follow-up.

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}, reconcile expected administrative submissions using the full term_code, campus_code, course_period_id and marking_period_id key, preserving ambiguous alias mappings and legitimate exemptions. 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. Keep two marking periods within the same term distinct; quarantine missing marking-period identity rather than guessing.

Expected output schema — proposed

Origin

editorial_proposal

Columns

1. term_code

2. campus_code

3. course_period_id

4. marking_period_id

5. instructor_code

6. required_flag

7. due_status

8. source_alias

9. mapping_state

10. raw_completion_flag

11. normalized_state

12. coverage_attested

13. source_row

14. registrar_question

15. owner_decision

Record status

draft_pending_owner_review

Primary key

1. term_code

2. campus_code

3. course_period_id

4. marking_period_id

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

Expected submissions

1. Term code

   SYN-2026-FALL

   Campus code

   SYN-WEST

   Course period id

   SYN-CP-A

   Marking period id

   SYN-MP-1

   Required flag

   Yes

   Due status

   due

2. Term code

   SYN-2026-FALL

   Campus code

   SYN-WEST

   Course period id

   SYN-CP-A

   Marking period id

   SYN-MP-2

   Required flag

   Yes

   Due status

   due

Observed statuses

1. Term code

   SYN-2026-FALL

   Campus code

   SYN-WEST

   Course period id

   SYN-CP-A

   Marking period id

   SYN-MP-1

   Flag

   complete

   Source row

   status:1

Complete export scopes

1. SYN-2026-FALL/SYN-WEST/SYN-CP-A/SYN-MP-1

2. SYN-2026-FALL/SYN-WEST/SYN-CP-A/SYN-MP-2

Illustrative expected output

1. Term code

   SYN-2026-FALL

   Campus code

   SYN-WEST

   Course period id

   SYN-CP-A

   Marking period id

   SYN-MP-1

   State

   submitted

   Source row

   status:1

   Notification sent

   No

2. Term code

   SYN-2026-FALL

   Campus code

   SYN-WEST

   Course period id

   SYN-CP-A

   Marking period id

   SYN-MP-2

   State

   missing_submission_evidence

   Source row

   expected:2; completeness:2

   Registrar question

   Is there additional administrative submission evidence for MP-2?

   Notification sent

   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. One alias maps to multiple course periods.

2. Two marking periods in one term collapse onto one course-period key, or a status without marking-period identity is applied to both.

3. A report contains only completed submissions.

4. Staff interpret the queue as a performance assessment.

5. 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

   One alias maps to multiple course periods.

   Recovery

   Retain candidate keys and quarantine that row from completion conclusions.

   Resume condition

   Registrar provides a scoped authoritative mapping.

2. Signal

   Two marking periods in one term collapse onto one course-period key, or a status without marking-period identity is applied to both.

   Recovery

   Quarantine rows lacking a unique marking-period mapping and rebuild the bridge and counts with the full four-part key. Never copy one period’s completion to another.

   Resume condition

   Registrar confirms period identities and completeness separately for each marking period.

3. Signal

   A report contains only completed submissions.

   Recovery

   Label absence as unobserved unless the export specification guarantees exhaustive coverage.

   Resume condition

   Administrator confirms semantics or supplies a complete status export.

4. Signal

   Staff interpret the queue as a performance assessment.

   Recovery

   Remove evaluative labels and retain only source-backed administrative states.

   Resume condition

   Registrar confirms the queue is used solely for submission administration.

Unexecuted validation plan

Sample setup

Design-only fixture: SYN-2026-FALL / SYN-WEST / SYN-CP-A has two expected submissions, SYN-MP-1 and SYN-MP-2. MP-1 is submitted; MP-2 is absent from an export attested complete for both. Add CP-B/MP-1 partial, CP-C/MP-1 ambiguous alias, CP-D/MP-2 not yet due, duplicate CP-A/MP-1 rows, a stale-term control, and a complete-flag row missing marking_period_id. No learner data exists.

Acceptance checks

1. Both SYN-CP-A/SYN-MP-1 and SYN-CP-A/SYN-MP-2 survive as separate full keys in the same term; MP-1 is submitted and MP-2 is missing evidence. Exactly two expected obligations remain for CP-A.

2. CP-B/MP-1 is incomplete, CP-C/MP-1 unmapped, and CP-D/MP-2 not yet due. Duplicate, stale-term and missing-marking-period controls do not overwrite either CP-A period.

3. Removing only the MP-2 completeness attestation changes CP-A/MP-2 to unknown coverage; CP-A/MP-1 remains submitted. A row without marking_period_id stays unresolved until authoritative mapping is supplied.

4. No student marks, student identifiers, employee ranking, disciplinary inference or eligibility outcome appears.

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. Whether a suitable administrative-only export exists is unknown. Alias cleanup and registrar review may dominate; no time saving or SIS integration 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 actual term and course-period vocabulary. Obtain institutional privacy approval before any real staff metadata is processed; no Canadian education or retention compliance claim is made.