First Pilot: GIAIC/PIAIC/Panaversity AI Support
The first worker built with Zia Developer AI: a customer and student support Digital FTE, named Zia Khan — GIAIC/PIAIC/Panaversity AI Support.
This page holds the pilot-specific parts of the Zia Developer AI specification: Product Section 6, the pilot part of E10, FR-J12, FR-L5, and AC-40 to AC-42. Every other requirement identifier cited here is defined in Zia Developer AI Requirements.
Contents
- Mission and scope
- Worker identity and self-description
- Team and customer communication
- Support loop and graph
- Bounded prototype and rollout
- Path to release
- Pilot-only requirements
- Pilot tests
- Pilot acceptance
Mission and scope
M0 demonstrates the GIAIC/PIAIC/Panaversity customer-support worker, named Zia Khan — GIAIC/PIAIC/Panaversity AI Support. It replaces accounting as the first prototype. It uses Claude Code as the initial development host and a generated Claude Code plugin, with typed Python tools only where needed. Codex development integration follows in 1.0; SDK generation remains in 1.2. A separately operated channel gateway and case service may be required: installing a plugin does not create Slack, email, or WhatsApp inbound endpoints.
The mission is to receive prospective-customer and current-student inquiries, answer within approved knowledge and authority, and route unresolved inquiries to an accountable teammate. “Answer all questions” means every inquiry receives an appropriate response or handover, not that the worker invents an answer when evidence is missing.
Worker identity and self-description
Every generated AI worker must have a stable worker ID and a versioned identity record: display name, AI disclosure, role, purpose, supported tasks, limits, knowledge sources, communication channels, accountable human owner, and escalation rules. Names need not be unique; authorization uses authenticated identities and roles. Self-descriptions are generated from the approved record, not improvised claims of capability. This support worker represents GIAIC/PIAIC/Panaversity and must not claim to be the human Zia Khan. Because it is named after a real person, the customer layer records that person’s written consent to the use of the name (Identity/Praxis discipline, Requirements Section 2), and the approved self-description discloses that the worker is an AI named after that person.
Example introduction:
Hello, I’m Zia, GIAIC/PIAIC/Panaversity’s AI support assistant, named after our founder Zia Khan. I’m an AI, not a staff member. I can help you understand our courses, admissions, certifications, and student services. If your question needs a staff member’s attention, I’ll connect you with the team.
Example answer to “What can you handle?”:
I handle course and admissions questions, explain published certification pathways, and help students locate approved learning resources. I escalate payment disputes, requests for exceptions, and questions whose answers I cannot verify.
The horizontal spec supplies general worker-building and operating rules. The vertical package supplies education-support procedures. The GIAIC/PIAIC/Panaversity customer layer supplies approved programs, policies, terminology, and escalation ownership. The project layer pins this deployment’s channels, sources, limits, and evaluation fixtures. M0 may use a fixed resolved specimen of all four layers; the general composition engine follows in M1.
Team and customer communication
| Channel | Purpose | Required behavior |
|---|---|---|
| Slack | Internal coordination among human and AI teammates | Each case has a shared thread visible to its authorized support team, with sender identity, case ID, owner, status, decisions, and handover. Sensitive details use appropriately restricted records or channels. |
| External customer/student conversations | Associate messages with a durable case, preserve threading, validate sender/address handling, and record delivery outcomes. | |
| External customer/student conversations | Use a qualified supported business integration, preserve conversation-to-case mapping, and enforce the provider’s verified messaging and account requirements. |
Email and WhatsApp are delivery channels for the same worker, not separate worker implementations. Slack is the shared coordination space; a durable case service is the system of record for ownership, approvals, state, and results. Team visibility does not grant every member access to private student records. A shared display name does not prove that two channels belong to the same customer; linking identities requires an approved verification procedure.
Example: a prospective student asks on WhatsApp which course suits a beginner. The worker consults approved course information, asks about goals if necessary, and explains the options with source links. If eligibility is ambiguous, it posts a limited case summary to the support Slack channel. A human or authorized specialist agent contributes in the thread. The worker checks the contribution against its sources and authority rules, sends the approved reply through the originating channel, and records the resolution. Missing ownership produces an explicit escalation state, not a claim that someone is handling it.
A Slack message such as “give them a discount” is not sufficient authorization. The service checks the sender’s authority, operation, approved inputs, and expiry under the existing approval contract. Other agents may propose answers and request handovers; they cannot manufacture human consent. Agent-to-agent communication needs correlation IDs, bounded exchanges, explicit ownership transfer, and protection against duplicate replies and self-triggering message loops. This first worker can coordinate with configured teammates; automatic construction and wiring of an arbitrary multi-worker team remains outside scope.
Support loop and graph
The support loop is: understand the inquiry, consult approved knowledge, check the answer, clarify or respond, then resolve or escalate within a configured turn/time budget. The fixed graph branches into course/admissions, certification, learning-resource, or restricted account/payment support. Source validation precedes factual answers; required identity checks precede personal-data access; required approval precedes external sending or exceptional action. The gateway and protected tools enforce these dependencies independently of model instructions.
The scheduled heartbeat reviews open cases and overdue handovers; it does not create unsolicited customer outreach. An event can enqueue a case while a qualified runner processes it on the supported cadence. Declare the resulting response-time expectations. If the plugin profile cannot meet the required availability or latency, qualify a backing runtime before advertising those guarantees. This does not silently move managed or SDK delivery into M0.
Bounded prototype and rollout
M0 uses approved public GIAIC/PIAIC/Panaversity information, synthetic customer inquiries, a pinned horizontal snapshot, and a fixed support workflow. It includes Slack coordination and one external channel, selected at kickoff based on verified account access and integration feasibility. Email and WhatsApp are both required for the completed support pilot at M4, but they are qualified separately. M0 sends only to approved test destinations after explicit send approval; it does not launch a live customer service. Actual channel setup and sending require deployment authorization, not this document edit.
| Exit evidence | Required result |
|---|---|
| Approved fixture | Support owner approves at least 20 inquiries, pinned sources, expected facts, escalation decisions, and answer rubric before implementation. Cover prospective and current students. |
| Useful response | The worker accurately identifies itself, answers supported public-information questions with traceable sources, and visibly hands over unsupported questions. |
| Team coordination | A human and a configured test-agent teammate can contribute to the same authorized Slack case thread; identities and case ownership remain clear. |
| External channel | The selected channel receives a test inquiry, creates a case, and delivers an explicitly approved answer; delivery status remains distinct from business resolution. |
| Negative cases | All seeded invented-policy, stale/conflicting-source, unauthorized-approval, sensitive-data, injection, and duplicate-message cases are handled according to the approved expectations. |
| Recovery | Interrupt and resume without lost accepted cases, duplicate committed sends, or a pending approval becoming consent. Reconcile uncertain delivery explicitly. |
| Quality | At least 18 of 20 fixed inquiries meet the approved factual/relevance rubric; every critical authorization, privacy, and approval fixture passes. Report all attempts, escalations, time, and cost. |
| Reproduction | Another developer reproduces the plugin, fixed workflow, source snapshot, tests, and documented gateway configuration from a clean checkout. |
M0 excludes a general plugin compiler, managed targets, arbitrary graph scheduling, a marketplace, production student records, refunds, payment handling, enrollment changes, and unattended external sending. Personalized student-account support follows only with separately authorized authenticated integrations. Mandatory runtime controls, bounded execution, protected fixtures, secret exclusion, and durable operation IDs apply from M0. A useful interactive prototype is not labeled an operational Digital FTE until recurring case ownership, availability, monitoring, and escalation are qualified.
Path to release
The shared roadmap from M0 to M6 is in Zia Developer AI Requirements, Section 6. For this pilot: M0 is the bounded prototype above, one useful and controlled support workflow with the exit evidence listed. M4 is the full GIAIC/PIAIC/Panaversity support pilot with Slack, email, and WhatsApp, the learner and consultant studies, and the release handover; it requires all 1.0 Must requirements and the release-specific acceptance evidence. The milestones between them (M1 to M3) are engineering milestones for Zia itself.
Pilot-only requirements
These two requirements apply to the support pilot only. FR-D26 (worker identity, all generated workers) and FR-J13 (public-channel volume and cost limits) also apply and are defined in Zia Developer AI Requirements.
| ID | Priority | Requirement | Evidence |
|---|---|---|---|
| FR-J12 | Must, support pilot | Maintain durable cases and authenticated participant identities across Slack, email, and WhatsApp. Enforce ownership, authorized visibility, scoped message deduplication, bounded agent exchanges, and independent send/approval controls. Verify customer identity before linking channels or accessing personal records. | AC-41 |
| FR-L5 | Must, support pilot | Deliver Slack plus one qualified external test channel at M0 and both external channels by M4. Declare gateway/runtime availability, response expectations, operators, provider prerequisites, costs, delivery reconciliation, and incident handling. The handover states a numeric escalation response floor (maximum time from escalation to human acknowledgement during declared operating hours), not free text alone. No connector or hosting capability is assumed from plugin installation. | AC-42 |
Pilot tests
The GIAIC/PIAIC/Panaversity support pilot is the first customer-facing worker. Its name is Zia Khan — GIAIC/PIAIC/Panaversity AI Support. Its approved scope, identity, channel staging, and M0 exit criteria are defined above. By M4 it supports qualified Slack coordination and both email and WhatsApp, with a human owner, documented operating hours/response expectations, case monitoring, and escalation. Production operation requires its own approved rollout. Synthetic fixtures remain separate from production records.
| Pilot test | Required result | Requirements |
|---|---|---|
| P01 Valid inquiry | Interactive and scheduled profiles answer approved support inquiries with traceable facts. Repeat on later targets in their assigned releases. | FR-G3, FR-E8, NFR-1 |
| P02 Bad inputs | Malformed events, missing case identifiers, conflicting customer links, duplicate messages, and an inbound flood above the declared per-customer and per-day limits are rejected, reconciled, or held before any send. | FR-D12, FR-J12, FR-J13 |
| P03 Missing evidence | Stale, contradictory, or absent policy evidence produces clarification or escalation; no answer or citation is invented. | FR-G3, FR-E8 |
| P04 Conflicting rules | Customer instructions cannot weaken horizontal or vertical controls. | FR-C2, FR-C6 |
| P05 Isolation and access | One student cannot access another’s records; source or message instructions cannot grant permissions. Slack visibility follows authorized team membership. | FR-K4, FR-E4, NFR-3 |
| P06 Interruption | Resume or fail clearly without duplicate sends, lost ownership, or fabricated approval. | FR-J2, FR-J4, FR-J6 |
| P07 Portability | Common case fixtures pass across interactive and scheduled profiles; channel/runtime evidence is qualified separately. | FR-D9, NFR-1 |
| P08 Deployment and handover | Reproduce deployment and identify channel, gateway, case-store, knowledge, billing, and incident owners; complete usability and cost studies. | FR-D15, FR-L3, NFR-9, NFR-10 |
| P09 Data statements | Approved data statements cover knowledge retrieval, case records, Slack, external channels, logs, and inference before relevant data moves. | FR-K5, FR-K8 |
| P10 Hosts | Both 1.0 development hosts complete the plugin workflow; later targets repeat their applicable tests. | FR-F7, FR-F10 |
| P11 Loop and surface | Heartbeat finds overdue cases, checker rejects a seeded unsupported answer, human checkpoint blocks the protected send, and support owner reviews through the plugin; repeat on the managed surface in 1.1. | FR-E12, FR-D17 |
Pilot acceptance
| ID | Criterion |
|---|---|
| AC-40 | The worker states its approved name and AI role and accurately answers questions about capabilities, limits, knowledge, and ownership. The default self-introduction itself passes the disclosure check: it states that the worker is an AI and does not present itself as the human. Attempts to induce impersonation of the human Zia Khan or invented authority fail. The recorded name consent exists in the customer layer. |
| AC-41 | Human and configured agent participants coordinate visibly in an authorized Slack case thread. Test wrong-role approvals, agent-fabricated consent, private-data leakage, repeated events, cross-channel identity ambiguity, handover without an owner, and self-triggering exchanges. Required checkpoints survive restart. |
| AC-42 | M0 passes the exit criteria above using approved test accounts. Before M4 acceptance, repeat inbound receipt, durable case creation, approved reply, delivery reconciliation, and handover through both email and WhatsApp and Slack. Record actual account/API permissions, provider rules checked at deployment, limits, credentials, runtime profile, and operating owner. No live service or automatic sending is claimed solely from documentation. |