Skip to main content

The Glass Box Syllabus

An image from the static

A course framework​

This document proposes a prototype syllabus for undergraduate students in a liberal arts context, developed from the experimental protocols on Discourse Depot.

The Core Pedagogical Move: Students engineer AI systems by translating theoretical research into executable analytical instructions. While this borrows the mechanics of "prompt engineering," it rejects the focus on efficiency that the term implies. Instead, it positions system instructions as types of interpretive Instruments and a site where an entire socio-technical apparatus meets generative inquiry.

A few guiding questions are: Can system instructions function as scholarly artifacts? Can data schemas serve as theoretical arguments? Can iteration logs be read as evidence of critical thinking?

Generative AI animates the central questions of a liberal arts education because it destabilizes all the interesting definitions of what it means to be human, to know, to explain, and to communicate. This course idea is framed as an interdisciplinary intervention by drawing on philosophy of mind, critical theory, media studies, information studies, and data science to attend equally to the "Artificial" (the mechanism) and the "Intelligence" (the projection).

Course Title: Minds, Machines and Making
Format: One semester (15 weeks) for Module 1; Module 2 is an optional extension
Audience: Undergraduate students; no programming prerequisites
Primary Deliverable: A working analytical instrument (prompt + documentation) that operationalizes a critical framework

Big Ideas and Core Questions​

1. Background: What are minds, and what are machines?

Students engage foundational texts in philosophy of mind, consciousness studies, and information theory to understand competing theories of cognition. We examine Integrated Information Theory (Tononi), computational theories of mind, embodied cognition frameworks, and critiques of the "Chinese Room" (Searle) argument. This establishes the conceptual tools needed to evaluate claims about AI "understanding" or "reasoning." This would most likely have to entail a deep dive into notions and distinctions between AI transparency vs. interpretability. Helpful would be some review of the philosophical concept of epistemic opacity (Humphreys) and things like the physics of non-determinism as well as readings on post-hoc interpretability, mechanistic interpretability, and the theories of knowledge around deep learning.

2. How does language shape (and obscure) our understanding of AI systems?

Students analyze the pervasive anthropomorphic metaphors in AI discourse like systems that "think," "learn," "understand," "hallucinate," or "are creative." Drawing on cognitive linguistics and critical discourse analysis, students learn to distinguish between system behavior (observable outputs given inputs) and projected cognition (attributions of mental states). This metacognitive awareness is foundational AI literacy.

3. Can formalizing theory as executable systems deepen understanding?

The course's central pedagogical claim is that translating critical frameworks into AI prompts and data schemas forces some type of iterative precision in theoretical understanding. Students discover (like I am doing) that operationalizing concepts like "discourse," "framing," "ideology," or "positionality" requires confronting gaps in their own comprehension. The prompt becomes scholarship: a citable, testable, improvable artifact that demonstrates theoretical understanding.

Pedagogical Framework: Four Pillars​

Artificial + Intelligence - Transdisciplinary Riffs​

  • The Philosophy of Mind (The "Alien Intelligence" Track)
  • Discourse & Critical Theory (The "Power & Language" Track)
  • Media Studies & Propaganda (The "Simulation" Track)

Before the phase-by-phase breakdown, here's the theoretical backbone of this approach.

1. Formalization as Learning

Students translate theoretical frameworks from abstract concepts into precise, step-by-step logic that an AI system can execute. Academic theories are often expressed in complex, nuanced, sometimes ambiguous language. They provide lenses for interpretation, but do they provide definitive analytical methods? What does this even mean?

Deconstructing a theoretical framework into its smallest analytical units ("operational primitives") creates a mirror where learners articulate exactly what the theory instructs them to look for and how to classify it. For example: What does this theory mean by "hegemonic discourse" in terms of textual features? Does this theory actually provide a coherent, executable method of analysis, or does it only offer a lens?

2. Schema as Argument

A schema tells the model: "When you analyze this text, return results in exactly this format." By deciding which fields to include, the student is arguing: "To understand this text through Theory X, one must account for categories A, B, and C."

Approached in this way, the schema itself is a theoretical statement. It is an argument about what matters. The choice, for example, to include instances_of_neocolonial_rhetoric but not mentions_of_domestic_policy is an analytical and political choice that asserts a hierarchy of significance. Students reflect on the politics of their own data structure: What does my schema try to get this LLM to "notice," and what does it allow it to "ignore"?

3. Iteration as Metacognition

The constant need to debug both prompt and schema externalizes thinking. The trial-and-error process becomes visible, measurable metacognition. The archived sequence of failed prompts, revised schemas, and successful outputs creates an "archive of doubt."

A prompt journal from a student might read: I made this change because the output from V1 was too vague, identifying 'power' in a metaphorical way without grounding it in specific textual evidence. This opens discussion of larger issues: LLMs, authorship, opacity. Students would be required to log prompts that failed to produce the desired analysis then attempt to explain why the instrument failed: Was the theory too nuance-heavy? Was the model too 'sycophantic'? Was the schema too rigid? I’ve learned more from system instructions that broke than the ones that worked.

4. Provenance as Scholarship

Provenance is the detailed, auditable history of analytical work. In this syllabus, it establishes standards for transparency. This level of provenance focuses scholarly assessment on more than a final argument, but on the integrity of the method itself. The learner is accountable for the entire "system" they built, even the messy middle parts.

The process generates a complete, transparent chain of intellectual custody:

Source → System Instructions → Schema → Iterations → Output

Assessment hits the librarian-ish highlights: systems thinking, architectural design, and critical awareness of tools, processes, and techniques used to produce knowledge.

The Scaffolded Question: "Can AI Help Here?"​

I want to avoid the "here are AI tools, now use them" approach and instead begin with the types of challenges that emerge naturally from intellectual work and a question students learn to ask with increasing sophistication: Given what I understand about how these systems actually work, could these AI tools help here?

Or to avoid any anthropomorphic framing of a “partner,” Does this task yield to this instrument? or Is this problem solvable by probabilistic completion?

That "given what I understand" is where the learning lives. Students build conceptual vocabulary along the way (structured output, schema design, probabilistic generation) developing judgment about when and how to deploy these tools. Looking at and through their interfaces.

Also, and more interesting to me, the advent of code-generating AI (vibe coding) shifts what "technical barrier" means. The question is no longer Is there an app for this? or even Can I code this? It's: Can I describe what I'm trying to do with enough precision to make the code? Conceptual clarity becomes the bottleneck and that's exactly the kind of thinking humanistic training develops.

Here are the kinds of example challenges I envision that scaffold this type of learning:

Challenge 1: Pattern Recognition at Scale

I've close-read 5 texts and I'm noticing recurring metaphors. But I have 45 more. How do I trace this systematically without losing analytical depth?

Opens the door to: structured output, schema design, corpus analysis

The informed question: Can I design an instrument that applies my analytical categories consistently across texts?

Challenge 2: Coding Drift

I'm applying this framework to multiple texts, but my own categories keep shifting. What counted as 'agentless passive' in text 3 doesn't match what I flagged in text 7.

Opens the door to: operational primitives, schema enforcement, explicit definitions

The informed question: Can I formalize my categories precisely enough that a system applies them consistently—and what does that formalization reveal about my own understanding?

Challenge 3: Making Qualitative Work Comparable

I have rich notes on each text, but they're all prose. I can't compare across them because nothing is structured the same way.

Opens the door to: JSON structure, database normalization, queryable data

The informed question: What would it mean to model my observations as data? What do I gain and lose?

Challenge 4: From Consumer to Builder

A colleague wants to apply my framework to a different corpus. And I want to build a simple interface for it. The question used to be 'is there an app for this?' Now it's: 'Do I understand what I'm trying to do well enough to describe it in language that makes the app?'

Opens the door to: prompt as artifact, provenance, natural language as specification, shareable tools

The informed question: Is my understanding precise enough to become a working system?

Challenge 5: The "What Am I Looking For?" Problem

I understand this theory conceptually, but when I sit down with a text, I'm not sure what textual features actually count as evidence.

Opens the door to: formalization as learning, operational primitives, evidentiary mapping

The informed question: Can the act of instructing a system force me to articulate what I tacitly know?

Since I’ve been going through these scenarios myself, they are no longer hypothetical. I’ve flagged them as the actual friction points of the work. The course would be designed in a way that uses them as on-ramps to technical concepts, always in service of humanistic inquiry. Moving beyond AI skills, the learning goals would be focused on developing informed judgment about a class of tools by understanding their mechanics and capabilities.

Why This Course?​

The Readiness Trap​

Many educational institutions like my own find themselves caught in a "readiness trap,” a cycle of forever-preparation that defers meaningful student engagement with AI until educators achieve some mythical state of mastery (or not). While we wait for the next professional development cycle or policy framework, our students are already accumulating countless AI experiences in spaces designed for more for entertainment and efficiency, not necessarily for deep, critical learning. They are interacting with "The Partner" (the marketing illusion) rather than "The Processor" (the technical reality).

This syllabus starts from a different premise: Reframe AI literacy from a static competency to be mastered into an ongoing interpretive practice to be cultivated.

From Black Box to Glass Box: Is it Magic or Floating-Point Chaos?​

One goal is to teach students to go beyond using generative AI just to perform a single task. In the course, there would be pervasive permission to explore the utility of these models in the process of doing complex academic work as a type of reflective experimentation.

Also, this is an overt exercise in demystification. By engaging with these systems through system instructions and schemas, the magic of the conversational interfaces is stripped away.

The Glass Box Distinction: The course actively and iteratively distinguishes the Black Box from the Glass Box.

  • The Black Box suggests the system is magic, secret, or unknowable.
  • The Glass Box acknowledges that the mechanism is visible: we can see the code, the weights, and the probabilities.

So what is the mystery? It is an opacity of scale. We have transparency (we can see the math) but we lack interpretability (we can't easily explain why the math converged on that specific word). Metaphor alert: It is like staring at a library with glass walls: we can see every book on every shelf, but they are organized by a 4,000-dimensional decimal system that no human mind can parse.

Even when we set the model to be as precise as possible (Temperature 0), we may see variations. This isn't the machine "changing its mind." It is the result of some non-deterministic hardware physics, for example, microscopic variations in calculation speed across massive GPU clusters.

This is what the Glass Box reveals: there is no mind inside, just a system. And systems can be understood even if they cannot always be read.

The pedagogical work here is not to "solve" the fascinating “mystery” of high-dimensional logic, but to acknowledge, even respect it. I can define the system as mechanistically transparent (we can see the gears/math) but semantically opaque (we cannot always trace the meaning). However, students, like me, can still learn to navigate a system that is fully visible yet remains alien to them.

Ultimately, the glass box is more than just all this noise; it's the entire socio-technical apparatus it is embedded in.

Beyond the "Neutral Tool"​

Calling generative AI systems "tools" is reporting a kind of fact, but one that is either meaningless or uninteresting, or both. A tool's meaning "worlded," it is embedded in a world of other purposes, relations, and practices. It only makes sense within that lived system. Saying something is "just a tool" tells us nothing about how it is made, used, encountered, understood or who made it.

In the hands of a student, I’ve learned that a tool is never neutral. It has constraints, affordances, assumptions. It pushes back. That tension is the pedagogical opportunity to explore:

  • The Reality: An LLM is a non-neutral instrument. It presses back. It has "sycophancy features" that want to agree with you. It has "refusal circuits" that block certain paths. It is marketed in ways that scaffold expectations about it.
  • The Pedagogy: The tension between the student's intent and the machine's optimization is a site of learning. This invites students to notice not just what they made, but how the machine shaped the making. Did the machine "impute" a generic idea because it was statistically safe? Did it "clamp" a controversial topic?

These class of “tools” are more than just things I use, they are things that shape how I make sense of the world. I can invite students to notice that too. What they've made and how they got there. What kind of thinking it required. What kind of thinking it made possible.

Pedagogical Principles Over Platform Mastery​

Instead of waiting for impossible-to-achieve platform mastery, this syllabus is organized around a core pedagogical principle: using the design of system instructions as a site and platform for all sorts of directions of scholarly inquiry.

This approach allows me as an instructor to position myself as a co-investigator. The focus shifts from knowing, for example, the exhaustive details of transformer architecture to guiding students through a fundamentally human process: asking good questions, applying analytical frameworks, and critically evaluating evidence.

Part I: The Course - Super Draft Mode​

Module 1: The Humanities Loop​

Research → Blueprint → System Instructions → Deployment

This is the complete, semester-long experience. Students move through a series of disciplinary readings and from selecting a critical framework to deploying a working analytical instrument. No programming required though students will encounter technical concepts (JSON structure, API playgrounds) as tools in service of humanistic inquiry.

Phases​

Phase 1: Framework Selection & Deep Research

Goal: Students identify a critical framework and build genuine scholarly understanding.

Learning Objectives:

  • Identify primary theoretical texts within chosen framework
  • Articulate the framework's core concepts, tensions, and debates
  • Distinguish between the theory's claims and its operational logic

Deliverables:

Framework Selection Memo

  • Which framework? Why this one?
  • What makes it suitable for operationalization?
  • What are its known limitations/blind spots?

Annotated Bibliography

  • Primary theoretical texts
  • Applied examples (how others use this framework)
  • Key concepts with preliminary definitions

Assessment Checkpoint: Does the student demonstrate reading comprehension AND critical awareness of the framework's scope?

Phase 2: Deconstruction into Operational Primitives

Goal: Translate abstract theory into discrete, executable analytical actions.

Learning Objectives:

  • Convert noun-based concepts into verb-driven tasks
  • Map each action to specific textual evidence types
  • Identify what the framework "sees" vs. what it ignores

Deliverables:

Operational Blueprint (structured document)

  • List of core concepts from the framework
  • For each concept:
    • Action verbs: What does one DO to apply this concept?
    • Evidentiary mapping: What textual features verify this?
    • Edge cases: When does this concept NOT apply?

Self-Assessment Reflection

  • Which concepts were hardest to operationalize? Why?
  • What did the operationalization process reveal about gaps in your understanding?

Assessment Checkpoint: Are the primitives specific enough to be machine-executable? Do they capture the framework's nuance or flatten it?

Phase 3: Writing System Instructions as Scholarship

Goal: Design system instructions that embody the theoretical framework.

Learning Objectives:

  • Construct effective persona/role assignments for LLM
  • Write negative constraints that prevent generic outputs
  • Design chain-of-reasoning requirements for transparency
  • Iterate based on diagnostic output analysis

Deliverables:

System Instruction Document (v1)

  • Persona assignment
  • Contextual grounding
  • Operational primitives (from Phase 2) as explicit instructions
  • Negative constraints
  • Required output structure (even if not JSON yet)

Test Run Documentation

  • Sample text analyzed
  • Full output from LLM
  • Diagnostic notes: What worked? What failed? Why?

Prompt Journal (iterative, ongoing)

  • Version log with rationale for each change
  • Example: "V2: Changed 'identify power' to 'quote specific language that legitimizes institutional authority' because V1 outputs were too vague"

Assessment Checkpoint: Does the prompt demonstrate theoretical synthesis? Are constraints precise? Is there evidence of diagnostic iteration?

Phase 4: Deployment & Documentation

Goal: Package the prompt as a reusable tool and document its intellectual/theoretical commitments.

Learning Objectives:

  • Deploy prompt in API playground OR no-code tool (Custom GPT, Claude Project, Google AI Studio, etc.)
  • Articulate what the system highlights and what it obscures
  • Test on multiple texts to verify consistency

Deliverables:

Final System Instruction (with deployment evidence)

  • Link to custom instrument, OR
  • Screenshot of API playground configuration

Critical Reflection Essay

  • What does your prompt force an analyst to notice?
  • What does it allow them to ignore?
  • How does this reflect the framework's inherent politics?
  • What surprised you about the outputs?

Final Assessment: Rubric TBD (4 criteria: Theoretical Synthesis, Operational Clarity, Reflective Iteration, Critical Awareness)

What Students Walk Away With (Module 1)​

By the end of the semester, students have:

  1. A working analytical instrument — a prompt that operationalizes a critical framework they researched deeply
  2. A documented design process — the prompt journal that traces their thinking
  3. A critical vocabulary — for talking about AI systems without anthropomorphism
  4. A transferable method — the Research → Blueprint → Prompt → Deploy loop applies to any framework

They have also practiced: close reading, theoretical synthesis, technical writing, iterative design, and metacognitive reflection.

Part II: The Pathway​

Module 2: Digital Scholarship Extension​

Schema → Database → Scalable Analysis

This is where the course could lead. Module 2 is aspirational scaffolding for students who want to continue—whether through independent study, a follow-on course, or self-directed learning. It builds on Module 1 by introducing structured data, API integration, and corpus-level analysis.

Who is this for?

  • Students pursuing Digital Humanities minors or certificates
  • Graduate students building research pipelines
  • Self-directed learners comfortable with technical documentation
  • Anyone who completed Module 1 and wants to go further

What additional skills does it require?

  • Comfort with JSON syntax (introduced in workshop)
  • Willingness to engage with API documentation
  • Basic data literacy (what is a database? what is a query?)

These skills are introduced through embedded workshops, but students should expect a steeper learning curve than Module 1.

Phase 5: Schema Design as Ontological Argument

Goal: Transform qualitative primitives into a structured data model.

Learning Objectives:

  • Distinguish between entities and attributes
  • Use data types (string, array, object, boolean) to enforce rigor
  • Design nested structures that represent analytical relationships
  • Recognize schema as theoretical commitment

Deliverables:

Schema Design Document (JSON format)

  • Complete schema matching operational primitives
  • Required vs. optional fields (with justification)
  • Data type choices (with rationale)
  • Example: "Why is projection a string and not an array?"

Schema Critique Memo

  • What does this schema assume about the nature of the phenomenon?
  • What alternative schema designs were rejected? Why?
  • What would a different framework's schema look like?

Skills Workshop: JSON syntax basics, schema validation tools, mapping theory to data structures

Assessment Checkpoint: Is the schema complete? Does it enforce relationships? Can the student defend structural choices theoretically?

Phase 6: API Integration & Structured Output

Goal: Connect system instructions + schema to API, handle responses.

Learning Objectives:

  • Configure API calls with system instructions and schema
  • Parse structured responses (JSON extraction, error handling)
  • Interpret "processing tokens" as diagnostic feedback
  • Iterate on both prompt AND schema based on malformed outputs

Deliverables:

Working API Configuration

  • Code/screenshots showing successful structured output
  • Evidence of schema validation (API accepts it)

Iteration Log

  • Document 3+ cycles of schema refinement
  • What broke? How did you fix it?
  • Example: "Schema initially made implications optional. API returned outputs without this field. Changed to required, outputs improved."

Skills Workshop: API authentication basics, reading API documentation, debugging malformed JSON responses

Assessment Checkpoint: Does the system reliably produce schema-conformant outputs? Is there evidence of prompt-schema co-evolution?

Phase 7: Multi-Text Pipeline & Comparative Analysis

Goal: Scale analysis across a corpus, enable cross-text queries.

Learning Objectives:

  • Design database schema for storing multiple analyses
  • Understand relational vs. document databases (conceptually)
  • Perform aggregate queries (frequency, patterns, outliers)
  • Visualize findings (optional: charts, tables)

Deliverables:

Database Design Document

  • Tables/collections structure
  • Relationships between entities
  • Sample queries with expected results

Corpus Analysis

  • Batch process multiple documents
  • Store results in database
  • Run comparative queries

Findings Report

  • What patterns emerged across texts?
  • What did structured data enable that manual analysis wouldn't?
  • What did the structure miss or obscure?

Skills Workshop: Database normalization basics, SQL/NoSQL query fundamentals, data visualization principles

Assessment Checkpoint: Does the pipeline work at scale? Are queries theoretically meaningful? Does the student recognize what quantification affords/forecloses?

Phase 8: Capstone Project (Optional Extension)

Goal: Build a shareable web application OR publish research findings.

Option A: Web Application

  • Frontend UI for inputting text
  • Backend API integration
  • Results display with export functionality
  • Deployment (Vercel, Netlify, etc.)

Option B: Research Publication

  • Use pipeline to analyze significant corpus
  • Write findings as conference paper / blog post
  • Share schema + prompts as reproducible methods

Deliverable: Either deployed app OR published research with full methodological transparency

Final Assessment: Expanded rubric (adds: Data Modeling, Technical Execution, Scalability, Methodological Transparency)

What This Course Is Not​

A few clarifications to preempt misreadings:

  • This is not a course in "prompt engineering for productivity." The goal is not to make students more efficient users of AI. The goal is to make them more critical thinkers about AI and about the frameworks they use to interpret the world.

  • This is not a course that assumes AI is good or bad. It assumes AI is a socio-technical phenomenon worth understanding on its own terms, without either utopian hype or dystopian panic.

  • This is not a programming course. Programming skills are introduced as needed (JSON, API calls, database queries, coding), but always in service of humanistic inquiry. Students who want to go deeper into code can; students who don't can still complete Module 1 with no-code tools.

  • This is not about teaching students to trust or distrust AI outputs. It's about teaching them to read those outputs critically as rhetorical artifacts produced by probabilistic systems shaped by training data, prompt design, and hidden instructions.

Closing Note​

This syllabus idea moves beyond the binary of prohibition versus uncritical adoption. Instead of framing AI as a "partner" to be trusted or a "plagiarism machine" to be feared, I prefer to frame it as a probabilistic instrument that requires specific calibration.

The core pedagogical move here is shifting the sites of evaluation. Less focused on evaluating the output (which the machine generates) and attending to the input architecture (which the student designs).

In a course like this, the prompt and the schema are the primary artifacts of assessment. By forcing students to translate critical theory into executable code, the idea is to make their entire analytical apparatus visible. So I’m not assessing whether they got a "good answer." I’m more interested in assessing the integrity of their designed system: the coherence of its logic, the rigor of its structure, and the sophistication of its constraints. Any assessment framework would follow from a course design that created and choreographed all the necessary conditions for noticing a hermeneutics of screwing around.

And again, this is what the Glass Box reveals: there is no mind inside, just a system. And systems can be understood even if they cannot always be read.

Troy W&M Libraries

This “syllabus” idea is a work in progress. Feedback welcome.

Discourse Depot © 2026 by TD is licensed under CC BY-NC-SA 4.0