Deployment Guide: From Prototype to GCC Pilot

01. Pilot Scope

The pilot is a single-college deployment at GCC, intentionally bounded in size so that operational issues surface before they scale. Specifically:

• One college. GCC main campus and North campus. Other Maricopa colleges are out of scope until pilot evidence informs the district decision.
• One semester. Fall 2026 is the target pilot window. Soft launch in the first two weeks of the semester, full availability for the rest of the term.
• Phased department rollout. Advising, Financial Aid, DRS, Counseling, Tutoring, GCC Cares, Library, Veterans, and Career Services in the initial deployment. Other departments added as their content gets verified.
• Real students, not test users. The pilot is open to any GCC student, no special enrollment, no opt-in barrier. Discoverability is part of what’s being tested.
• Anonymous-first preserved. No login is added for the pilot. The architectural property that makes CopaMigo distinct (no student identity collected) holds during the pilot exactly as it holds in the prototype.

02. Pre-Launch Checklist

The following items must be in place before any student can interact with the pilot. Each is described in detail in later sections of this document.

Infrastructure and architecture

• AWS account access for the project, with appropriate IAM roles for engineering and operations
• AWS Bedrock model access for Claude (current production model family) provisioned and tested
• Application server deployed (Node.js or Python on AWS Lambda, ECS Fargate, or Elastic Beanstalk)
• API key management in AWS Secrets Manager, never in client code
• Production domain registered (e.g. copamigo.gccaz.edu) with TLS certificate via ACM
• CDN / static asset hosting via CloudFront for the frontend HTML, CSS, JS
• Anonymous request logging to CloudWatch with no student-identifying fields
• Rate limiting in place (per-IP and global) to prevent abuse and cost overrun

Knowledge base and content

• Verified system prompt with all 19 service modules and current contact info
• Department sign-off from each represented office on their card content (advising, financial aid, DRS, counseling, tutoring, GCC Cares, library, career, veterans)
• Advisor-submitted course data for any program where Phase 2 advising features are turned on (default: stays in Phase 1, checksheet only)
• Crisis routing reviewed by GCC Counseling and district legal counsel
• Title IX routing reviewed by district Title IX coordinator

Compliance and accessibility

• WCAG 2.1 Level AA audit completed by approved vendor with all blocking issues resolved
• Anthropic Data Processing Agreement signed institutionally (or AWS BAA if going through Bedrock)
• FERPA review with district legal counsel confirming the anonymous-first design satisfies obligations
• Maricopa CIO sign-off on the deployment architecture and pilot scope

Operational readiness

• Per-office chat staffing plan in place for the offices participating in Phase 2 (advising, GCC Cares, tutoring, financial aid)
• Incident response runbook with on-call rotation and escalation path
• Monitoring dashboards for traffic, error rates, AI response quality, and cost
• Pilot lead designated, a single person with operational ownership for the pilot window
• Communication plan for syllabus statement, faculty introduction, and student-facing rollout

03. Infrastructure Setup (AWS Bedrock Path)

AWS account and IAM

The pilot lives in a Maricopa-owned AWS account. New IAM roles needed at minimum:

• copamigo-app-role, used by the application server to call Bedrock and read secrets. Permissions: bedrock:InvokeModel for the specific Claude model ARN, secretsmanager:GetSecretValue for the application’s secrets, logs:PutLogEvents for CloudWatch.
• copamigo-deploy-role, used by CI/CD to deploy application code. Permissions scoped to the specific Lambda or ECS service.
• copamigo-admin-role, for engineering staff. Read access to logs, ability to rotate secrets, ability to update Bedrock model versions.

Bedrock model access

Claude models on Bedrock require explicit per-region enablement. The pilot should:

1. Choose a region (us-west-2 is the default for Bedrock + Claude availability)
2. Request model access in the AWS console for the specific Claude version that will be used in production. Pin the model version explicitly in application code; do not use “latest” pointers
3. Test the model with a representative system prompt and verify token usage matches expectations
4. Set CloudWatch billing alarms at expected and 2x-expected monthly token spend so cost overruns get caught early

Application hosting

For pilot scale (one college, single semester), the simplest viable hosting is AWS Lambda behind API Gateway:

• Frontend: Static HTML, CSS, JS served from S3 + CloudFront. No build step required for the prototype’s vanilla JS architecture.
• Backend: A single Lambda function (Node.js 20.x or Python 3.12) that receives the student’s question, calls Bedrock with the system prompt and conversation history, and returns the response. Stateless. No database for the application itself; localStorage on the client handles session continuity.
• API Gateway with a custom domain (copamigo.gccaz.edu/api) and a usage plan that enforces per-IP rate limits.
• CloudFront in front of both the static frontend and the API for consistent TLS termination and edge caching of static assets.

Secrets management

The application server needs the Bedrock API access to call Claude. AWS Secrets Manager holds anything sensitive; nothing lives in code or environment variables baked into the deployment artifact.

• Bedrock access: handled by the IAM role attached to the Lambda; no API key needs to be stored. This is one of the procurement advantages of Scenario B over a direct Anthropic API integration.
• Any third-party service keys (chat platform, analytics if added, error tracking) live in Secrets Manager with rotation enabled where the service supports it.

04. Application Architecture

The architectural shift between prototype and production is that the application becomes a server-side proxy. The student’s browser never holds an API key, never calls Bedrock directly, and never has access to the system prompt. This is a meaningful security improvement and is also what makes anonymous request logging, rate limiting, and cost control possible.

Request flow

1. Student types or speaks a question in the browser. Voice transcription happens client-side via Web Speech API (no audio is sent to the server).
2. The browser POSTs the conversation history (current and previous messages in this session) to copamigo.gccaz.edu/api/respond.
3. API Gateway applies rate limiting (per-IP and global). Excess requests return a polite throttling message.
4. The Lambda function adds the system prompt, calls Bedrock, receives the response, and returns it to the browser.
5. The browser renders the response (empathy message + service cards + linkified contact info).
6. A redacted log entry is written to CloudWatch: timestamp, query category (inferred from response routing), routing decision, response time, token count, and a hash of the IP for rate limiting. Not logged: the question text, the response text, any student-identifying information.

Anonymous logging principles

The logging design respects the data sovereignty position described in PRD Section 08b. The principle: log enough to operate the service, not enough to identify a student or reconstruct what they asked.

• Logged: timestamp, response category (which cards were shown), token count, response latency, hashed IP for rate limiting (rotated daily so the hash cannot be linked across days), success or error status, language detected.
• Not logged: raw question text, raw response text, IP addresses (only the hash), conversation history, any free-text fields.
• Aggregated for tuning: daily reports on which categories routed most, which questions failed (returned an error or a generic response), which language pairs appeared. These reports inform system prompt tuning and show department leaders where their content has gaps.

Rate limiting and abuse prevention

• Per-IP: 60 requests per hour per IP for normal traffic. Excess returns a friendly “you’re moving too fast, try again in a minute” message.
• Global: a daily token budget that, if exceeded, alerts the on-call engineer and degrades to a static “service is temporarily limited, please try again tomorrow or contact [office]” message.
• Prompt injection defense: Claude’s system prompt has explicit instructions about its role and refuses to engage with attempts to override it. Beyond model-level defense, the application doesn’t execute any code from user input and doesn’t expose anything sensitive that would be worth attacking.
• Content moderation: incoming requests are not pre-moderated; the model handles inappropriate content per its alignment training. Outgoing responses are spot-checked daily for the first month of the pilot via the aggregated logs.

05. Knowledge Base Maintenance Pipeline

The system prompt is the knowledge base. Updating it correctly is the single most important operational discipline of the pilot. The advisor-submission form (R-17) handles content collection from departments; this section describes how that content actually becomes part of the deployed bot.

The submission-to-deployment pipeline

06. Per-Office Chat Platform (Phase 2)

R-14 and PRD Section 07 describe the per-office chat fallback as the safety net. The prototype does not have this wired up; the pilot does. This section describes what the production chat layer requires.

Platform options to evaluate

• LibChat / LibAnswers (Springshare). Already in use at the GCC library; the contractual relationship exists, and the widget pattern can be replicated for other offices. Lowest friction. Cost is per-office license.
• Intercom or Zendesk Chat. Mainstream business chat platforms with strong administrative tooling. Higher cost but better admin experience for the staff receiving chats.
• Salesforce Service Cloud chat. If Maricopa is moving toward Salesforce more broadly, this is the natural integration point. Aligns with the hybrid architecture in PRD Section 08b Scenario E.
• Open-source self-hosted (e.g. Chatwoot). Lowest recurring cost, highest operational overhead. Probably wrong for a pilot.

Recommendation: start with LibAnswers for offices that already use it (library, ask-a-librarian) and extend to a single additional platform (likely Intercom or Zendesk) for the other participating offices. Keep the chat platform decision reversible during the pilot, multi-vendor for the pilot is acceptable; consolidation can happen post-pilot once volume and staffing patterns are known.

Per-office staffing and onboarding

Each participating office identifies the existing staff member who will receive chats. Most offices have an obvious person: the front-desk admin, the program coordinator, the social work intern who already triages walk-ins. Onboarding for that person is approximately 30 minutes and includes:

• How chats arrive in their queue alongside email and phone
• Expected response time during business hours (15 minutes target, 1 hour cap)
• What to do for after-hours chats (auto-reply directing to next-business-day response)
• Crisis escalation: if a student in the chat appears to be in crisis, the warm handoff path to counseling or 988
• How to flag a question that the bot got wrong, so the system prompt can be improved

Removing the prototype chat shim

The prototype includes a placeholder modal that fires when a student taps “Still stuck? Chat with this office” on any non-crisis card. The modal explains the chat is not yet live and tells the student to use the contact options on the card instead. This shim must come out before production launch, it would be confusing or alarming to a real student in a real deployment.

Specific cleanup in index.html:

• Delete the showPrototypeChatModal() JavaScript function
• Delete the .proto-modal-overlay, .proto-modal, and .proto-modal-close CSS rules
• Change the per-card chat button’s onclick from showPrototypeChatModal() to the production chat launcher for that office (e.g., LibAnswers widget URL, Intercom Intercom(‘show’), Zendesk zE(‘webWidget’, ‘open’), depending on platform)
• Leave shouldShowCardChat() alone, its exclusion list (crisis, title_ix, instructor, campus_police) is intentional and stays in production

07. Monitoring and Incident Response

Dashboards

The pilot lead needs three dashboards visible at all times:

• Health: request volume, error rate, p50 and p95 response latency, Bedrock token usage
• Routing quality: which categories are routing most, ratio of empathy-only responses to escalation-to-chat, languages observed, unanswered queries
• Cost: daily and projected monthly Bedrock spend with explicit alarm thresholds

Alarms

• Error rate above 5% over a 15-minute window: page on-call
• P95 latency above 8 seconds over a 30-minute window: page on-call
• Daily token usage above 1.5x the seven-day average: Slack alert to engineering channel
• Daily token usage above 3x the seven-day average: page on-call (likely abuse or runaway loop)
• Bedrock model access errors: page on-call (model deprecated or region issue)

Incident response

The pilot needs a single on-call rotation across the engineering team with a runbook covering the most likely incidents:

• Bedrock outage or degraded response: degrade gracefully to a static “service temporarily unavailable, please contact [office] directly” message with the most-routed offices’ contact info hardcoded
• Sudden cost spike: rate-limit globally to a lower threshold, investigate logs for abuse pattern, consider IP block list if abuse is identified
• System prompt regression: roll back to previous version via Lambda alias swap (under 60 seconds)
• Student reports inappropriate response: capture the conversation context (without breaking anonymity), patch the system prompt, deploy the fix, follow up with the student through the office they were routed to (not directly)

08. Cost Estimates

These are pilot-scope estimates only. They assume one college, one semester, conservative traffic projections (5,000 student conversations during the pilot window, average 2,500 tokens per conversation including system prompt and response). District-scale projections require a Maricopa-specific AWS pricing conversation that has not happened yet (PRD Open Questions appendix).

09. Pilot Launch Checklist

The week before the pilot opens to students, walk this list. Anything still open is a launch-blocker.

• All Section 02 pre-launch items signed off by their respective owners
• Soft launch happened, the pilot lead and three trusted students ran 10 representative scenarios end-to-end and confirmed correct routing, working URLs, and reasonable response latency
• Per-office chat staff are trained and have run a chat with the pilot lead acting as a student
• Crisis routing tested with the GCC counseling team in the loop, confirming the warm handoff actually works as designed
• Monitoring dashboards are visible to the pilot lead and the on-call engineer
• Communication plan executed: syllabus statement is in faculty-facing materials, the GCC homepage links to the tool, an internal announcement has gone to participating departments
• Rollback plan documented: who can take the tool offline, how to do it, and what the off-state communicates to students
• Office hours posted for the pilot lead so participating departments know who to ask if something goes wrong

10. Post-Pilot Evaluation Gate

The pilot ends with a formal evaluation conversation, not an automatic rollover into district scale. The gate is a deliberate decision point: based on what the pilot showed, does Maricopa want to keep this tool, change it, scale it, or not?

Evidence the pilot needs to produce

• Usage: total student conversations, breakdown by category, peak times, language distribution
• Routing quality: sample of conversations reviewed by department leads to assess whether the routing was right, whether the empathy framing landed, whether the contact info was sufficient
• Chat handoff load: per-office chat volume, response time, staffing sustainability assessment from the staff who handled chats
• Student feedback: structured exit-interview-style feedback from a sample of students who used the tool, with specific attention to students who used it for stigma-coded topics
• Department feedback: from each participating office, an honest assessment of whether CopaMigo reduced their repeat-question load, increased it, or had no measurable effect
• Cost: actual vs. projected, and a defensible district-scale projection based on real pilot data

Decisions on the table at the gate

• Continue, expand, or sunset. If the evidence supports it, continue at GCC and add additional Maricopa colleges. If the evidence is mixed, continue at GCC at current scope and re-evaluate after a second semester. If the evidence is negative, sunset honestly, the architecture being a thoughtful bet doesn’t obligate anyone to keep paying for a tool that didn’t deliver.
• Architecture path for scale. Stay on Scenario B (AWS Bedrock direct), or move to Scenario E (hybrid with Salesforce for identified students). The decision depends on what kinds of student needs the pilot showed actually matter.
• Governance handoff. The pilot ran with faculty-led ownership. Scaling requires a designated institutional unit and budget line. Who owns it, where the budget sits, and what the SLA is, all decided at the gate, not assumed.