Support SavvyConsulting IT & Security Overview · Interactive Case Study Builder
Interactive Case Study Builder

IT & Security Overview

Hosting, student data, AI providers, security controls, retention, and access — for university IT, security, and privacy reviewers evaluating a pilot or purchase.

Audience · University IT, security & privacy Hosting · United States Updated · 1 Oct 2026

AI Made Simple. Knowledge Made Yours.

01
Chapter One

At a Glance

The Interactive Case Study Builder is a web application. Instructors build a business case with AI-played executives and share one link; students open the link, interview the executives, and download a PDF report of their consultation. This guide answers the questions a university IT, security, or privacy reviewer typically asks before a pilot or purchase.

Where data goes Students (no account) and staff (signed in through Clerk) connect over HTTPS only to casebuilder.studio, hosted on Vercel in the United States. The application alone calls Neon Postgres, Clerk, your institution's AI provider with your key, Upstash Redis, and Stripe. Students Case link + display name No account Instructors & admins Email + password via Clerk HTTPS HTTPS casebuilder.studio Application on Vercel United States Every AI call is made here. Keys never reach a browser. YOUR KEY Neon Postgres Data · AWS us-east-1 Clerk Staff sign-in Your AI provider Claude, OpenAI or Gemini Upstash Redis Rate-limit counters Stripe Billing only
Figure 1Students and staff connect only to casebuilder.studio. The application alone calls the database, sign-in, billing, and your institution's AI provider with your key.
QuestionShort answer
DeliverySoftware-as-a-service in the browser at casebuilder.studio. Nothing to install.
HostingUnited States. The application runs on Vercel; the database is Neon Postgres in AWS us-east-1 (N. Virginia).
Student accountsNone. Students open a link and type a display name. No email, student ID, password, or institutional login.
Student data storedThe self-entered display name and the chat messages, held for the report and for your retention window.
AI providerYour institution's own Anthropic (Claude), OpenAI, or Google (Gemini) account and key. We hold no AI account of our own for your traffic.
Used to train AI?We do not train models. Whether your provider may use API traffic is governed by your institution's agreement with that provider.
Staff sign-inEmail and password through Clerk. MFA and SAML SSO are not available yet.
LMS integrationNone. No LTI, roster sync, or grade passback; the product is used through a shared link.
RetentionSet by your administrator in days, with on-demand deletion. Default is to keep until deleted.
AttestationsNo SOC 2, ISO 27001, HECVAT, VPAT, or third-party penetration test at this time.
02
Chapter Two

How It Works

Three kinds of people use the product, and only staff have accounts.

Three roles, one case link Inside the institution's organization, an administrator connects the AI key, invites instructors, sets retention, deletes transcripts and handles billing. An instructor builds, previews and publishes a case. A student without an account opens the case link to enter a display name, chat with the executives and download a PDF report. YOUR ORGANIZATION · SIGNED-IN STAFF Administrator Connects the AI key Invites instructors Sets data retention Deletes transcripts Handles billing Instructor Builds the case Previews it Publishes one link Revokes it at any time CASE LINK Student No account Types a display name Chats with executives Downloads a PDF
Figure 2Only staff sign in. Students reach a case only through its link, and revoking the link ends their access.
WhoAccessWhat they do
Institution administratorSigned-in account, admin roleConnects the institution's AI provider key, manages instructor seats and invitations, sets data retention, deletes transcripts, handles billing.
InstructorSigned-in account, instructor roleBuilds cases (company, executives, assignment), previews them, publishes or revokes the student link, generates teaching notes.
StudentThe case link only — no accountEnters a display name, reads the brief, chats with the executives, downloads a PDF report once the instructor's minimums are met.

Each institution is a separate organization (tenant). Every staff request is scoped to the signed-in user's organization on the server, so one institution's cases, settings, and transcripts are never visible to another.

Each case has one live student link. An instructor can revoke it at any time, and a revoked link stops working immediately — for the page and for the chat.

03
Chapter Three

Architecture & Hosting

A single web application with no client-side AI. Every AI call is made from our servers, so provider keys never reach a browser.

Figure 1 shows the services involved. Figure 3 follows one student message through them.

One student message, step by step 1: the student's browser sends a message over HTTPS to casebuilder.studio. 2: the application checks in Neon Postgres that the case link is still live. 3: it checks the rate limit in Upstash Redis. 4: it checks the organization is active and loads the case and the encrypted AI key. 5: it saves the student's message. 6: it sends the prompt and recent history to your AI provider with your key. 7: the reply streams back to the student. 8: the application saves the AI reply. A failed check stops the request before anything reaches the AI provider. Student's browser casebuilder.studio Upstash Redis Neon Postgres Your AI provider 1 Sends a message over HTTPS 2 Is this case link still live? 3 Within the rate limit? 4 Org active? Load the case and encrypted key 5 Save the student's message 6 Prompt + recent history, sent with your key 7 Reply streams back to the student 8 Save the AI reply
Figure 3What happens when a student sends one message. If any check in steps 2–4 fails, the request stops there and nothing reaches your AI provider.
  • Server-side AI only. Student devices talk only to casebuilder.studio; they never contact the AI provider directly.
  • No analytics or tracking. The application includes no analytics, advertising, session-recording, or error-tracking scripts.
  • Release process. Every change passes type checks, linting, automated tests, and a production build, then runs on a separate staging environment with test data before it reaches production.
04
Chapter Four

Data We Collect

The product is built on data minimization: students are never identified, and we store only what the experience needs.

The student's browser

Local storage on their own device

  • Display name
  • The conversation so far

Kept until the student chooses Start Fresh

Our database

Neon Postgres, United States

  • Display name
  • Messages and AI replies
  • Random session identifier

Kept for your retention window, or until deleted

Rate limiter

Upstash Redis, United States

  • Request counters keyed by IP address

Expire within 60 seconds

Your AI provider

Your institution's own account

  • Case material, messages and recent history, sent per request

Governed by your agreement with that provider

Never collected

  • Email
  • Student ID
  • Password
  • Grades
  • Demographics
  • Institutional login
Figure 4Where each piece of student data lives, and for how long.

Students

DataStored?Notes
Display nameYesFree text the student types (up to 80 characters). Not verified, matched, or linked to any institutional record.
Chat messages and AI repliesYesStored with the display name so the report can be built, and kept for your retention window.
Random session identifierYesGenerated in the student's browser to keep one student's conversation together. Not tied to identity.
IP addressTransientlyUsed only to rate-limit the student pages; the counters expire within 60 seconds. Not stored in the database.
Email, student ID, password, grades, demographicsNoNever requested or collected.
The PDF reportNoGenerated on request from the stored conversation and downloaded by the student; not kept as a file.

Before typing a name, every student sees a short notice explaining what is saved and that the institution decides how long it is kept, with a link to the full Data Handling & Privacy notice. The downloaded report carries the same pointer.

In the student's browser, the conversation and display name are kept in local storage so a student can close the tab and resume. A Start fresh control clears them. The application sets no cookies of its own.

Staff

  • Account details (name, work email, role) are held by our sign-in provider, Clerk.
  • Cases instructors author — company profile, executives, assignment.
  • Agreement acceptance records: when an administrator accepts trial terms, we record who accepted, the institution's legal details, the time, IP address, browser, and a fingerprint of the exact text accepted.

Institution and billing

Organization name, plan, seat count, and billing identifiers. Card details are handled entirely by Stripe and never reach our systems.

05
Chapter Five

AI & Your Provider

You bring your own AI key. Conversation content goes to the provider account your institution controls, under your institution's terms with that provider.

How your AI key is handled An administrator enters the key. It is checked with your provider and rejected if invalid, then encrypted with AES-256-GCM and stored as ciphertext plus its last four characters. On each AI call the key is decrypted in server memory and used to call your provider from our servers. A browser only ever sees the last four characters. Admin enters key Administrator role only Checked With your provider; rejected if invalid Encrypted AES-256-GCM Stored Ciphertext + last 4 EACH AI CALL Decrypted In server memory only Your AI provider Called from our servers What any browser sees The last 4 characters only, e.g. ••••a1b2
Figure 5Your key is verified, encrypted, and only ever decrypted on our servers for the moment of an AI call.
  • Supported providers: Anthropic (Claude), OpenAI, and Google (Gemini). An administrator picks the provider and models and enters the key.
  • What is sent: the case material, the student's messages, and recent conversation history for chat; the student's conversation for report generation; the instructor's case material for case design and teaching notes.
  • Key protection: the key is checked with the provider before it is saved, then encrypted at rest with AES-256-GCM. Only its last four characters are ever shown again, and it is never returned to a browser.
  • Training and retention by the provider are governed by your institution's own agreement with that provider. Because the account is yours, so are those settings.
  • Pedagogy guardrails: the AI executives are instructed to guide students with questions rather than do their work, and student text in report generation is treated strictly as data, not instructions.
Spending

AI usage is billed by your provider to your institution's account. Students are rate-limited per link, and instructors can revoke a link at any time. Administrators can replace the key in the application, and can revoke it at the provider to stop all AI usage immediately.

06
Chapter Six

Sub-Processors

The services that process data on our behalf. The authoritative, maintained list is at casebuilder.studio/legal/subprocessors.

ServicePurposeDataLocation
ClerkStaff sign-in and organizationsAdministrator and instructor accounts onlyUnited States
NeonDatabaseCases and display-name transcripts; encrypted at rest at the platform levelUnited States
VercelApplication hostingRequests in transit; no student data at restUnited States
StripeBillingInstitution billing contact onlyUnited States
UpstashRate limitingIP-keyed counters, expiring within 60 secondsUnited States
Your AI providerConversation processingStudent messages and AI replies, through your own keyPer your provider account
07
Chapter Seven

Security Controls

What is in place today, stated plainly.

Checks on every staff request A staff request arrives over HTTPS, must carry a signed-in Clerk session, is scoped to the organization taken from that session, passes a role check for administrator actions, and an active-organization check, before it reaches data filtered to that organization. Failing sign-in requires sign-in; failing the organization or role check is refused with 403; an inactive organization is refused with 402. HTTPS TLS + HSTS (two years) Signed in? Clerk session Sign-in required Your org From sign-in, not the request Refused · 403 Role Admin-only actions Refused · 403 Org active? Paid, or trial in its window Refused · 402 Your data Filtered to your org only
Figure 6The checks a staff request passes before it reaches any data. The role check guards administrator actions; the active check guards case building, AI tools, sharing and the student pages.
AreaControl
Encryption in transitHTTPS only, with HTTP Strict Transport Security (two years, subdomains included).
Encryption at restDatabase encrypted at rest by the database provider. AI provider keys additionally encrypted by the application (AES-256-GCM).
Tenant isolationEvery staff request is scoped server-side to the signed-in user's organization, taken from the sign-in session, never from the request.
RolesAdministrator and instructor. Only administrators can change the AI key, seats, retention, or delete transcripts.
Instructor-only contentHidden case material (each executive's private brief and instructions) is removed on the server before a case is sent to a student's browser.
Input validationRequest bodies are validated against schemas with length limits before any processing.
Abuse protectionRate limits on the public student endpoints and on the AI case-design tools.
IntegrationsBilling and sign-in webhooks are verified by cryptographic signature; scheduled jobs require a secret.
Browser hardeningClickjacking protection, MIME-sniffing protection, a strict referrer policy, and camera, microphone, and location disabled by policy. A Content Security Policy runs in report-only mode while it is tuned.
Report safetyPDFs are built from text only, so student or AI content cannot inject markup.
DependenciesAutomated weekly dependency-update proposals; every change runs the full test suite.
08
Chapter Eight

Access & Authentication

  • Staff sign in with email and password through Clerk. Administrators invite instructors; seats are capped by your plan. Multi-factor authentication and SAML single sign-on are not available yet.
  • Students have no accounts. Anyone with a case link can use it while it is live, so treat links like course materials: share them in your LMS or class channel, and revoke a link to end access.
  • Our access as the operator. Support Savvy Consulting operates the service and has administrative access to the hosting and database infrastructure. Our operator console manages organizations, seats, and invitations and shows activity counts; it does not display transcript content.
09
Chapter Nine

Retention & Deletion

Your administrator controls how long student conversations are kept.

How retention works Conversations age from the day they are saved. While they are younger than your retention window they are kept. A nightly purge at 03:00 UTC deletes anything older than the window. Administrators can also delete on demand, and with no window set, conversations are kept until deleted. KEPT Deleted by the nightly purge 03:00 UTC Your retention window, set in days Saved today Older Administrators can also delete on demand: one case, anything older than an age, or everything. With no window set, conversations are kept until an administrator deletes them.
Figure 7Each conversation is kept until it is older than your retention window, then removed by the nightly purge.
  • Retention window — set in days under Admin → Data retention. A nightly job deletes transcripts older than the window. If no window is set, transcripts are kept until deleted.
  • On-demand deletion — administrators can delete transcripts for one case, older than a chosen age, or all at once, with a preview of how many will be removed. A request concerning one student's conversation is handled by deleting that case's transcripts.
  • End of a trial — unless the institution subscribes, we delete its content within 30 days after the trial ends, and confirm in writing on request.
  • Leaving the service — offboarding deletes the institution's cases, links, transcripts, AI key, and organization. Agreement acceptance records are retained as the legal record of the relationship.
10
Chapter Ten

Trials, Pilots & Contracts

An evaluation first, then a subscription for classroom use.

From evaluation to subscription On day 0 an administrator accepts the Evaluation Agreement online. A 90-day evaluation follows, with test data only. At day 90 the institution either subscribes, under a subscription agreement and Data Processing Agreement, for classroom use with students, or does not, in which case access ends and content is deleted within 30 days. 90-day evaluation · test data only Day 0 · administrator accepts the Evaluation Agreement online Day 90 Subscribe Classroom use with students Subscription agreement + DPA No subscription Access ends at day 90 Content deleted within 30 days
Figure 8The evaluation runs on test data only. Without a subscription, access ends at day 90 and your content is deleted within 30 days.
90-day evaluationSubscription
PurposeFaculty and staff evaluate the productUse in courses with enrolled students
DataTest data only — no student personal data, no enrolled students, no graded useStudent use as described in this guide
TermsEvaluation Agreement, accepted online by an administratorSubscription agreement with a Data Processing Agreement
LimitsCapped number of active cases; access ends when the window closesPer your plan

Subscription pricing is set out in Exhibit A of the Evaluation Agreement.

11
Chapter Eleven

Privacy & Compliance Posture

Built to keep student identity out of the system entirely.

The platform authenticates no students and collects no verified student identity, and conversations are not linked to grades or institutional records. That design, and the boundary it depends on, are described in our Data Handling & Privacy notice. Your institution's privacy office should review it against its own FERPA and data-protection analysis.

Data is hosted in the United States. Institutions outside the US should note this when assessing cross-border transfer.

Attestations

We do not currently hold SOC 2 or ISO 27001 certification, and have not completed a HECVAT, VPAT, or third-party penetration test.

12
Chapter Twelve

Integration & Network

  • No LMS integration. There is no LTI, roster sync, SSO, or grade passback. Instructors post the case link wherever they share course materials.
  • Browser. A current web browser with JavaScript enabled. Nothing to install.
  • Network allowlisting. Allow casebuilder.studio and the Clerk sign-in service used on staff pages. Administrators handling billing also reach Stripe. AI providers are contacted from our servers, not from campus devices.
  • Your AI provider account must permit API use with the models your administrator selects.
13
Chapter Thirteen

Support & Security Contact

One address for questions, support, and security reports.

Email john.biske@support-savvy.com for support, for questions from your review, or to report a suspected security issue. Incident-notification terms for subscribing institutions are set out in the Data Processing Agreement.

Related documents: Data Handling & Privacy · Sub-processors · Evaluation Agreement · User Guide.