JRC internal portal
A calmer front door into the internal tools that keep JRC running.
The public site should tell the story clearly. The portal should do the opposite of storytelling: it should get approved people to the right operational tool, quickly, with less confusion and less noise.
This public shell is the future launcher. Once Cloudflare Access is attached, it becomes the calmer front door into the internal Apps Script tools.
Active launchers
The portal should expose only the internal tools people actually need.
These cards are the durable internal routes: project update, intake, and admin surfaces that belong behind a login rather than on the public website.
Project Update
The primary weekly workflow for project status, student progress, and new-project requests. This remains the operational bridge into Judd Project Manager.
PI Intake
Collects PI/team details, staffing needs, reviewer preferences, and lab metadata so Team Directory can stay structured without extra manual cleanup.
Student Intake
Operational intake for onboarding, contact preferences, recognition settings, and restricted demographic routing into Sensitive Information.
Admin Controls
Configuration, repair helpers, and the operational backstops that keep the platform stable once the public and internal routes are live.
How access will work
Portal access should match real operational access.
The cleanest model is to treat the JRC folder-access group as the portal-access group too. That way Google login, Drive access, and Cloudflare entry all point to the same underlying membership decision.
- Cloudflare Access will become the first gate: Google login required.
- Membership will mirror the JRC folder access group so portal access and Drive access stay aligned.
- The launcher will route into Apps Script until the internal tools are worth rebuilding natively.
What this launcher is for
Keep internal work legible.
- Project update and project lifecycle coordination
- PI intake and leadership-facing operational setup
- Student intake routing after admissions
- Admin and repair helpers that should never live on the public site
What this launcher is not for
Do not turn the portal into the public website.
- It should not explain the whole mission from scratch.
- It should not expose protected workflows to the general public.
- It should not replace Google-backed operations until the backend is ready.
- It should feel lighter and more utilitarian than the marketing site.
Upcoming portal surfaces
Visible placeholders for the next layer of internal resources.
These pages intentionally exist as starred placeholders so the architecture can grow without pretending unfinished work is already live.
*Research Guide
A shared orientation library for methods, communication norms, and research readiness.
*Student Hub
A future student-facing home for milestones, office hours, and routine operating resources.
*Leadership Hub
An internal command center for coordination, reporting, and cross-team planning.
*Lab Lead Hub
A practical space for lab leads to manage onboarding, review cycles, and team expectations.
*Onboarding
A more complete onboarding surface for policies, acknowledgments, and first-week guidance.
*Internal Review
A structured place for review workflows, revision checkpoints, and manuscript coordination.
*Meeting Playbooks
Reusable agendas, prep lists, and decision frameworks for recurring JRC meetings.