Syllabus Checker

Course Design · Case study

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.

1. Summary

The check logic and interface are built: the deterministic checks, the live approved-language read, normalization, the faculty email report, and the response-sheet status columns. The tool is in use for syllabus submissions in the department.

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

3. Users and context

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’s Art and Humanities department.

4. How it works

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 the approved wording needs no upkeep in the script.

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.

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.

Requirements and acceptance criteria

Each requirement is one behavior. The checks beside it are what a builder or tester confirms before that requirement is called done. Status reflects what this document records as built.

#	Area	Requirement	Done when	Status
R1	Build and portability	The Syllabus Checker must run as Google Apps Script bound to the department’s existing Google Form and start on each form submission.	Submitting the form starts one run of the script with no manual step. The project has an onFormSubmit trigger and no polling or time-based trigger for the check. The script is owned by the department account and not by a personal account.	Built
R2	The approved language is read live, never copied	The Syllabus Checker must read the approved-language document on every run and keep no copy of it.	After the approved wording is edited in the reference document, the next submission is checked against the new wording with no change to the script. No approved wording is found in the script source, in script properties or in the response sheet.	Built
R3	Deterministic where it matters	The Syllabus Checker must normalize both the approved text and the syllabus text before any comparison.	A syllabus that contains the approved statement with curly quotes or a curly apostrophe passes. A syllabus that contains the approved statement with long dashes in place of hyphens passes. A syllabus that contains the approved statement with extra spaces, line breaks or different capitalization passes.	Built
R4	Deterministic where it matters	The Syllabus Checker must check that the approved seat-hours statement appears verbatim in the syllabus.	A syllabus containing the exact approved statement is reported as having it. A syllabus containing a paraphrase of the statement is reported as missing it. The check gives the same result with the model turned off.	Built
R5	Deterministic where it matters	The Syllabus Checker must check for the RSI statement by fingerprint phrase only when the course is online or hybrid.	An online or hybrid syllabus without the RSI fingerprint phrase is reported as missing the RSI statement. An in-person syllabus without the RSI statement is not flagged for it. When modality is unknown, the report makes no pass or fail claim about the RSI statement.	Built
R6	Deterministic where it matters	The Syllabus Checker must flag a section marked combined that lists no associated class numbers.	A submission marked combined with no associated class numbers is flagged. A submission marked combined with associated class numbers listed is not flagged. A submission not marked combined is not flagged.	Built
R7	Deterministic where it matters	The Syllabus Checker must validate each class number against the pattern PREFIX###-#####.	A class number of three letters, three digits, a hyphen and five digits passes. A class number with a missing hyphen or a wrong digit count is flagged and named in the report.	Built
R8	Deterministic where it matters	The Syllabus Checker must compute the submission deadline as the Friday of the first week from the class start date.	For a given class start date, the deadline shown is the Friday of that first week. A submission made after the computed deadline is identified as late, and one made on or before it is not.	Built
R9	Deterministic where it matters	The Syllabus Checker must check the literal MCCCD Reg 3.6 elements by keyword match.	A syllabus missing a literal Reg 3.6 element has that element named as a gap in the report. A syllabus containing the keywords for every literal element has none of them flagged. The literal checks give the same result with the model turned off.	Built
R10	Deterministic where it matters	The Syllabus Checker must send the ambiguous Reg 3.6 elements to a model only when that option is enabled, and must label every model finding as a suggestion.	In the default configuration no request leaves the Google tenant. With the option enabled, every model finding in the report is labeled as a suggestion and none is reported as a failure. With the option enabled, the text sent to the model does not include the instructor name or email taken from the form. Changing the model provider requires a change to one function only.	To verify
R11	Reading the syllabus, and its limit	The Syllabus Checker must extract the syllabus text from a Google Doc or a Word file.	A Google Doc submission is read and checked. A Word submission is converted, read and checked. After a Word submission, no converted temporary copy remains in Drive.	Built
R12	Reading the syllabus, and its limit	The Syllabus Checker must tell the instructor when a submission is a PDF that extraction may be unreliable and that they may resubmit as a document.	Every report on a PDF submission carries the extraction notice and the resubmit instruction. A file that cannot be read is reported as unreadable, with no pass or fail results guessed. No submission ends without a report or a status entry.	To verify
R13	The reports	The Syllabus Checker must email the instructor who submitted an itemized report marked complete or incomplete.	The email arrives within seconds of the submission. The email names each finding separately. Each missing approved statement is followed by the approved wording, ready to paste. The email goes to the submitter only and no copy goes to the department administrator.	Built
R14	The reports	The Syllabus Checker must write four columns to the existing response sheet for each submission: check status, missing items, file type and date checked.	After a submission, its row holds a value in each of the four columns. The status cell is filled with a solid color that matches its state. The sheet can be sorted by the status column.	Built
R15	Privacy	The Syllabus Checker must never modify a submitted syllabus.	After a run, the content and last-modified time of the submitted file are unchanged. The only outputs of a run are the four sheet columns and the email to the submitter. The script writes to no database, log store or analytics service.	Built
R16	Build and portability	The Syllabus Checker must match form fields by field ID rather than by question title.	Rewording a question on the form does not change what the script reads from that field. No question title text is used as a lookup key in the script.	Designed, not built

5. Data, privacy, and governance

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 separate database and no analytics. The only records are the status columns in the response sheet the department already owns and the 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 has 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.

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

Dependencies

What has to be in place, and who provides it.

Needed	Provided by	Needed for
Authorization of the script by the account that owns the form	The department account owner	R1 and every run of the tool
The existing Google Form and its response sheet	The department	R1, R14
The approved-language Google Doc, kept current	The department	R2, R4, R5
Docs, Drive, Sheets and Gmail on the college Workspace account, with accounts, permissions and audit logging	OIT	R1, R11, R13, R14
A model endpoint: Claude, Gemini or a district-hosted endpoint	The district, by its choice of provider	R10
Review of the AI configuration and a written data boundary	OIT and the ARC	Offer to a second department or another college
A policy that syllabi are submitted as Google Docs or Word files	The department	R12 and the zero false failure bar
A human reviewer who continues the manual review and reports time spent	The department	Shadow-mode term and the success bar

7. Pilot and testing

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.

Disagreement on the AI-assisted fuzzy elements is expected, which is exactly why they are labeled suggestions and never failures.

The tool is now in use.

8. Definition of success

The bar 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.
• Every unreadable file reported as unreadable rather than guessed.

9. Rollout

The tool is in use, bound to the department’s existing Google Form on the college Workspace account. Nothing runs until the account that owns the form authorizes the script.

The planned sequence is that faculty email turns on only after the shadow-mode term meets the bar, with the manual review kept as a backstop for one more term.

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.

Out of scope

• The Syllabus Checker never revises or rewrites a submitted syllabus; it only reports.
• The Syllabus Checker does not send the administrator a copy of each individual report.
• The Syllabus Checker does not use a model to decide whether approved wording appears verbatim.
• The Syllabus Checker does not treat a model finding as a failure; model findings are suggestions only.
• The Syllabus Checker does not store a copy of the approved language.
• The Syllabus Checker does not read, create or store any student record.
• The Syllabus Checker does not yet follow Syllabus+ PDF URLs, although the form accepts them.
• There is no multi-tenant version and none is planned; each department runs its own script.

10. Open questions and risks

• PDF extraction. The false failures described in section 4 remain until the department accepts only Google Docs and Word.
• Form field matching. Form fields are matched by exact title, so a reworded question currently makes the script read nothing.
• Modality. RSI applicability is inferred, because the form has no modality question.
• 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.

Questions to settle before the next build

1. Now that the tool is in use, are faculty emails on, was the shadow-mode term run and the bar met, and are the fuzzy Reg 3.6 checks enabled and with which model?
2. What is the full list of Reg 3.6 elements, which are literal with which keywords and which are fuzzy, and can a model suggestion ever change a report from complete to incomplete?
3. How is modality determined today, and how does the script pick the right seat-hours statement from the approved-language document for a given course?
4. For the deadline check, what is compared against the computed Friday and what does the report say when a submission is late; and what are the allowed status values and their colors?
5. Is the weekly digest built, who receives it and what runs it; and should instructor names and emails that appear inside the syllabus text be removed before a model call?

11. Roadmap

The known fragilities to fix before it travels:

• Match form fields by ID rather than exact title.
• Add a modality question so RSI applicability is asked rather than inferred.

Also planned, with no order set:

• A fetch-and-parse step so Syllabus+ PDF URLs are followed.
• An offer to a second department or another college, as configuration, after OIT and the ARC review the AI configuration and put the data boundary in writing.