Digital Assignment Platform (Education)

Paid pluginsize Mplanned, not built

Indicative price, not an offer: €34/mo; rubric grading, plagiarism detection (Turnitin integration)

Generated from docs/plan/paid/digital-assignment-platform/PLAN.md in the AstroBaaS repository. Nothing described below is implemented — it is the written plan for it.

Teachers need a system to assign, collect, and grade student work: submission tracking, late work flags, plagiarism detection integration, and rubric-based grading. This feature provides an assignment lifecycle from creation through grading and feedback.

The problem

I’m a teacher managing assignments via email and attachments. I can’t see which students submitted on time, there’s no central place for feedback, and no way to flag plagiarism or use rubrics for consistent grading.

What it does

• Assignment entity: title, description, due date, rubric rules (optional), submission limit (1 or multiple), allowed file types, max file size
• Assignment lifecycle: draft → published → closed (no new submissions after due date, but grading continues)
• Student submission: file upload with timestamp, late indicator (bool set at submission time based on due date), submission count per student (track multiples if allowed)
• Grading: score (integer 0–100), rubric score breakdown if rubric exists, written feedback per submission, grade status (submitted, graded, feedback-sent)
• Plagiarism flag: manual flag per submission or integration with Turnitin API (if configured), plagiarism score/percentage stored
• Rubric: list of criteria, each with point value and description; rubric_id on assignment, scores stored per criterion on submission
• Class/section: group students, bulk assign assignments to a class, bulk view grades
• Grade book view: all students × all assignments grid, sortable by student/assignment/grade, export to CSV
• Notifications: assignment published, due in 24h, submission received, grade posted, feedback available
• API endpoints: CRUD assignments, list submissions, POST grade, GET grade book

What it deliberately does NOT do

Each boundary carries its reason. A boundary without a reason gets crossed by the next person who reads this.

• Peer review workflows — student-to-student grading requires moderation, anonymization, and separate approval; out of scope
• Turnitin direct API integration beyond plagiarism-score storage — setting up the merchant’s Turnitin account and API key is their responsibility; we store what Turnitin returns
• Assignment reminders via SMS — we send email only; SMS is a separate channel and carrier
• Gradebook analytics and predictive grading — trend analysis and risk detection are post-1.0
• Assignment templates and reuse across classes — copying assignments is a manual operation in v1; templating is a UX feature, not a platform feature

Data model

New entity: Assignment {id, title, description, due_date, rubric_id (FK), submission_limit, allowed_file_types (JSON array), max_file_size_mb, class_id (FK), status, created_at, published_at, closed_at}. New entity: Submission {id, assignment_id, student_id, file_url, uploaded_at, is_late, plagiarism_score (nullable), plagiarism_provider, submission_number}. New entity: Grade {id, submission_id, score (0–100), rubric_scores (JSON), feedback_text, graded_at}. New entity: Rubric {id, title, criteria (JSON array of {criterion, points, description})}. Schema migration across all three drivers. Assume existing user/student entity.

API

• POST /api/assignments — create assignment (teacher only)
• GET /api/assignments/:id — fetch assignment with rules
• PATCH /api/assignments/:id — update assignment (teacher, before published)
• POST /api/assignments/:id/publish — mark as published (teacher only)
• GET /api/assignments/:id/submissions — list submissions for an assignment (teacher only)
• POST /api/submissions — student submits assignment (authenticated student only)
• GET /api/submissions/:id — fetch submission (student owner or teacher)
• POST /api/submissions/:id/grades — create or update grade (teacher only)
• GET /api/assignments/:id/gradebook — all submissions × students view (teacher only)
• GET /api/rubrics — list rubrics

Every route added here must also appear in src/pages/openapi.json.ts — a test fails the build if it does not.

Admin

Assignment manager: create/edit form (title, description, due date, select rubric, submission rules, file type restrictions). Publish button, close button. Assignment list with filter by class/status. Submissions panel: table with student name, submission time, is_late flag, plagiarism score (if available), grade status. Grade entry: score input, rubric criterion checkboxes, feedback textarea, save & notify student. Grade book grid: all students down left, all assignments across top, click to grade. Export button (CSV). Late submission highlighter (red row).

The seam — why this is paid

Core owns the assignment model, submission storage, grading state machine, and REST API. Paid layer owns Turnitin API integration (merchant’s API key, checking plagiarism score on upload, storing results), FERPA/GDPR compliance (student data retention policy, data export on teacher request, deletion on class close), and support for assignment workflows that involve third-party tools.

Support commitment: plagiarism vendor relationship, GDPR student-data handling

Dependencies

• User/student entity (assume it exists; link student_id on submission)
• File upload and storage (already shipping in core)
• Email notification system (already shipping in core)
• Class/section entity if support for grouping is required (may not exist; assume it does for this scope)
• Turnitin API key (optional; if not provided, plagiarism checks are manual/disabled)

Acceptance checks

Each of these must be able to fail. Before claiming this is done, break the code deliberately and watch each one go red.

• An assignment can be created with title, description, due date, and rubric selection; it is stored with status ‘draft’
• An assignment can be published; status changes to ‘published’ and students can see it
• A student can submit a file before the due date; submission is stored with is_late = false and upload timestamp
• A student who submits after the due date has is_late = true set automatically at submission time
• A teacher can grade a submission with a score and feedback; grade is stored and student is notified
• If a rubric is assigned, teacher can enter rubric criterion scores; they sum to the total score
• A grade book query returns all students × all assignments with scores; late submissions are flagged
• If Turnitin is configured and a submission is uploaded, plagiarism_score is populated from the API and stored

Risks

FERPA compliance is non-negotiable for U.S. schools; all student data must be encrypted at rest and purged on schedule. Plagiarism detection API failures must not block submission uploads — plagiarism check must happen async and the score populated later. Concurrent submissions from the same student must be sequenced (if submission_limit=1, earlier ones are replaced; if unlimited, each is a separate entry). File upload size limits prevent abuse; must validate file type and size before storing. Grade export (CSV) may contain PII — must be encrypted or require password to open in Excel.

Commercial context

The anchor is what the nearest equivalent charges on Shopify or Magento today. It is context for a pricing decision, not the decision.

---

Generated from the commerce plan. See docs/COMMERCE-PLAN.md for the full catalogue and ../../AI-GUIDE.md for how to work on this repository.