RTS Developer & Pedagogical Brief on Movement 1 — From Spark to Stakes

updated 08.29.25

Why RTS?

Too often, I’ve seen undergraduate multimedia projects stall at the threshold of production. Students arrive with research in hand but then feel adrift when asked to translate it into media. “Why am I learning this software if my ideas are already clear?” The question seems practical, but it points to something more: a lingering belief that media production is just a delivery mechanism, and not a generative thinking space. That the work of the story is already finished, and the medium is purely incidental, or worse, just a tool.

Many students begin their projects with a quiet dread: the sense that now comes the part they’re “not good at.” The shift from research to media-making is often framed as a handoff—from thinking to doing, from analysis to decoration. “Creativity” gets cast as an intuitive gift some students have, while communication tools are treated as neutral containers. The result is disorientation, detachment, and a fair dose of missed opportunity.

Research To Story (RTS) begins from a different belief: that making is a way of knowing. That the tools, formats, and rhythms of media production don’t just convey ideas, they have the power to reshape them. RTS is designed to help students notice their thinking evolve as they build and to experience making as more than some “techie” interruption, but as another place where their questions stretch, clarify, and come alive.

It’s really about recovering the spark that made the topic matter in the first place and discovering what that spark can become when it meets a medium, an audience, and their own voice.

RTS was born from listening to all this signal and all this noise. It is built on a foundational principle: making is a form of thinking. RTS aims to help students continue to work on what their research is about, but also what it might do, how it might take shape, spark response, and live “out there” in the world. By framing media work as a site of discovery, RTS aims to collapse an entrenched binary between doing and thinking and to open up a space where students can experiment, reflect, and narrate their own inquiry. In this way, RTS is a tool, but it is also a position.

This briefing document outlines the architecture of Movement 1 of RTS where this process begins.

Movement 1: The Generative Engine of the Entire RTS Framework.

While students work on the “aboutness” of their research topic, Movement 1 of RTS is designed to present another layer, intervene and help the student elaborate on that topic by supporting early curiosity, identity, and audience awareness into a threadable narrative posture. Pedagogically speaking, this is the groundwork for the process of going from research to story.

In the RTS system, Movement 1 serves as a type of incubation chamber for topic development for a topic that is not going to live in a research paper - but rather a podcast or audio essay. While it does function somewhat like a brainstorming tool, it is a deliberate pedagogical structure that aims to cultivate a reflective stance on the inquiry process through three foundational postures:

• 🧭 Personal Connection
• 🔬 Research Potential
• 🎯 Audience Awareness

These postures frame the journey of Movement 1 from “Spark to Stakes” and are the rhetorical (and pedagogical) ingredients for this early fusion of thinking and making. Every RTS session begins here and a purposefully developed Movement 1 sets the thread that carries through subsequent movements.

From a development perspective, Movement 1:

• Establishes the session_id: the root container for a student’s inquiry
• Seeds reflective traces and metadata for all downstream movements
• Surfaces student voice, but in structured tension with scholarly framing and public orientation
• Trains AI in context-aware follow-up logic, grounded in five ideational categories and a recursive synthesis loop

This movement is designed to transition students from "What is my research about?" to "What can my research do out in the world?" with the podcast medium as the communicative target.

Movement 1 Elaborated: From Spark to Stakes

Purpose

To surface the raw energy and purpose behind a student’s interest before citation, before structure. The work of Movement 1 is to discover what’s already alive under the surface.

Postures & Prompts

🔹 1. Personal Connection

Core Question: What drew you to this topic?

Pedagogical Goal: Uncover students’ lived curiosity and experiences.

Outcomes:

• Articulate a personal stake
• Identify genuine confusion or curiosity
• Reframe research as agency

⠀Sample Prompts:

• What first pulled you toward this topic?
• Even if it was assigned, where do your experiences or interests meet the subject?
• What feels unresolved or confusing right now?

🔹 2. Research Potential

Core Question: What do you want to figure out?

Pedagogical Goal: Highlight contradiction, complexity, and intellectual stakes.

Outcomes:

• Frame meaningful questions
• Surface gaps or challenges
• Identify scholarly friction

⠀Sample Prompts:

• What assumptions does everyone seem to make?
• What has surprised you so far?
• Where have you changed your thinking?

🔹 3. Audience Awareness

Core Question: Why does this topic matter to others?

Pedagogical Goal: Shift toward rhetorical purpose.

Outcomes:

• Specify a public or disciplinary audience
• Clarify intended impact
• Figure out what “evidence” will look like

⠀Sample Prompts:

• Who needs to hear this story?
• How would you explain this to a friend, policymaker, skeptic?

Core Architecture: The Movement 1 Flow

Session-Level Structure

1. Student enters a topic (messy, personal, or specific)
2. The system initiates a 4-round journey:
   • Each round includes:
     • AI-generated interpretive summary
     • 10 follow-up questions (2 per category - see below)
     • Student chooses 1 to answer
     • System logs selected Q&A + unused questions
   • Each round builds on the previous — generating a reflection trail
3. At the end of Round 4, a prompted generative AI model generates a synthesis of the student’s inquiry arc.

The Follow-Up Categories: Five Ideational Postures

Category	Goal
🔥 Spark of Inquiry	Surface personal resonance, formative moments, naive curiosity
📚 Inquiry as Story	Frame scholarly tension as narrative
🌎 Stakes and Significance	Articulate broader impact and urgency
🧩 Puzzles and Unknowns	Explore contradictions, gaps, and uncertainty
🎧 Listeners and Lens	Imagine the rhetorical impact and shape of a podcast episode

• These categories guide question generation, reflection logging, and later deep dives.
• Each round’s AI output is stored with token metadata and model config (see transparency notes below).
• After the core 4 rounds, students may choose to “zoom in” on one or more ideational/analytical category. (Deep Dives)

Pedagogical Principles At Play

• Research is content discovery and it's story preparation.
• Reflection is additive and it's foundational to inquiry.
• GenAI can be a shortcut but can it also function like a provocateur, Socratic partner, and reframing engine? Yes, unacknowledged metaphors are problematic in genAI's cultural story- This is a guiding research question of RTS development
• Transparency matters — students can review all their AI interactions and metadata. (What exactly is “transparent” is still murky with these LLMs)

RTS: Conceptual Model & Identifiers

RTS (Research to Story) is built around deep, reflective engagement with a single topic — what I call a session. But this process is always contained within a course. Nothing in RTS happens outside that scope.

✅ 1. course_id (The Walled Garden)

Every RTS journey lives inside a course. A course may have many sessions (i.e., different research projects or topics a student explores over time), but these sessions do not exist globally — they only make sense within the context of a course. This allows instructors to assign multiple RTS sequences over time, while keeping data scoped to that course’s theme, pacing, and instructor guidance.

✅ 2. session_id (The Inquiry Thread / Project Container)

A session_id is the anchor for a single, continuous research story.

• It’s equivalent to a notebook, a research journey, or a topic thread.
• All reflections, AI-generated outputs, metadata, and artifacts (syntheses, search terms, podcast suggestions, etc.) are scoped to a single session_id.
• On a student dashboard, the session is what they “click into” — it’s their project.

➡️ Example: A student in a course might have two sessions over time:

• One exploring AI in Education
• One exploring Narrative Journalism

✅ 3. movement_number (The Narrative Timeline)

RTS is sequenced through a scaffolded progression called Movements — each one guiding a different mode of reflection, analysis or research action (e.g., Personal Connection, Research Potential, Public Impact, Friction, Medium Awareness, etc.).

• A movement_number marks where a student is in that journey.
• Movements are ordered (e.g., “1”, “2”, “3”, … “6”) and each one holds unique prompts, outputs, and pedagogy.
• All activity in RTS is both session-specific and movement-specific. Each of these has a separate session_id, even though both live inside the same course_id.

In database terms:

session_id + movement_number → determines which reflections, AI prompts, syntheses, and metadata are relevant.

How This Enables the RTS Dashboard + Ledger

This structure allows for flexible yet organized UI/UX:

• Dashboard view: “Show me all my sessions across time, sorted by course.”
• Session view: “Show me my full narrative journey for this topic (session_id), across all Movements.”
• Ledger view: “Audit all the AI-generated outputs, student reflections, search terms, and narrative artifacts tied to a given session.”

Summary in Developer Speak

• course_id = scope boundary
• session_id = project container (1 per inquiry journey)
• movement_number = ordered step in the RTS scaffold
• user_id + session_id + movement_number = unique context for any reflection, AI interaction, or output
• RTS never functions without all 3 of these anchors.

How and Why I’m Using Generative AI in RTS — Pedagogical and Developmental Rationale

First of all, RTS is personal research platform that I’m using to interrogate generative AI more broadly. What is it? What can it do? How does it work? Can RTS use generative AI as a tool for provocation, structure, and reflection. May aim is to frame its role as a surface, a place to shape a meaningful dialogue between student and topic — helping learners look at what they didn’t yet know they were trying to say. And finally ask, what does that mean? What’s possible here?

Pedagogical Framing

• Generative AI as Question Maker: In Movement 1, Google’s Gemini 2.5 model is heavily instructed through prompts to surface questions grounded in course context and rhetorical goals.
• Traceable AI Influence: Students see not just the outputs, but the “logic” behind them: token counts, interpretive summaries, “thought” traces. This (attempt at) transparency supports AI literacy and invites metacognition.
• Iterative Inquiry: Each round is designed to deepen understanding, not complete a task. Generative AI doesn't write the story rather it aims to shape the inquiry that leads to one.
• Pedagogical Guardrails: All prompts are tightly constrained, schema-validated, and mapped to specific reflection categories tied to course outcomes. So it is not an open-ended chat — it's structured generative scaffolding.

⠀Development Implementation

• Structured Prompting with Gemini 2.5: RTS uses the Gemini API (generateContent) with:
  • responseSchema for precise, JSON-based outputs
  • thinkingConfig to surface token usage and model “thoughts”
  • Controlled temperature and prompt templates tailored to the movement and round
• Full Context Trace: Every AI interaction is scoped to a session_id, movement_number, and round_number, and logged to Supabase with metadata for:
  • AI interpretive summaries
  • Model token usage (prompt, response, thoughts)
  • Reflection questions (answered and skipped)
  • Student responses
• Synthesis via AI, Interpretation via Student: At the end of each 4-round journey, Gemini produces a synthesis but this is always framed as one possible story, just another “text,” inviting student critique, remixing, or expansion.

Developer-Facing RTS Overview: Why This System Exists and How It Works

RTS is a pedagogical and technical response to a recurring bottleneck in student-centered media education: the assumption that research and production are separate phases. From a system design perspective, treats student reflection, rhetorical development, and generative AI interaction as structured data.

The Core Architectural Premise

Each student journey is:

{
  course_id: UUID,              // the learning container
  session_id: UUID,             // the project container
  movement_number: integer      // the stage of inquiry
}

Everything in RTS—AI questions, student responses, metadata, synthesis—is scoped to that triple.

Supabase Table Highlights

rts_sessions

Root record for each topic-specific inquiry:

session_id UUID PRIMARY KEY
user_id UUID
course_id UUID
topic_text TEXT
current_movement_number INTEGER
model_used TEXT

followup_questions_log

10 AI-generated questions per round, categorized:

session_id UUID
movement_number INTEGER
round_number INTEGER
category TEXT                -- e.g., "Spark of Inquiry"
question_text TEXT
model_used TEXT

reflection_rounds

Captures the student’s response and logs model metadata:

session_id UUID
movement_number INTEGER
round_number INTEGER
user_reflection TEXT
answered_question_id UUID
interpretive_summary TEXT
prompt_token_count INTEGER
response_token_count INTEGER
thinking_token_count INTEGER
thought_summary TEXT

movement_synthesis

The AI’s end-of-movement summary of the reflection arc:

session_id UUID
movement_number INTEGER
synthesis_text TEXT
thought_summary TEXT
total_token_count INTEGER

API Handler Trio Flow Example for Movement 1

generateFollowupQuestions.ts

• Pulls session history (topic_text, prior reflections)
• Calls Gemini 2.5 with:
  • responseSchema for structured categories
  • thinkingConfig for token traceability
• Writes 10 follow-up questions to followup_questions_log
• Returns:
  • Interpretive summary
  • Questions grouped by category
  • Token breakdown + AI thought trace

const result = await model.generateContent({
  contents,
  tools: [{ functionDeclarations: [structuredSchema] }],
  generationConfig: {
    responseMimeType: "application/json",
    temperature: 1.2,
    thinkingConfig: {
      includeThoughts: true,
      thinkingBudget: -1
    }
  }
});

saveFollowupRound.ts

• Validates session_id ownership via Supabase Auth
• Logs:
  • Selected question
  • Student response
  • Model metadata (tokens, interpretive summary)
• Stores data in reflection_rounds

generateSynthSummary.ts

• Fetches all 4 reflection_rounds
• Feeds content to Gemini for synthesis
• Returns:
  • synthesis_text
  • thought_summary
  • token_usage block
• Writes to movement_synthesis

Query Pattern Example

To retrieve a full narrative trace with AI metadata for one session:

SELECT 
  r.round_number,
  r.user_reflection,
  r.interpretive_summary,
  f.category,
  f.question_text,
  m.synthesis_text,
  r.prompt_token_count,
  r.response_token_count,
  r.thinking_token_count,
  r.total_token_count,
  r.thought_summary
FROM reflection_rounds r
JOIN followup_questions_log f 
  ON r.answered_question_id = f.id
JOIN movement_synthesis m 
  ON r.session_id = m.session_id
WHERE r.session_id = 'abc-123-uuid'
  AND r.movement_number = 1
  AND m.movement_number = 1
ORDER BY r.round_number ASC;