Render
Case study · AI Tools & Strategy · Learning Design
A student-facing AI career-readiness environment students build across the capstone, and keep after they graduate.
1. Summary
Creative students graduate with strong portfolios and no plan for using them. Canvas access ends at graduation, taking their coursework with it.
Render is a personal learning environment: a student-facing AI career space populated during AVC 248 (Design Self Promotion at the college) and owned by the student afterward. Students do not face a blank AI prompt. They work inside a structured environment anchored to one real reach job they choose on day one.
By graduation a student leaves with a populated career launchpad (goals, saved jobs, resume drafts, a job log with cover letters, a skills gap analysis, networking contacts, interview practice, a weekly schedule, and a 90-day plan), exported as a downloadable package they own: a dashboard, a job tracker, their tailored documents, and their agents and skills as prompt files that run in their own AI tool.
Render does not get replaced by the agent. Render builds the agent.
How the AI runs, August 2026. Students use their own Google Gemini accounts. Each section supplies the prompt, the student runs it in their own account, and the result comes back into Render. There is no shared key, no district proxy, and no institutional AI account to provision, so the tool runs on its own schedule rather than on an approval queue. Student data stays in the browser, which keeps the no-PII design intact.
1.1 Build status
So this reads honestly: Render’s interface is built and its AI steps are written, and students run them in their own Gemini accounts. Here is the exact state.
| Component | Status |
|---|---|
| The interface and all data panels (profile, goals, job and client log, resume vault, skills, networking, interview prep, launch plan, export) | Built and working. |
| The AI skills (about twenty prompts, one per section) | Built and in use. Each section hands the student a ready prompt to run in their own Gemini account. |
| How the AI runs, student-owned Gemini accounts | In use for the Fall 2026 pilot. No shared key, no proxy, and nothing to provision, so the pilot is not gated on anyone else’s timeline. |
| Login and storage | First name only, no PII, stored in the browser. Nothing to approve. |
| The agents (career counselor, hiring committee, interview panel, the student’s job-search agent) and the added skills in section 4.8 | In progress. A working prototype of the panels exists; integration into the tool follows. |
| Hosting | Live and running. A move to a district GitHub organization is a post-pilot option, not a prerequisite. |
2. Goal
A career environment that outlasts the course. The pedagogy is connectivism: a personal learning environment is a space the learner owns where goals, work, skills, and connections live together and keep developing. The export is not an archive, it is a dashboard students keep updating.
2.1 The learning environment to agent arc
| Stage | What happens in Render |
|---|---|
| Day one | The student sets goals, guided by targeted questions, and picks one real reach job as their anchor. Every later module aligns to it. |
| All semester | Render runs alongside the capstone: profile, goals, job log, resume vault, skills tracker, networking, interview prep. |
| Capstone | Render analyzes the gap between what the student built and what the reach job requires, then generates a portable learning plan and career agent. |
| Take with you | The student keeps Render (data and dashboard, exportable) and the agent, which runs in any AI tool. |
2.2 Assessment model
Formative all semester: every saved job refreshes a running read of where the student needs to tool up, and the gap analysis, tailoring iterations, interview coaching, instructor feedback, and Diagnose Your Search feed low-stakes signals while there is time to act. Summative at the capstone: that evidence becomes the learning plan and portable agent. Formative again afterward: the Training Plan Agent runs a weekly loop and promotes a skill onto the resume once it is demonstrated.
2.3 Two-product architecture
| Product | Purpose | Status |
|---|---|---|
| In-class gathering interface | Structured data-entry tool used during AVC 248, populated week by week. AI assists with analysis, cover letters, search strings, and coaching. | Built |
| Post-graduation dashboard and career agent | A persistent, updatable dashboard exported from the first product, plus the portable agent and learning plan. Four themes, no login. Students own both. | Built |
2.4 Agents and skills
Render is built from two kinds of parts, and the course teaches the difference. A skill is a single focused job: input in, a useful result out, one step (tailor a resume to a posting, draft a cover letter, score a gap). An agent is a role or an orchestrator: it plays a persona, coordinates several skills and personas into one experience, or runs on its own over time. Render’s AI functions are skills. On top of them sit a few agents: a career counselor that guides the whole journey, a hiring committee and an interview panel that each run a set of named role personas, and the student’s own job-search agent that they build and take with them. Students are told on day one that they are building agents and skills, that Render is training wheels, and that at the end they leave with the agents and skills themselves, exported to run in their own AI tool, plus the understanding to build more.
3. Users and context
| User | Context | Needs from Render |
|---|---|---|
| Digital Media Arts students | Finishing AVC 248. Portfolios done. Seeking employment, freelance clients, or both. | Structured guidance, not blank prompts. |
| Animation students | Targeting studios, production companies, streaming platforms. Reel is the primary job-search tool. | Reel link prominent. Industry-specific job analysis. Animation software tracking. |
| Photography students | Commercial and fine art. Client-finding as relevant as job-searching. | Freelance client track. Commercial versus editorial distinction. |
| Film and media students | Agencies, corporate video, broadcast, or a freelance production company. | Both tracks. Reel and portfolio. Spec sheet and contract templates. |
| UX design students | Pursuing employment at tech companies. Case-study portfolio is critical. | Job-search focus. Case-study links. UX-specific gap analysis. |
| Instructor | Runs AVC 248, about 24 students. | Instructor settings panel. Career Services pipeline. No FERPA-sensitive data transmitted. |
| Career Services | Wants employer intelligence to build internship pipelines. | Anonymous aggregated data: employer names, job titles, program areas. No student names or MEIDs. |
- Course: AVC 248 Design Self Promotion, 15 weeks, online, asynchronous, roughly 24 students per section.
- Canvas access ends after graduation, so Render must be self-contained after export.
- Student devices are a mix of Mac, Windows, and mobile, so the tool is device-agnostic.
4. How it works
The interface and data panels below are built. The AI steps are written as prompts students run in their own Gemini accounts (see the build status in 1.1). The items marked “planned, building now” are the agents in 4.7 and the added skills in 4.8. Each subsection notes when the capability is used across the 15-week semester.
4.1 AI literacy unit
Weeks 1 to 2
A prerequisite, not an introduction. The Tailor flow is locked until it is complete.
- How a model produces text. Next-token prediction, why fluency is not evidence. Students run a prompt designed to elicit a fabrication, then verify it.
- Prompting as specification. Role, task, format, context, constraint. Students compare a weak and a strong prompt on the same model.
- Verification and disclosure. What must be checked before it enters an application (every employer, date, metric, skill claimed), and how to disclose AI use to an employer who asks.
- Bias, privacy, and the labor question. What a model was trained on, what a vendor does with a prompt, and how applicant tracking systems read a student’s materials first.
- Where a model is the wrong instrument. Original voice, situated judgment, anything that must be true. This is what makes the base materials rule intelligible.
Assessment: a short AI use policy the student writes for themselves, stating where they will and will not use a model in their own job search. Graded on the reasoning, not the position.
4.2 The job search loop
Weeks 1 to 15
The home view frames the tool as one repeatable 10-stage system: target, build base materials by hand, find roles, then per job research, tailor, iterate, apply, and log, then follow up, network, prep for interviews, track the pipeline, and diagnose. The student keeps running the loop after graduation with the exported dashboard and agent.
Diagnose Your Search is a rules-based funnel diagnosis. It reads logged activity (applications sent, responses, interviews) and names where the search is stalling and what to change, with an optional AI deeper dive. Every data-entry section opens with directions, so students never face a blank field.
4.3 Profile, goals, links hub, search strings
Weeks 1 to 3
A guided goals builder walks the student through targeted questions (role, industry, setting, location, day-to-day work, timeline, values, pay range) and assembles a specific goals statement. The student picks one real reach job as the anchor for every later module and for the capstone gap analysis.
The profile captures program, employment and freelance tracks (both can be active), weekly commitment sliders, a links hub (LinkedIn, Behance, portfolio, reel, Instagram, GitHub), dream job or client, target market, and a 3-year vision. The current build also has an AI search-string generator (ready-to-paste strings for LinkedIn, Indeed, Glassdoor, and Google), but it is being replaced by the student’s job-search agent (section 4.7), which does far more than produce strings: it takes the resume and goals and actively finds and verifies live roles. Search strings remain only as a simple fallback.
4.4 Job log, base materials, tailoring, and critical AI review
Weeks 2 to 13
On the employment tab, students paste a job description and get an AI skills gap analysis and a cover letter draft, tracked through a status pipeline (saved, applied, interview, offer or pass), with the description, resume edits, and cover letter stored together. On the freelance tab, students describe an ideal client type and AI returns search strategies, 8 to 10 real prospect names, outreach guidance, and a pricing check. On save, Render tells the student what goes to Career Services and why (section 5).
The resume vault holds base resume drafts (first through fourth) and a base cover letter, with instructor feedback fields and an active resume flag. The base materials rule is hard: the first resume and first cover letter are written by the student, by hand, with no AI and no template, then pasted in. The Tailor flow refuses to run until both exist. Resume drafts carry no name, address, or phone number; students add contact details to the version they send.
The Tailor flow shows the job-match read (skills match, gaps, positioning, red flags), then takes the job description plus the active base resume plus the base cover letter and produces tailored first drafts of both, in the student’s voice, plain text only. An iteration loop lets the student re-prompt by naming what to change, and a reflection field captures what they edited. A critical AI review checklist renders under every AI output: accuracy, voice, proof, format, and fit to the specific job. Students never submit a first AI draft.
4.5 Skills, networking, interviews, and application support
Weeks 5 to 14
A software stack checklist by program covers 6 categories and roughly 60 tools. Students build a skills-to-build list by hand or pull gaps from saved job entries via AI. Gap analysis surfaces professional skills and industry workflows (project management, client presentations, creative briefs, production planning, budget management) alongside software, then names free learning resources. A portfolio project idea generator and a professional development log complete the section. This is the formative engine from section 2.2.
A contact log with type tagging (mentor, employer, peer, alumni, industry) and outreach status. AI drafts LinkedIn connection requests under 300 characters, with a redraft option per contact.
Interview prep generates role-specific questions from saved job descriptions plus general questions by role type. Students practice answers and get AI coaching feedback (coach, not cheerleader), saved to a question and answer log. Big Interview is integrated for video practice. AI also drafts a thank-you or follow-up note in the student’s voice, with timing guidance.
Support materials: a references sheet builder matching the student’s resume styling, an online presence audit covering what an employer sees when they search for the student, and a salary research helper covering BLS, Glassdoor, Levels.fyi, and Built In and how to answer the salary question with a researched range.
4.6 Launch plan and career agent, the capstone export
Week 15
Render analyzes the gap between everything the student built and the requirements of their day-one reach job, then generates a career agent and personal learning plan as a Markdown file that runs in any AI tool.
A companion Training Plan Agent sequences the gaps from real saved jobs into a 90-day learning plan, mapping each gap to a specific low-cost resource (named YouTube channels, Coursera and Adobe courses, freeCodeCamp, the AVC 248 AI unit). It runs on a weekly loop after graduation, promoting each skill onto the resume once it is demonstrated.
An AI weekly schedule builder generates a Monday to Sunday time-blocked schedule from committed hours, goals, gaps, and job targets, with a Sunday review block.
The export is a single downloadable package (a zip) the student owns and keeps. It contains: a self-contained HTML dashboard (four color themes, opens in any browser with no login or software) carrying goals, the job-search agent, links, the mentor list, the skills map with gaps and resources, the professional development plan, the 90-day plan, the weekly schedule, and semester stats; a spreadsheet job tracker (their living record of what they applied for, with the job description, status, and mentor contacts); their real application documents (each tailored resume and cover letter as an editable file plus a ready-to-send PDF, filed with its job description); and their agents and skills as clearly labeled prompt files with a one-page plain-English readme showing how to paste each one into their own ChatGPT, Claude, or other AI tool. The Render editing interface does not have to live on; this package does.
4.7 The agents: career counselor, hiring committee, interview panel, and the student’s job-search agent
Planned, building now
These agents are never generic, and they are not the same for every student. They are shaped by the individual student’s goals, which is what guides that student toward the right jobs to research and save in the first place. Each committee and each interview is then built from one specific saved posting. Two students never get the same committee or the same interview, because both are instantiated from that student’s own goals and the exact job in front of them, grounded only in that posting’s real requirements. Nothing here runs until the student has real target jobs saved in the job log, and the committee and interview attach to each saved job rather than existing on their own.
Career counselor. The orchestrating agent that guides the whole experience. It meets the student wherever they are, seeking a job or going freelance full time, keeps them on track by saving resumes and job descriptions and running the goals questions, and helps them build the two things they take with them: their own job-search agent and a path to a real mentor. Finding a mentor is a guided question flow that identifies real avenues to look, because the mentor is a real person, not an AI (this serves competency 4 and the Module 5 and 6 mentor work).
Hiring committee. A panel of named role personas, each with a department and a lens: an HR specialist, the hiring manager for the job, a peer who does the same job, and a peer in the department doing a different job. Each scores the student’s application against the specific pasted posting on a rubric. An orchestrator returns one report: the rubric scoring, an interview-likelihood band (Reach, Possible, Strong), and a roadmap of what the student would need to do to land a job like this. Grounded only in the posting, coaching in tone, never “you will not get in.”
Interview panel. Once the student clears the committee, the same named personas interview them one question at a time, rotating and introducing themselves by name and department. Eight questions: open with “tell me about yourself” and “why are you a good fit,” about six drawn from the posting’s minimum qualifications and work-culture cues, and close with “do you have any questions for me.” An orchestrator runs the experience and coaches afterward (this deepens competency 7 and the Module 7 mock interview).
The student’s job-search agent. This replaces the old search-string helper. Rather than Render running the search itself, which would need a server that runs on a schedule with open web access, Render writes the agent for the student. It takes their resume (or master resume), goals statement, and the kinds of jobs they want, and assembles a ready-to-run agent, the full directions plus the student’s own parameters, that the student pastes into their own Gemini. Gemini then does the work in the student’s hands: it scours widely on keywords and other signals across job boards and company career pages, and, importantly, verifies each posting is still live on the employer’s own careers page before listing it, so the student is not chasing dead links or aggregator reposts. The results come back as a job feed the student reviews and pulls into their job log, where the hiring committee and interview attach. Because the agent runs in the student’s own AI, it is truly theirs and keeps working after graduation, and Render needs no backend to make it go. A fully automated weekly feed that runs itself inside Render is possible later, but that version needs a server-side worker and is not part of the pilot.
Master resume. The resume vault evolves toward one long master document the student keeps adding to, like a CV, then draws down from to align to each specific job, the way a working professional tailors from a master.
4.8 Skills to add (from the competitive scan and the course competencies)
Reviewing Render against the competitor tools and the eight AVC 248 competencies surfaced a few skills worth adding so the tool fully covers what students are taught:
- Elevator pitch. Helps the student build and refine a short self-introduction, feeding both the Module 3 elevator-pitch assignment and the interview panel’s opening “tell me about yourself.”
- LinkedIn profile builder. Beyond the existing online-presence audit and connection-message drafts, a skill that helps optimize the actual LinkedIn profile (headline, about, experience), matching Module 6 and competency 4. Competitor tools score LinkedIn; students are taught it, so Render should let them practice it.
- Freelance contract and spec-sheet coach. Walks a freelance-track student through the points of discussion for a client contract and a spec sheet, directly serving competency 6 and the Module 5 Project Brief with Contract, and deepening the freelance track.
- Explicit application match check. The Tailor flow already tailors to a posting’s keywords; a clear, readable match read (met, partly met, missing against the posting) gives students the ATS-style signal the commercial tools sell, taught here as a coaching moment rather than a black-box score.
Scope note: the design deliverables in the competencies (business card, identity package, leave-behind) are studio production work students make in their design tools, not AI functions, so Render supports them through the portfolio review rather than generating them.
5. Data, privacy, and governance
Render collects no personally identifiable information. No name, no email, no student ID, no address, no phone number. Students sign in with an anonymous handle, and no PII enters any AI call: every AI feature runs on the student’s anonymous profile, goals, and pasted job descriptions.
5.1 Login and data storage
The prototype stored data in browser localStorage, which loses a student’s work if the cache is cleared or a shared lab machine is wiped. That model is retired. Student work is stored on a server so it survives any machine, and the API key never sits in the browser. Grading runs entirely through Canvas submissions; the instructor never opens a student’s Render, so the tool never needs to identify a student for grading. Two login models are documented; the anonymous handle is what the Fall 2026 pilot runs on:
- Option A, anonymous handle. This is what the pilot uses, and it is truly no-PII. The student signs in with an invented handle and a PIN, never a name or email. Work is stored in a small backend keyed to the handle; the system cannot connect the handle to a real person, and resume content already carries no direct identifiers. This keeps the strict no-PII posture and makes the tool outlast the college account, since it is not tied to a district login that is deprovisioned at graduation. Its one cost is that a forgotten handle cannot be recovered, which is low-stakes here because grades live in Canvas, not Render.
- Option B, district Google sign-in (identified but protected). The student signs in with their district Google account. Work saves under their identity inside the district Google tenant, covered by the district agreement and not used for training. Smoothest experience, but it is not no-PII, and the account and the student’s work are deprovisioned when they leave the college, which undercuts the outlast-the-semester goal.
Either way the backend stores only the student’s own career content, no PII is sent to the AI, and nothing is used for training (section 6). Auto-save runs during the session, and the student can export the full package (section 4.6) at any time.
5.2 FERPA
| Data type | Where it goes | Status |
|---|---|---|
| Login handle, goals, job history, resume text (no contact info) | Stored in the student’s browser, exportable by the student at any time | Never sent anywhere by the tool; no PII |
| Employer name, job title, URL, interest level, program area | Google Sheet via Apps Script (Career Services pipeline) | No student identifiers |
| Full data export (JSON) | The student’s own Google Drive | Student owns the data |
| Future: full cloud sync | district Google infrastructure or a school server | Requires a FERPA agreement, not yet implemented |
5.3 Career Services pipeline
Saving an employment job entry sends one anonymous row to a Google Sheet via Apps Script: date, employer name, job title, job URL, interest level, program area. Career Services uses it to identify companies students target, build employer relationships, and pursue internship and placement opportunities. Students are told this at the moment they save an entry.
6. Build and portability
6.1 Current stack
- Frontend: a single HTML file, vanilla JavaScript and CSS, no framework.
- Authentication: an anonymous handle plus PIN. No PII.
- Persistence: a small server-side backend (for example Supabase), owned by a district or department account, keyed to the login. Browser-only storage is retired.
- AI: students run each section’s prompt in their own Google Gemini account. No shared key exists, so there is nothing to secure in the browser and nothing to provision. Gemini output quality was tested and approved August 10, 2026, and the prompts are model-agnostic, so a student on another AI tool is not blocked.
- Career Services pipeline: a Google Apps Script web app (POST endpoint, no-cors mode), moving to a department account.
- Hosting: static frontend on GitHub Pages. A move to a district-owned organization is a post-pilot option.
- Export: a downloadable zip package the student owns (section 4.6).
6.2 Running on district infrastructure
Nothing about Render requires district infrastructure to run. The AI runs in each student’s own Gemini account, so there is no key, no proxy, and no institutional AI account in the path. The static frontend can be served from any web host. The changes below are portability improvements available whenever the district wants them, not prerequisites for the pilot.
| Change required | Why | Scope |
|---|---|---|
| Host the frontend on a district GitHub organization | District student traffic should sit under district control, not a personal account. | Repo move, no code change. |
| Stand up the login and storage backend | Browser storage loses work on a wiped machine; a backend keeps each student’s work safe and follows them across devices. Students export their package in the meantime. | New build, post-pilot. |
| Move the Apps Script endpoint to a department account | The pipeline currently runs on a personal account. | Account transfer, no code change. |
6.3 Model portability, and moving from Claude to Gemini
Render’s prototype was built on the Anthropic Claude API, and the pilot runs on Google Gemini, the district standard. That is a solvable mismatch by design, not a rebuild. Every AI call in Render runs through a single request function, so moving the whole tool to Gemini means changing three things in one place: the endpoint, the authorization header, and the shape the response is parsed from. Prompts are plain text with no vendor-specific features, and outputs are plain text rather than structured tool calls, so nothing in the functions is tied to a particular model.
The practical plan, decided August 2026: students run each section’s prompt in their own Google Gemini account, since the district is standardizing on Gemini and every student already has access. Gemini was tested against Render’s coaching and fit-report prompts on August 10, 2026 and passed. Because no shared key exists, there is nothing to secure in the browser, nothing to provision, and no per-class spend to manage. The prompts are plain text with no vendor-specific features, so a student working in a different AI tool gets comparable results.
What to re-test on a swap: output quality on the longer reasoning prompts (skills gap, tailoring, diagnosis), which are the most sensitive to model capability, and the token budget on the tailoring call, which sends a full job description plus a base resume plus a base cover letter. The privacy posture does not change with the model, because no personally identifiable information is sent to any of them. This is the same provider-agnostic pattern used across the portfolio, so a Gemini migration here is the template for the others.
6.4 Cost and access
Render costs the department nothing to run. There is no API key, no metered usage, no proxy to host, and no budget line. Students run each section’s prompt in the Gemini account they already have, which is the same access they use across their other coursework.
What the pilot needs, all of it inside the course:
- Gemini access confirmed for every student in week 1, verified alongside the other tool logins the course already checks.
- A short AI-literacy unit in weeks 1 to 2, which the course already includes (section 4.1).
- The prompt library, one prompt per section, written and in the tool.
The no-PII posture is unchanged and is stronger under this model, not weaker: no name, address, phone, or email enters Render, and nothing about a student is transmitted to an institutional account, because there is no institutional account in the path.
6.5 AI functions
The AI functions below (about twenty today, more as the skills in 4.8 are added) all route through the single request function named in 6.3. Every call includes the student’s anonymous profile and goals as context.
| Function | Input | Output |
|---|---|---|
| analyzeWithAI | Profile, goals, job description | Skills match, gaps, positioning advice, red flags |
| generateCoverLetter | Profile, job description, analysis | Tailored 3-paragraph cover letter |
| sendToSheet | Job description (up to 1500 characters) | 2 to 3 sentence summary for the Career Services sheet |
| getResumeEdits | Active resume, job description | Specific resume edits for this job |
| pullGapsFromJobs | Saved job descriptions (up to 6) | 8 to 12 skills: software, professional, workflows |
| getRecommendations | Profile, skills gap list | Named free learning resources |
| getProjectIdeas | Profile, targets, gaps | 5 portfolio project ideas with time estimates |
| draftLinkedInMessage | Contact info, notes | Connection request under 300 characters |
| redraftMessage | Contact, previous message | Fresh message for an existing contact |
| generateInterviewQuestions | Profile, job description | 10 role-specific questions |
| generateGeneralQuestions | Profile, role type | 8 questions for any creative role |
| getFeedback | Question, student answer | What is working, what to improve, a stronger version |
| generatePDPlan | All student data, hours, focus | Personalized 90-day plan |
| generateSearchStrings | Goals, dream job, market | Copy-paste strings for LinkedIn, Indeed, Glassdoor, Google |
| buildWeeklySchedule | Hours, goals, gaps, targets | Monday to Sunday time-blocked schedule |
| generateCareerAgent | All student data, day-one goals, reach job | Portable career agent and learning plan (Markdown) |
| tailorApplication | Job description, base resume, base cover letter, match read | Tailored first drafts in the student’s voice, plain text |
| generateThankYou | Job, interview or application context | Thank-you or follow-up note with timing guidance |
| researchSalary | Role, market | Realistic pay range and how to state expectations |
| diagnoseSearch | Logged funnel activity | Deeper read on where the search is stalling |
7. Pilot and testing
Usability testing ran in March and April 2026 with 4 students, using think-aloud sessions on the core flows: setting goals on day one, saving a real job, running the gap analysis, and tailoring an application against hand-written base materials. Career Services feedback is ongoing, focused on whether the anonymous employer rows are useful for building internship pipelines.
Render is written into the AVC 248 course competencies, so the pilot is not an add-on. The Fall 2026 pilot is one full semester with a live section of roughly 24 students, week 1 through the week 15 capstone export.
What the pilot measures: whether students complete the AI literacy unit before the Tailor flow unlocks, whether the base materials rule holds, whether saved job entries accumulate enough data for the capstone gap analysis to be meaningful, whether the exported dashboard works on a student device after the semester ends, and whether Career Services receives usable employer data.
7.1 How the pilot runs, step by step
A pilot is not “try it and see.” It is a small, bounded test with the questions and the yardstick set before anyone logs in, so the result can actually be trusted. This is the sequence, and it is the same shape every tool in this portfolio uses.
- Frame the question first. Name the one or two things the pilot has to answer (here: does the environment produce a real, populated career plan a student keeps, and does the base-materials-plus-review structure keep students from submitting first AI drafts). Everything measured traces back to a question; anything that does not is noise.
- Set a baseline. Decide what “better” is measured against before the semester starts. For Render that is the prior norm: students finishing the capstone with a portfolio and no plan, and no artifact after Canvas closes. A short start-of-term readiness self-rating gives a pre-point to compare the exit against.
- Choose the cohort and get consent. One live AVC 248 section, roughly 24 students, is the whole pilot, not an add-on, because Render is written into the course competencies. Students are told at entry what is collected (a first name, anonymous employer rows to Career Services) and why, which is the consent step, not a checkbox afterward.
- Instrument lightly, at fixed checkpoints. Because the tool stores no telemetry by design, evidence comes from three planned touchpoints: setup (week 1 to 2), midpoint (week 8), and the capstone (week 15). At each, capture a short survey plus a look at the actual artifacts (saved jobs, hand-written base materials, the export). Measure the behaviors from 7, not satisfaction.
- Run one full semester without moving the target. Fix only what is broken during the run; save redesign ideas for after. Changing the intervention mid-pilot means you can no longer tell what produced the result.
- Analyze against the baseline, then decide keep, iterate, or kill. Compare exit evidence to the baseline and the success thresholds in section 8. Be willing to conclude it did not work: if students will not maintain the environment or the base-materials rule collapses in practice, that is a finding, not a failure, and it changes the next build.
8. Definition of success
Version 1.0 means Render has passed the Fall 2026 pilot and is cleared for production use, which requires all of the following.
- Students finish with a populated environment: real goals, a real reach job, real saved jobs, hand-written base materials, and a capstone export.
- The exported dashboard and career agent open and run on a student device after Canvas access ends.
- Students report the tool told them what to do next rather than handing them a blank prompt.
- The base materials rule and the critical AI review checklist hold in practice, so no student submits a first AI draft.
- Career Services can act on the anonymous employer data, with at least one employer relationship or internship conversation traceable to it.
- Nothing beyond a first name is stored, and nothing identifying reaches AI or the Google Sheet.
- The Career Services endpoint is owned by a department account.
Anything short of that keeps the tool labeled a prototype.
9. Rollout
- Summer 2026, production hardening. Write the per-section prompt library, move the Apps Script endpoint to a department account, finish the instructor settings panel, act on usability findings.
- Fall 2026, the AVC 248 pilot. One section, roughly 24 students, full semester, with feedback at the midpoint and at the capstone.
- Winter 2026 to 2027, revision. Fix what the pilot exposed, then decide what wider use needs.
- Spring 2027, expansion inside the college. Offer Render to the other digital media programs, then to other career-oriented programs at the college. The architecture is already program-agnostic.
- Beyond, district conversation. Bring a tested tool with real pilot data to the district, and extend it beyond digital media to other disciplines whose students enter the workforce (business, information technology, allied health, trades and career-technical programs, and the liberal arts), rather than pitching a prototype.
10. Open questions and risks
| Question or risk | Priority | Notes |
|---|---|---|
| Do all students have working Gemini access on day one? | High | Verified in week 1 alongside the other tool logins, the same way every other platform in the course is checked. |
| Consistency of output when every student runs the prompt in their own account. | Medium | Prompts are written to be self-contained, so results vary in wording rather than in structure. Worth watching across the pilot. |
| Model dependence. A single vendor sits under 20 features. | Medium | Prompts are model-agnostic and run in any capable AI tool, so a student on a different tool is not blocked. |
| Should the tool be shared across the district or stay college-specific? | Medium | The architecture is already abstracted. District deployment is viable after the pilot. |
| Does Career Services want to manage the Google Sheet, or just receive a report? | Medium | Determines how the pipeline is structured and whether notifications are needed. |
| Should there be an instructor view showing class-wide progress? | Low | Useful for grading, but it would require explicit student consent for FERPA compliance. |
11. Roadmap
| Milestone | Target | Notes |
|---|---|---|
| Full tool built | June 2026 | Profile, goals, search strings, job and client log, resume vault, skills and professional development, networking, interview prep, launch plan, the Tailor flow, the base materials rule, the critical AI review checklist, references sheet, online presence audit, salary research, Diagnose Your Search, and the export with 4 themes. |
| Usability testing | March to April 2026 | 4 students. Career Services feedback ongoing. |
| Production hardening | Summer to Fall 2026 | Prompt library per section, department-owned Apps Script endpoint, instructor settings panel. |
| Pilot, AVC 248 | Fall 2026 | First full semester with live students. Running. |
| Agents and skills build | Fall 2026 onward | The hiring committee, interview panel, career counselor, the student job-search agent, the added skills in 4.8, the master-resume model, and the zip Export Skills package. |
| Google Drive auto-sync | Post-pilot | Cross-device data transfer without manual export and import. |
| Industry news feed | Post-pilot | Curated RSS per program track, roughly 8 to 12 sources each, using the Cultivate architecture. |
| District adaptation | Post-pilot | Deployment across the district, starting with digital media programs and extending to other disciplines that prepare students for work, business, information technology, allied health, trades and career-technical programs, and the liberal arts, since career readiness and the no-PII design are program-agnostic. |
Key references
- Render tool: singletrackmom.github.io/render/
- Render overview: singletrackmom.github.io/render/overview.html
- Training Plan Agent (prototype): singletrackmom.github.io/render/training-plan-agent.html
- Sample exported dashboard: singletrackmom.github.io/render/sample-dashboard.html
- AVC 248 course site: singletrackmom.github.io/canvas/avc248/
- Big Interview: www.biginterview.com
- Career Services: gccaz.edu/student-life/career-services