Our story

Starting from the student experience.

RedAPPL grew from firsthand questions about how AI can support learning without overriding instructor intent. What started in the classroom quickly revealed a much larger institutional problem.

Shape the product

The starting point

Students were already using AI.
The rules around it were still catching up.

Students were bringing increasingly capable AI tools into everyday academic work. Professors were writing more detailed expectations. Universities were developing broader guidance.

But a generic tool did not arrive knowing the course, the assignment, the instructor’s intent, or the university’s rules.

That gap became the starting point for RedAPPL.

University / professor intent

Course context
Assignment expectations
Academic rules

The gapIntent wasn’t reaching the tool.

Generic AI tool

A capable model.
No built-in knowledge of this assignment’s boundaries.

RedAPPL began with the connection between them.

The first idea

What if an AI policy could actually change how the AI behaved?

The first question was specific: could an instructor’s assignment policy shape the help a student receives? The rules should live in the experience itself, not only in a syllabus.

  1. Professor writes policy
  2. RedAPPL configures capabilities
  3. Student AI experience changes

An example assignment

BrainstormingAllowed
OutliningAllowed
Concept explanationAllowed
Draft generationRestricted
RewritingRestricted

Imagine the interaction

Student

“Write my introduction.”

RedAPPL

“This assignment allows brainstorming and outlining, but not draft generation. I can help you structure the argument instead.”

The problem turned out to be bigger than assignments.

Every assignment-level decision opened another question.

  • Who should have access, and which rules should follow their role?
  • Which models should the institution allow?
  • What should be inherited—and what should professors control?
  • How should course and assignment context change the response?
  • What happens when the underlying provider changes?

An assignment-policy idea became a university AI control layer.

The idea widened

  1. Institution
  2. Department
  3. Course
  4. Assignment
IdentityModelsPolicyContext

One classroom question led us to the institution around it.

Built with higher education

We don’t want to build university software in isolation.

RedAPPL’s direction is being shaped through conversations with people inside higher education. We’re developing a design-partner process that brings hands-on feedback into the work.

Actual academic workflows, institutional constraints, and pedagogical priorities should shape the product—not assumptions made from outside the university.

Design-partner work can include

01

Try the workflow

Test early product experiences using synthetic courses and assignments.

02

Examine the behavior

Explore how configured policies change the assistance students encounter.

03

Challenge the product

Give UI and UX feedback, question assumptions, and identify missing requirements.

04

Ground the next step

Help define what a realistic, tightly scoped pilot could look like.

A working relationship. A shared direction.

We’re shaping the partnership around an exchange: access to the product as it develops, and insight from the people it is meant to serve.

What RedAPPL brings

  • Early product access
  • Direct access to the founding team
  • Rapid iteration
  • Meaningful influence over product direction
  • Synthetic prototype testing
  • A path toward tightly scoped pilots, where appropriate

What design partners bring

  • Real academic workflows
  • Honest criticism
  • Policy examples
  • Product testing
  • Institutional context
  • Feedback on what would make adoption realistic

Design partners help shape the product.
They don’t have to adopt it.

Become a Design Partner

Where we are

Still early.
Already learning fast.

We’re developing the product and design-partner process, learning from educators, and using synthetic environments to explore university workflows. That work is intended to inform tightly scoped pilot opportunities where there is a good fit.

  1. 01

    Build

    Develop the early product

  2. 02

    Test

    Explore synthetic workflows

  3. 03

    Learn

    Refine with educator feedback

  4. 04

    Pilot

    Work toward a scoped opportunity

The founder perspective

Built from inside the university experience.

RedAPPL began with a university student watching generative AI change how academic work was being done.

That perspective led to conversations with professors, teaching and learning professionals, institutional stakeholders, and people thinking about AI governance in higher education.

The question grew beyond how to stop students from using ChatGPT. It became a question about who gets to decide the conditions of use.

How should universities decide what AI is allowed to do?

What we believe

Universities shouldn’t have to choose between banning AI and surrendering control of it.

  • AI can support learning without replacing learning.
  • Professors should be able to express instructional intent in the tools students actually use.
  • Institutions should control access and policy without being locked into one model provider.
  • Students should understand the AI boundaries of their work before they cross them.

Universities should own the rules that govern AI—even if they don’t own the underlying models.

Help shape how universities use AI.

We’re building RedAPPL with people who want universities to move from reacting to AI toward governing it intentionally.

Become a Design PartnerTalk to the Founder
Explore Why RedAPPL