Plain language summary

Teachers increasingly encounter AI tools that can write fluent text but cannot clearly show where their answers come from, and institutions often cannot send course materials to external cloud services. RUCAI is a locally deployable teaching copilot that helps teachers work with their own course descriptions and readings. Teachers upload course documents, ask questions for planning or teaching support, and receive answers that point back to the specific course texts used as evidence. RUCAI also lets teachers publish restricted student-only chat workspaces so students can ask questions only within the course materials and instructions the teacher has chosen. RUCAI is designed for teaching contexts where the primary scholarly activity is the interpretation of assigned texts – a pattern characteristic of humanities disciplines and text-centered social sciences.

Context

RUCAI was developed to address a recurrent problem in course preparation and delivery related to how teachers need to think across multiple assigned texts while maintaining interpretive accountability. Existing AI interfaces often produce fluent but weakly grounded responses and provide little control over what textual evidence is being used. In humanities teaching, this is not a minor issue. The pedagogical value of AI assistance depends on whether claims can be traced back to course literature and whether uncertainty is represented clearly (Qi et al. Reference Qi, Sarti, Fernández and Bisazza2024; Wallat et al. Reference Wallat, Heuss, Rijke and Anand2024). Recent empirical evidence from humanities education confirms that while generative AI can support initial familiarization with course material, it lacks the depth required for advanced study unless combined with authoritative, source-grounded resources (Crompton and Burke Reference Crompton and Burke2023; Wessels Reference Wessels2025).

Two context drivers shaped RUCAI’s design. First, course planning is iterative and distributed across artifacts. Teachers move between course descriptions, institutional learning objectives, assigned readings, and exercise design. RUCAI, therefore, treats a course as a first-class object, with an explicit course title, course description, and course-specific prompt instructions. This design supports continuity across sessions and avoids the stateless restart pattern common in ad hoc chatbot use. Second, institutional and legal constraints shape what software universities can deploy. European universities operate under the General Data Protection Regulation (GDPR), which restricts processing of student and course data on servers outside institutional control. Data sovereignty concerns are heightened by the dominance of US-based cloud providers – whose three largest firms control about 70% of the EU cloud infrastructure market – and by access provisions under US legislation such as the CLOUD Act (European Parliament 2025). These constraints mean that routing course materials through proprietary AI services (e.g., ChatGPT, Copilot) may not be permissible without institutional risk assessment. In many educational settings, the default assumption cannot be unrestricted cloud processing of course materials. RUCAI is designed to run locally on controlled VM infrastructure with local inference via Ollama, relational storage in PostgreSQL, and vector search via pgvector. This local-first orientation supports data governance requirements while retaining operational flexibility (Huang and Lee Reference Huang and Lee2025; Karakurt and Akbulut Reference Karakurt and Akbulut2026; Koeser et al. Reference Koeser, Damerow, Casties and Crawford2025).

The methodological orientation supports the expectation that AI-assisted responses should be traceable to specific course texts and should express uncertainty when evidence is limited. RUCAI enforces source-grounded prompts, requests explicit citation markers, and returns source metadata to users. When context is insufficient, the intended behavior is not extrapolative confidence but explicit uncertainty (Pollin et al. Reference Pollin, Fischer, Sahle, Scholger and Vogeler2025).

These terms – close reading, hermeneutic interpretation, interpretive accountability – are invoked in this paper with a specific and limited software-level meaning. RUCAI does not simulate hermeneutic interpretation, nor does it perform close reading in the humanistic sense, leaving this to student–teacher interactions. Rather, it operationalizes three features that make humanistic interpretive practices tractable when working with AI assistance:

1. 1. Source traceability: Responses include explicit references to the specific course texts used as retrieval evidence, grouped by source identity (not by chunk). This supports the humanistic expectation that claims are attributable to primary texts rather than to an opaque model.

2. 2. Uncertainty marking: When retrieved evidence is insufficient, the system is instructed – through a locked prompt rule – to express this explicitly rather than extrapolate. This is a software-level proxy for the close-reading norm of not overstating what a text says.

3. 3. Evidence scope control: Retrieval is limited to the teacher’s indexed course materials. The system does not retrieve external web content, and its prompts instruct the model to base answers on the uploaded corpus. This corresponds to the practice of constraining interpretation to assigned texts within a course context. The scope is intentionally conservative, but not static: throughout a course, the teacher can update the system prompt to reflect course developments, class conversations, comments, objections, and emerging interpretations. RUCAI therefore treats the uploaded corpus as the evidence boundary for generated answers, while allowing the teacher to adjust the instructional framing around that corpus as the course develops. This is not presented as the full boundary of human interpretation.

These three features do not constitute a humanistic method; they are minimal software conditions for AI assistance that do not actively undermine it. The paper’s claim is that most current AI tools for teaching often fail to meet even these conditions, and that RUCAI is designed to meet them.

One typical workflow is: (1) set up a course module in RUCAI with formal requirements; (2) upload a syllabus and readings; (3) use the chat feature to ask synthesis questions (e.g., how two texts disagree on a concept), generate ideas and reflections on overall curriculum structure, and develop class exercises; (4) curate student-only context based on insights from previous steps using a dedicated prompt feature, as well as digital curriculum texts; (5) create any number of student instances for use during the course. RUCAI can enter this process at two points. During course assembly, it can help teachers test relationships among candidate readings, learning objectives, and exercises before a course is finalized. During course delivery, it can expose a selected and frozen corpus to students. This makes the workflow relevant both to large or repeated courses and to upper-level or research-led courses where the reading list and interpretive framing are still being built.

Related software

RUCAI is not the first system to combine LLMs, retrieval, and user-facing interfaces. Its contribution is best understood by comparing workflow assumptions and operational constraints (Brown et al. Reference Brown, Roman and Devereux2025; Huang and Lee Reference Huang and Lee2025).

This paper focuses on six categories commonly encountered in practice: proprietary chatbots (e.g., ChatGPT, Copilot, Claude); general-purpose local LLM workspaces (e.g., AnythingLLM); RAG frameworks for custom pipeline assembly (e.g., LlamaIndex, Haystack); institutional LMS environments (e.g., Moodle, Canvas, Brightspace) with limited AI extension points; purpose-built educational RAG platforms (e.g., AI-University; Shojaei et al. Reference Shojaei, Gulati, Jasperson, Wang, Cimolato, Cao, Neiswanger and Garikipati2025); and project-specific DH tools with domain-specific workflows. The goal is not to rank these systems, but to show where RUCAI’s design choices differ.

Proprietary chatbots are widely adopted in university settings and offer strong general-purpose language capabilities. However, they typically involve recurring per-seat or API-usage costs that scale with institutional adoption, and their data-handling practices – including whether uploaded documents are used for model training, how long user interactions are retained, and where data is processed geographically – are governed by vendor terms that may change without institutional consent. For European universities operating under GDPR, these uncertainties create compliance risks that local-first alternatives are designed to avoid.

Key distinctions

Table 1 compares RUCAI against proprietary chatbots (the category most commonly encountered by teachers), AnythingLLM (the most direct open-source comparator in the local RAG workspace category), and generic LMS-based AI extension points. RUCAI’s distinguishing design choices are concentrated in three areas that these systems do not provide by default.

Table 1.

Feature comparison: RUCAI and selected local RAG systems

Table 1. Long description

The table compares four system categories across eight features. RUCAI supports all eight: local-first deployment, workspace-level document scoping, a course as a first-class object, a custom system prompt per workspace, publication of frozen student instances, persistent course-scoped chat history, an MIT open-source license, and institutional data sovereignty. AnythingLLM supports local-first deployment, workspace document scoping, custom prompts, persistent history, open source, and data sovereignty, but not a course object or student-instance publication. Proprietary chatbots do not support local-first deployment, a course object, student-instance publication, open source, or on-premise data sovereignty; they offer limited session-scoped file upload, partial custom prompting through custom GPTs, and persistent history that is not course-scoped. Generic learning-management systems vary by vendor for local deployment, document scoping, chat history, open source, and data sovereignty; they do not provide a course as a first-class software object, have limited custom prompting, and may partially support publication through assignments.

Note: “7” indicates not supported in the system’s standard configuration as of the time of writing. “Partial” and “Limited” indicate the feature exists in a constrained form. “Vendor-dependent” indicates the capability depends on the specific product or institutional agreement.

First, RUCAI treats the course as the primary software entity, with explicit activation state, course description, and course-specific prompt instructions that persist across sessions. AnythingLLM’s workspace is a flat document container; it carries no course-level semantics (Mintplex-Labs 2024. Second, RUCAI enforces citation normalization at the retrieval layer: responses group retrieved chunks under canonical source identities, reporting the unique source count separately from the chunk count. This design decision is motivated by research on faithfulness in RAG systems (Qi et al. Reference Qi, Sarti, Fernández and Bisazza2024; Wallat et al. Reference Wallat, Heuss, Rijke and Anand2024). The idea is to position the text and the curriculum up front and to encourage students to engage directly with the curriculum texts. Third, RUCAI provides a publish-to-student mechanism that freezes course context and prompt constraints into a bounded runtime snapshot. This is architecturally distinct from exposing the teacher’s live workspace to student access, and it supports the repeatability and governance requirements of classroom deployment. Among purpose-built educational platforms, AI-University (Shojaei et al. Reference Shojaei, Gulati, Jasperson, Wang, Cimolato, Cao, Neiswanger and Garikipati2025) is the closest comparator: it aligns LLM output with instructor-defined learning objectives in STEM classrooms. RUCAI differs in emphasis by prioritizing source traceability over instructional alignment, targeting humanities corpora rather than scientific curricula, and enforcing local-first deployment rather than cloud-hosted operation.

Software architecture

RUCAI is organized into five functional layers. Figure 1 illustrates the system architecture while Table 2 summarizes layer responsibilities.

Figure 1.

RUCAI system architecture. Documents are ingested into pgvector-backed chunks; at query time, an intent classifier selects the retrieval scope, and citation normalization groups chunks by source before LLM generation. A student-instance mechanism packages a frozen corpus and a prompt snapshot into a bounded context. All prompts and UI strings are in Danish or English.

Figure 1. Long description

The architecture diagram is divided into five connected areas. The Teacher Interface moves from Create or Activate Course, to Upload PDF or DOCX and Set Scan Mode, to Ask Planning Question, and then Publish Student Instance. Uploaded documents enter the Ingestion Pipeline. Digital files use pypdf for PDFs or python-docx for DOCX; hand-scanned files use docling OCR, with MinerU as a fallback when extraction yields no text. Both routes pass through a Danish/English language heuristic, word-based chunking of 800 words with 100-word overlap, and bge-m3 embedding through Ollama. Metadata is stored in PostgreSQL and embeddings in pgvector. A planning query enters Retrieval and Generation, where a keyword-phrase classifier labels it as narrow, synthesis, or compare. Vector search may run a second retrieval round for synthesis or comparison queries when too few unique documents are found. Results then pass through citation normalization, layered prompt assembly, and gemma3:12b generation before a grouped response is returned with intent, source, and chunk counts. Publishing creates a Student Interface with an instance-scoped chat and a frozen corpus and prompt snapshot. Student queries remain corpus-scoped while sharing the same retrieval and generation services.

Table 2.

RUCAI architecture layers and responsibilities

Table 2. Long description

The table describes five RUCAI architecture layers. The Application layer uses FastAPI routes and an HTML/JavaScript interface for course operations, chat, search, and student-instance management. The Data layer uses PostgreSQL for metadata and pgvector for embeddings and cosine-similarity retrieval, providing persistent storage and approximate nearest-neighbor search. The Inference layer uses configurable Ollama models, by default bge-m3 for embeddings and gemma3:12b for chat, so embedding and generation run locally without external API calls. The Ingestion layer combines pypdf, docling OCR, MinerU fallback, python-docx, Danish/English language detection, and overlapping word-based chunks to normalize heterogeneous course files into retrievable content. The Chat and Retrieval layer combines narrow, synthesis, and compare intent classification, multi-round retrieval, query expansion, citation normalization, and layered Danish prompt governance to generate source-grounded answers with transparent citation metadata.

Development methodology

RUCAI was developed through an iterative, practice-led qualitative design process. The initial prototype was built by the author and presented at a digital methods workshop with colleagues from the humanities and social sciences. Their feedback shaped subsequent backend, frontend, and UX development, especially the need for a chat interface organized around course materials rather than generic prompting, and for answers that could be traced back to uploaded course texts. These requirements directly informed the RAG-centered architecture, the course-as-primary-object model, and the emphasis on source-grounded responses. Development followed a formative cycle: build a prototype, gather feedback from humanities and social science teachers, implement changes across backend, frontend, and UX layers, and test the system in a smaller master’s-level course. This was not a controlled evaluation of learning outcomes, but rather qualitative workflow validation: the aim was to observe whether RUCAI could support realistic course use while remaining grounded in assigned materials.

All software implementation was carried out by one developer, including the FastAPI backend, PostgreSQL/pgvector integration, Ollama model serving, ingestion, retrieval, student-instance functionality, frontend interface, and deployment scripts. Pedagogical feedback shaped implementation priorities: course-centered interaction led to the course workspace design; the need to refer back to readings led to citation normalization and source display; and heterogeneous course materials motivated the PDF/DOCX ingestion pipeline and OCR fallback strategy. RUCAI is currently hosted on a local server operated by the Digital Media Lab at Roskilde University. The architecture does not depend on this specific setup: future development could make the inference layer more modular by allowing RUCAI to call a configurable GPU-backed inference endpoint, whether local, institution-hosted, or approved cloud-based.

Ingestion and retrieval implementation

RUCAI uses Ollama-served embedding models for all document and query embedding operations. The default model is bge-m3 (BAAI General Embedding, multilingual, 1024-dimensional dense embeddings), selected for its strong performance on multilingual content, including Danish. The embedding model is configurable via the environment variable (EMBED_MODEL), allowing operators to substitute alternative Ollama-compatible models without code changes. All embeddings are stored in a pgvector column and retrieved via cosine similarity. The system supports both the legacy /api/embeddings and the newer /api/embed Ollama endpoints, with automatic fallback between them.

Chunking

RUCAI uses fixed-size overlapping chunking defined by word count (not token count): the default is 800 words per chunk with an overlap of 100 words between adjacent chunks (step = max_words – overlap). The chunking algorithm splits on whitespace, ensuring that word boundaries are preserved. Each chunk stores its text content, the originating document identifier (used as the citation normalization key), the page number where recoverable, and a position index within the document. This word-based design is conservative but predictable across heterogeneous document formats.

Document extraction pipeline

Born-digital PDFs are processed using pypdf; DOCX files are processed using python-docx. The extraction pipeline is designed around the principle of graceful degradation: when a primary extraction method yields insufficient text, the system automatically falls back to progressively more capable but slower alternatives. The primary path uses direct text extraction; if output quality is below a character threshold, the system falls back to docling (a layout-aware document converter with built-in OCR); if that too yields no usable text, a tertiary fallback to MinerU is triggered. This three-tier design ensures that even severely degraded scanned documents are processed, while born-digital documents are handled efficiently without unnecessary OCR overhead.

Language is detected per-document using a custom word-frequency heuristic that counts occurrences of Danish and English function words and Danish-specific characters (æ,ø, and å). The detected language is stored as document metadata and displayed in the UI. The scan-mode flag is set at upload time by the teacher; it is not auto-detected.

Intent-aware retrieval

A practical problem in course-based RAG is that different question types require different retrieval strategies. A narrow factual question is best served by a few highly relevant chunks from one text, while a synthesis question (e.g., “how does the curriculum fit together?”) requires evidence drawn across multiple documents. RUCAI addresses this by classifying each query into one of three intents – narrow, synthesis, or compare – using a lightweight keyword-phrase heuristic that runs before retrieval. Each intent maps to a distinct retrieval profile that controls how many chunks are retrieved and whether results are diversified across documents. For synthesis and comparison queries, query variant expansion and multi-round retrieval are triggered automatically when initial coverage is insufficient. The intent label and retrieval metadata are returned transparently to the teacher in every response.

Citation normalization

A common problem in chunk-based RAG systems is that multiple retrieved text passages from the same document appear as separate “sources” in the response, inflating the apparent number of independent references. In teaching contexts, this can mislead users into overestimating the breadth of supporting evidence. RUCAI addresses this through citation normalization: retrieved chunks are grouped under a canonical source key derived from the document filename. The response reports both the number of unique sources and the number of retrieved chunks, allowing teachers to distinguish genuine multi-source corroboration from repeated retrieval from a single text.

Student-instance publication

When a teacher publishes a student instance, the practical workflow is as follows (see Figure 2): The teacher selects the course materials and prompt instructions that should be available to students, reviews the locked grounding and uncertainty rules, and publishes an instance from the teacher workspace. At publication time, the system creates a persistent instance record consisting of: (1) prompt snapshots – the editable instructions, the locked safety block, and the effective system prompt at publication time, each stored as a separate string; (2) a copied chunk corpus snapshot, copied at publish time from the source course corpus and not live-linked to teacher chunks; and (3) instance-specific access credentials or an access link. Students then access only the student chat interface, authenticated via the instance session. Later teacher-side edits to the course or prompt do not change that published instance unless the teacher republishes it or creates a new instance.

Figure 2.

Example from the student-instance publication window.

Figure 2 Long description

The screenshot shows the teacher form used to publish a locked student chat window from the active course. A large editable text box contains the student prompt. It defines three tasks: help students understand curriculum texts and concepts; explain connections and differences across texts; and support revision and study exercises using only the material. The rules require answers to use and cite the provided sources, state when sources are insufficient, use clear English, and act as a supervisor and sparring partner rather than writing complete projects, problem formulations, or analyses. Below the prompt is a checkbox confirming that the teacher has reviewed it. The lower section contains fields for an internal chat-window name and a student access password, followed by Publish and Refresh chat windows buttons.

Constraint enforcement is two-layered. The hard constraint is retrieval scoping: search reads only from the instance’s own chunk corpus, so the model cannot retrieve outside the published document set. The soft constraint is prompt-based: the frozen prompt instructs the model to answer from the provided sources and to signal uncertainty explicitly. Prompt immutability is enforced at the API level (no endpoint updates these snapshots after publication) rather than by a database-level immutable type. Student instances are logical snapshots, not separate model deployments: multiple instances can share the same server-side Ollama inference service. Classroom-scale use therefore requires GPU capacity planning, request queueing, and model-size choices, but not necessarily a dedicated GPU per student instance.

The student-instance design is consistent with active learning principles (Wessels Reference Wessels2025): rather than providing unconstrained generative output, it constrains responses to course materials and signals uncertainty, encouraging students to engage critically with what the system can and cannot support.

Pilot observations

RUCAI has been tested by university teachers participating in a project on how to use digital methods and tools in DH teaching. The observations reported here are informal pilot records rather than a controlled evaluation study. They are included to provide concrete illustrations of workflow behavior; formal comparative evaluation is listed as a future work priority (see Figure 3 for an example of the teacher chat window).

Figure 3.

Example from the teacher workspace, which supports retrieval-grounded course planning by allowing the instructor to configure source coverage and model settings while maintaining a persistent course-specific chat history. Responses are generated from uploaded curriculum materials and shown alongside source-oriented context for iterative teaching design and reflection.

Figure 3 Long description

The screenshot shows the teacher form used to publish a locked student chat window from the active course. A large editable text box contains the student prompt. It defines three tasks: help students understand curriculum texts and concepts; explain connections and differences across texts; and support revision and study exercises using only the material. The rules require answers to use and cite the provided sources, state when sources are insufficient, use clear English, and act as a supervisor and sparring partner rather than writing complete projects, problem formulations, or analyses. Below the prompt is a checkbox confirming that the teacher has reviewed it. The lower section contains fields for an internal chat-window name and a student access password, followed by Publish and Refresh chat windows buttons.

In terms of the pilot scope, two course-planning contexts were used: (1) a humanities seminar course with a corpus of six assigned readings (three born-digital PDFs, two scanned PDFs, one DOCX), and (2) a course redesign workflow in which a teacher was revising an existing course description against new mandatory learning objectives. The following query–answer–source interaction (see Table 3) is drawn from the first pilot context. It illustrates the grounded-response behavior and citation grouping that are central to RUCAI’s design.

Table 3.

Example of teacher course-planning chat mode

Table 3. Long description

The example query asks whether participation, campaigning, and propaganda remain meaningful distinctions when the same platforms, engagement logics, and emotional dynamics support both democratic mobilization and disinformation. RUCAI answers that the boundaries are increasingly blurred and that these activities can be understood as manifestations of a broader digital political communication system. Source 1 supports this by showing politically engaged people adopting identities, symbols, and messaging strategies also used in disinformation and propaganda. Source 2 describes dissonant public spheres in which campaigns compete with movements, counterpublics, and anti-democratic communities, leading campaigns to use trial and error and popular appeal in the same environment as misinformation. RUCAI then suggests three exercises: compare a political campaign with disinformation tactics; debate whether the three activities should remain analytically distinct; and conduct a critical media analysis of where digital communication strategies overlap and differ.

From the workshop session, it was evident that the system could recognize when a question went beyond what the uploaded course texts covered. In such cases, rather than inventing an answer, RUCAI responded with explicit statements like “the retrieved texts do not address this directly.” This happened consistently without any special setup by the teacher – the behavior is built into the system’s locked grounding rules. When a query exceeded available source coverage, the system returned these honest disclaimers rather than generating plausible-sounding, unsupported claims.

Audience

RUCAI is primarily designed for three overlapping audiences. First, teachers and course planners in humanities and adjacent fields who work with assigned reading corpora and need AI assistance that is disciplined by source attribution. Second, research software engineers and DH practitioners building or evaluating local AI deployment for educational contexts. For this audience, RUCAI is useful less as a finished institutional platform than as a reference implementation of course-scoped RAG: it shows how to connect document ingestion, pgvector-backed retrieval, citation normalization, prompt governance, and student-facing snapshots into one teaching workflow. Third, institutions – particularly universities in policy-constrained or data-governance-sensitive environments – that require reproducible, locally deployable alternatives to cloud-dependent AI tools.

Moving from the current pilot phase to institutional deployment should be understood as moderate engineering and governance work rather than a simple software install. The main effort lies in provisioning a GPU-enabled VM or equivalent server, selecting model sizes that match expected class load, configuring PostgreSQL/pgvector and Ollama, setting authentication and access rules, documenting teacher workflows, and completing local data protection, copyright, and course-material review. RUCAI’s architecture supports this work by keeping inference and storage under institutional control, but it does not remove the need for institutional policy review or operational capacity planning.

RUCAI is designed for multilingual teaching contexts. The default system prompts and UI are in Danish, reflecting the institutional context of its initial development. The underlying architecture – particularly the bge-m3 multilingual embedding model and the custom DA/EN language heuristic – supports extension to other language contexts. The prompt layer is configurable; institutions can adapt base system prompts to other instructional languages without code changes.

Impact

RUCAI has been deployed as a pilot system in a humanities faculty context and has been used by a small cohort of course planners for course description work and cross-text synthesis. The primary observable impact is workflow: teachers report being able to ask synthesis questions across reading lists and receive grounded, source-attributable responses without the need to formulate vector search queries or interpret raw retrieval results. The citation grouping mechanism specifically addresses a practical complaint about chunk-centered RAG interfaces, where multiple chunks from a single text appeared as independent evidence items.

The student-instance mechanism extends this impact to classroom orchestration by allowing teachers to transform planning artifacts into constrained student interaction windows without rebuilding the pipeline. The source-grounded response principle – reflecting the expectation that AI-assisted responses should be traceable to specific course texts and should express uncertainty when evidence is limited (Huang and Lee Reference Huang and Lee2025; Pollin et al. Reference Pollin, Fischer, Sahle, Scholger and Vogeler2025) – is operationalized as a locked grounding rule rather than a configurable option.

Limitations

RUCAI is a pilot-stage system with stable core workflows and ongoing development. This section explicates some of the limitations of the current system. First, RUCAI currently lacks a formal comparative evaluation against baseline systems under controlled conditions. The assertions in this paper are implementation and workflow claims, not generalized performance claims. Pilot observations are reported in the Pilot Observations section; formal evaluation studies comparing citation accuracy, teacher utility, or student learning outcomes remain future work. Second, scanned documents with severe degradation (heavy skew, poor contrast, and non-standard fonts) remain a bottleneck for retrieval quality. The three-tier extraction pipeline (pypdf → docling → MinerU) provides fallback coverage, but software controls cannot compensate for irretrievably poor-quality source material. Teachers working with degraded archival scans should treat retrieval results with additional caution. Third, RUCAI can support multiple simultaneous users, but high concurrency requires careful tuning of Ollama’s keep-alive settings, request queue depths, and GPU memory allocation. The system provides configuration controls for these parameters, but no universal concurrency guarantee is claimed. Fourth, RUCAI’s local-first design supports institutional data governance requirements, but legal and policy compliance is context-specific. The software architecture creates the conditions for compliant deployment; it does not constitute compliance itself. Institutions should review applicable data protection regulations (e.g., GDPR for European deployments) and copyright or text-and-data-mining policies before deploying with course materials.

Two additional boundary conditions are important for classroom use. First, RUCAI constrains interaction inside the RUCAI interface; it cannot technically prevent a student from copying course materials or generated responses into another AI platform. That risk must be handled through assessment design, academic-integrity policy, and explicit classroom guidance. Second, student instances are bounded runtime snapshots that can share a common inference service. Their scalability depends on the institution’s model choice, GPU memory, request queueing, and expected concurrency rather than on the number of logical instances alone.

Ethical and pedagogical considerations

RUCAI’s design implies a pedagogical stance emphasizing how AI responses in humanities teaching should be inspectable, revisable, and explicitly constrained by available evidence. The system favors grounded assistance over unconstrained fluency.

This stance has ethical implications. It reduces – but does not eliminate – the risk of misleading outputs. When evidence is sparse or retrieval is imperfect, the system can still produce confident-seeming language. RUCAI’s uncertainty-signaling behavior mitigates this risk but does not resolve it entirely. Teachers should review AI-generated responses rather than relay them uncritically to students.

The system can shift rather than reduce labor. Teachers may spend less time drafting a synthesis from scratch but more time evaluating AI-grounded suggestions against their own knowledge of the course texts. RUCAI is designed to make that evaluative labor more tractable through grouped citation display and explicit confidence signals, but it does not reduce the need for teacher judgment.

In student-facing contexts, the student-instance mechanism supports instructional control but does not constitute pedagogical neutrality. The prompt framing, source boundaries, and instructional language that teachers configure shape what students experience. Software transparency should be paired with pedagogical transparency: teachers should be able to explain to students what sources the system is using and what constraints govern its responses. Students may still move material outside RUCAI into less constrained systems, so RUCAI should be treated as one part of a broader teaching and assessment design rather than as a complete academic-integrity solution.