Syllabus Checker

Case study · AI Tools & Strategy

Faculty submit a syllabus, it is checked against MCCCD and program requirements, the instructor gets an itemized reply within seconds, and every submission is logged in one place.

Goal

Move syllabus compliance from a manual, end-of-review bottleneck to an instant, consistent check that runs at the moment of submission. The reason this matters is pedagogical before it is administrative. A complete, consistent, accessible syllabus is the first thing a student reads and the document they return to all term: it sets the expectations, names the support services, and carries the accommodation and response-time language that students who need it most depend on. When a required statement is missing or a deadline is unclear, the cost lands on the student as confusion, and on the faculty member as the emails and appeals that follow. Catching gaps before the term starts, rather than in week six when a problem surfaces, keeps the syllabus doing its job.

Two concrete outcomes follow. The instructor learns what is missing in seconds instead of weeks, with the correct approved wording supplied so there is nothing to go find, and the department sees the status of every section in one sortable place without opening a single attachment. The review it replaces is slow, its consistency depends on who is doing it, and it produces no single view of who has complied.

Audience

User	Need	What they receive
Faculty member	To know what is missing and fix it without hunting for the approved wording.	An email within seconds naming each gap, with the correct approved language supplied inline, ready to paste.
Department chair or administrator	To monitor compliance across every section of the term.	Status columns written back into the response spreadsheet they already own. One sortable log, not a forty-report inbox.

The split between those two outputs is the central design decision, and it is what keeps the tool serving people rather than burying them. Faculty need to act, so they get a message they can act on. The administrator needs to see the whole term, so she gets a log. Sending the administrator a copy of every individual report is not monitoring, it is drowning, and it is the mistake most compliance tools make. The department already collects syllabi through a Google Form on a college Workspace account, so faculty habit does not change, and the seat-hour profiles are currently written for the college Art and Humanities.

Process

Faculty submit through the existing Google Form. An onFormSubmit trigger fires inside the department’s Workspace, the script reads the approved-language document live and extracts the submitted syllabus text, normalizes and compares the two, emails the instructor the itemized report, and writes status columns back to the response sheet. Two design choices carry most of the trust.

The approved language is read live, never copied

The script reads the reference document on every run and stores no copy. A stale stored copy is how compliance checklists fail: the department revises the wording, nobody updates the checker, and the tool starts approving syllabi against language that is no longer current. Reading live means the check is correct the same minute the source document changes, and there is nothing to maintain.

Deterministic where it matters

Whether an approved statement appears verbatim is a string comparison, not a judgment call. A language model would be worse at it, because it might decide a paraphrase counts as a match, and on text an accreditor reads, a confident wrong answer is the worst possible outcome. So the model is reserved for the ambiguous Reg 3.6 elements and clearly labeled as a suggestion, and the tool delivers most of its value with the model turned off. Before any comparison, both texts are normalized (curly quotes to straight, dashes to hyphens, whitespace collapsed, case lowered), because a verbatim check that fails on a curly apostrophe is useless and formatting noise must never produce a false failure.

Check	Method	Uses AI
Approved seat-hours statement	Verbatim string comparison against the live document, after normalization.	No
RSI statement (online and hybrid only)	Fingerprint phrase match, conditional on modality, never asserted when modality is unknown.	No
Combined-section integrity	Flags a section marked combined with no associated class numbers listed.	No
Class-number format	Regex against PREFIX###-#####.	No
Submission deadline	Computed from the class start date, the Friday of the first week.	No
MCCCD Reg 3.6 elements (Title IX, accommodations, response time, and similar)	Keyword match for the literal ones, a model for the fuzzy ones.	Partly

Reading the syllabus, and its limit

Google Docs are read natively through DocumentApp, and Word files are converted through Drive and the temporary copy discarded. PDF text extraction is imperfect, and a verbatim check against imperfectly extracted text produces false failures, so when a submission is a PDF the report says plainly that extraction may be unreliable and tells the instructor to resubmit as a document if it flags language they know is present. The tool never fails anyone silently, and the durable fix is policy rather than code: ask the department to accept Google Docs and Word. Syllabus+ PDF URLs are accepted by the form but not yet followed; that needs a fetch-and-parse step and inherits the same extraction limit.

The reports

• To the instructor: an email, complete or incomplete, with each finding named and the approved wording supplied where relevant.
• To the department: four columns written into the existing response sheet (check status, missing items, file type, date checked), with the status cell colored by state in solid colors.
• Optional weekly digest of what is still outstanding.

Privacy

A syllabus is instructor content, not student content. It is a course document written by the faculty member and distributed to a class, containing no grades, no enrollment records, no submissions, and no student identifiers, so no FERPA-protected record is created, transmitted, or stored anywhere in this workflow. The system never touches a student record and has no path to one.

• There is no database, no logging, and no analytics. The only things written anywhere are a status value in a spreadsheet the department already owns and an email to the person who submitted.
• Everything runs inside the district’s own Google tenant, and the default configuration uses no AI, so nothing is sent to an external service.
• If the optional fuzzy Reg 3.6 checks are enabled, the only text sent to a model is syllabus prose written by the instructor; the instructor’s name and email stay in the Workspace layer and are never included in a model call. If the district prefers that no content leave the tenant at all, the fuzzy checks turn off and the deterministic checks still run.
• The script is read-only, with no write access to any submitted syllabus, and it is owned by the department account rather than a personal one, so it survives staff turnover.

Build and portability

The tool is Google Apps Script bound to the department’s existing Google Form, triggered by onFormSubmit with no polling or scheduler. Its source of truth is the department’s approved-language Google Doc read live on every run, it logs to the form’s own Google Sheet, and it notifies through Gmail, all on the college Workspace account. A static HTML page on GitHub Pages demonstrates the workflow; the working system runs in Workspace.

Apps Script is the right runtime because the department already lives in Google Workspace: the script runs there as an authorized user with access to Docs, Drive, Sheets, and Gmail already granted, so there is no OAuth consent screen to publish, no client secret to protect, no server to host, no CORS proxy, and no vendor. It already runs on district infrastructure, under accounts, permissions, and audit logging that OIT administers, so installation is an administrative authorization on the department account, not a deployment.

The optional AI call sits behind one interface, text in and findings out, so nothing else depends on which model answers. It can point at Claude, at Gemini (already inside the Workspace tenant and the lowest-friction option for a district that wants no traffic leaving Google), or at a district-hosted endpoint, and swapping providers changes one function rather than the tool. Because the deterministic checks carry most of the value, the system runs correctly with no model at all. Serving more than one department is configuration, not a rebuild: each supplies its own form, approved-language document, and department account, while the district-wide Reg 3.6 elements are the portable core and need no work. There is no multi-tenant version and none is planned, because ten small scripts each department owns fit how these forms are actually administered better than one central system nobody owns. The known fragilities to fix before it travels are matching form fields by ID rather than exact title (a reworded question currently makes the script read nothing) and adding a modality question so RSI applicability is asked rather than inferred.

Status

The check logic and interface were built in June 2026: the deterministic checks, the live approved-language read, normalization, the faculty email report, and the response-sheet status columns. The tool is a prototype in testing, not in production, and the one blocking dependency is administrative rather than technical, nothing runs until the account that owns the form authorizes the script.

The intended way to earn trust before anyone relies on it is a shadow-mode term: run the checker on every syllabus submitted through the existing form in one department, log the results, and send no faculty email, while the manual review continues in parallel as the system of record. The point is to compare the checker against the human reviewer and count false failures (flagging language that is present) separately from misses (passing a syllabus that is missing something), since a false failure destroys trust fastest. The bar to move past prototype is strict: zero false failures and zero misses on the deterministic checks against Google Doc and Word submissions, because those are string comparisons and anything above zero is a bug rather than a tolerance; a clear reduction in the reviewer’s manual verbatim-checking time, reported by the person doing it; faculty who can act on the report without asking what it means; and every unreadable file reported as unreadable rather than guessed. Disagreement on the AI-assisted fuzzy elements is expected, which is exactly why they are labeled suggestions and never failures. Only after that would faculty email turn on, with the manual review kept as a backstop for one more term, and any offer to a second department or another college would be configuration taken one step at a time, with OIT and the ARC asked to review the AI configuration and put the data boundary in writing first.