AI Operations Overview

This standard describes what the AI Operations function operates and the duties that attach to operating it. It is used by the AI Operations Lead, who owns the Company's AI services day to day; by AI Operators, who monitor and maintain them; by the Clinical Reviewer, a licensed veterinarian who reviews triage quality and safety; and by Support staff, who receive customer reports about AI behaviour. The Company's AI services are the Company's own systems: models the Company operates on its own data, reached through the Company's own gateway. No part of these services is provided by an outside AI vendor, and no customer request is sent to an external AI service.

Roles and duties

• AI Operations Lead: owns the model, prompt, evaluation, incident, and cost standards in this section; approves every model or prompt activation.
• AI Operator: monitors invocation records, error rates, and latency; performs the checks in AI Troubleshooting; files incidents.
• Clinical Reviewer: reviews triage outputs for urgency accuracy and the no-diagnosis boundary; approves any change that affects triage behaviour.
• Support: routes customer reports about AI answers into AI Incident Handling with the session identified.

The services operated

The Company operates two customer-facing AI services, both served through the Company's gateway and both recorded in the same invocation log

1. Pawzly, the pet-care triage and shopping assistant on the storefront. A customer describes symptoms or asks about products; the service classifies urgency, answers general care questions, recommends products from the Company's own catalog, and directs emergencies to a veterinarian. Pawzly is the only customer-facing AI with clinical-safety consequences, and it is operated under the Tele-Triage Terms and the Teletriage Disclosure Policy. Pawzly provides general information and urgency guidance only; it does not diagnose and does not treat.
2. The classroom tutor, inside the Company's learning portal. It answers course questions from the Company's course materials. Its errors confuse a learner; they do not endanger an animal, and its review cadence reflects that difference.

How a Pawzly request is handled

Operators shall understand the handling order, because each stage has its own failure behaviour

1. Abuse control. Requests are limited to 20 per 60 seconds per network address. The limit is abuse control, not a quota, and exceeding it returns a plain-language message asking the customer to slow down.
2. Input limits. A message is capped at 1,500 characters; conversation history is the last 8 turns at 1,200 characters each. Pet context is attached from the customer's own records where the customer is signed in; a general mode suppresses pet context for a shopper buying for someone else.
3. Triage. The request passes to the Company's triage service, which returns an urgency classification (INFO, ROUTINE, URGENT, or EMERGENCY), any red flags, whether the customer must be directed to a veterinarian, and a triage record identifier. Triage is a hard dependency for safety classification. If the triage service does not answer, the conversation may continue but no urgency classification has occurred, and operators shall treat that state as a safety-relevant failure under AI Troubleshooting.
4. Reply. The reply is prepared under the governing prompt in Prompt Library and Versioning: brief, practical, never a diagnosis, with the fixed list of emergency signs: trouble breathing, collapse, seizures, poisoning, bloat, repeated vomiting, blood, inability to urinate: always answered with direction to contact an emergency veterinarian immediately.
5. Product selection. Where the shopper would benefit from products, a selection step produces a short search query of 2 to 5 words, which is run against the Company's own product search index. Empty or invalid results are discarded. Emergencies skip this stage entirely: no product cards are shown on an EMERGENCY.
6. Grounding. Before it is sent, the reply is checked against the products actually returned, and may name only those products. This is the control that keeps the assistant from presenting a product the Company does not sell as if it were Company fact.
7. Recording. Signed-in customers' turns are stored as chat sessions and messages carrying urgency, red flags, products shown, and the triage identifier. Guest conversations are not stored. Every gateway call: including failures: is written to the invocation log with its feature, usage counts where the service reports them, latency, and a result of success, error, or timeout.

The classroom tutor applies the same pattern at lower stakes: messages capped at 4,000 characters, the last 16 messages of history, and answers drawn from the Company's course materials, recorded in the same invocation log.

Human oversight duties

No AI output reaches a customer outside the oversight this section specifies

1. Models and prompts reach customers only after evaluation and human approval, under Model Inventory and Lifecycle, Prompt Library and Versioning, and Evaluations.
2. The Clinical Reviewer samples live triage sessions weekly and reviews every session classified EMERGENCY or URGENT, checking urgency accuracy, red-flag handling, and the no-diagnosis boundary.
3. Any output reported as wrong, unsafe, or misleading is investigated under AI Incident Handling, and the service may be restricted or suspended by the AI Operations Lead at any time.

Data duties

Customer data is used by these services only as the Privacy Policy permits. Pet and conversation data attached to a request is limited to what the answer requires. Customer data shall not be used to improve a model except as that Policy permits, and evaluation datasets drawn from real sessions are reviewed and corrected by a human before use, under Evaluations.

Controls

The invocation log is the shared operational record for both services, and it is kept complete: a logging failure shall never be allowed to interrupt a customer answer, which means a missing log record does not prove a call did not happen. Operators shall reason about absence accordingly in every investigation. Access to operate these services is limited to the roles named above. Disclosure duties for these services are governed by AI Disclosures and Agent Registration and the AI Disclosure Policy.

Records

This standard relies on and produces: invocation log records, triage session records, chat session and message records, the model registry, the prompt library, evaluation records, incident records, and cost records, each kept under its own standard in this section.

Escalation

Operational failures go to support@aapawz.com. A suspected clinical-safety failure: a missed emergency or diagnostic language served to a customer: goes to the AI Operations Lead and the Clinical Reviewer immediately, and is filed the same day under AI Incident Handling. Legal process or a regulator's enquiry concerning these services goes to legal@aapawz.com.

Review cadence

The AI Operations Lead reviews this overview, the service inventory, and oversight sampling results monthly, and the Clinical Reviewer reviews triage safety sampling weekly.