AI Incident Handling

This standard governs how failures of the Company's AI services are recorded, investigated, corrected, and reported. It is used by every AI Operator and Support staff member who notices a failure, by the AI Operations Lead, who owns each incident to resolution, and by the Clinical Reviewer, who owns any incident touching animal care. The threshold for filing is deliberately low: anything an AI service did wrong, or nearly did wrong, that is worth recording is an incident. The cost of an unnecessary record is nothing; the cost of a pattern nobody recorded is a systemic failure discovered by a customer.

Roles and duties

• Any operator or Support staff member: files the incident immediately, while the evidence is fresh.
• AI Operations Lead: assigns the owner, sets severity, and confirms the verified correction before closure.
• Clinical Reviewer: investigates every incident touching urgency, diagnosis language, or animal outcome, and decides the clinical remediation.
• Incident owner: investigates, records the failure classification, and verifies the correction against the original case.

Severity

Severity measures harm, not embarrassment

• Critical: a missed emergency; diagnosis language served to a customer; any case where an animal's outcome may have been affected.
• High: an urgency misclassification short of critical; a grounding failure on a care-related turn; a sustained failure of the triage path.
• Medium: irrelevant product selection; phrasing problems; transient serving errors.
• Low: cosmetic faults; a single transient failure with a clean fallback.

Where two levels are arguable, the higher is taken. Severity may be lowered after investigation; a critical incident filed as medium does not receive the immediate response it needed, and that error is not recoverable.

Where the evidence lives

The investigator works from the session outward

1. Triage session records: the fullest record: what the customer wrote, the urgency concluded, the recommendation given, the model that served, the knowledge documents consulted, and the red flags recorded. Reconstruct the incident here first: what was said, what was concluded, and where the two diverged.
2. Chat message records: the turns as the customer saw them, with urgency, red flags, the products shown, and the link to the triage record. This is where the investigator checks whether the grounding step constrained the final reply and whether the products shown matched the selection step.
3. Invocation records: the serving record: feature, model, usage counts, latency, and result. This is where "the model answered badly" is separated from "the model never answered." An error result with no usage counts and very low latency is a gateway failure: nothing was computed; a successful result with a bad answer is a quality failure. The two have entirely different corrections, and this record is the only place that separates them cleanly.

The investigator then classifies the failure, because the correction depends on it

• Reasoning failure: the knowledge consulted was sound and the conclusion was wrong. Correction lies in the prompt or the model.
• Knowledge failure: the documents consulted were wrong or incomplete, or the wrong documents were reached. Correction lies in the Company's knowledge base or the way it is searched.
• Serving failure: no answer, or the fallback answered. Correction lies in the gateway, the triage service, or timeouts, under AI Troubleshooting.
• Selection or grounding failure: the answer was sound and the products were wrong. Correction lies in the selection prompt or the product search path.

The classification is recorded in the incident. The next investigator shall not have to repeat the work.

Filing and working the incident

1. File the incident record immediately: model (the model reference from the triage or invocation record where the register join is unavailable), severity, status opened, a title written for a future reader, and a description carrying the session, message, and invocation identifiers.
2. Where the incident touches care: wrong urgency, missed emergency, any animal-outcome question: file the corresponding telemedicine incident record as well, with the reporter type, the session, and an honest statement of whether the record contains protected health information, because that statement governs who may handle the record from that point on. Clinical incident duties to customers and regulators are governed by the Tele-Triage Terms and the Teletriage Disclosure Policy.
3. Work the record as a sequence: opened, investigating, remediating, resolved: with a named owner at every stage. Corrections follow the classification. A prompt failure is corrected by a new prompt version under Prompt Library and Versioning, with the incident referenced in the change record; a model failure is tested under Evaluations and, where the model is at fault, changed under Model Inventory and Lifecycle; a knowledge failure is corrected in the knowledge base and the affected evaluations re-run; a serving failure is worked under AI Troubleshooting, with a note on whether the fallback behaved as intended.
4. The incident stays open until the correction is verified against the original failing case: the actual case, not a paraphrase: and the verification is recorded. An incident closed without a verified correction is an incident waiting to recur.

The reporting loop

Critical incidents are reviewed immediately. All other incidents are reviewed in a regular session where patterns are the point: three medium urgency failures in a month is a systemic finding even where each looked minor alone, so incidents are aggregated by failure classification as well as by severity. External reporting follows the Company's regulatory obligations and its veterinary partners' requirements; where reporting is arguable, the Company reports. The record exists so the Company can answer, at any time: what went wrong, what was done, and what changed so it does not happen again.

One asymmetry governs every investigation: the invocation logger is built never to interrupt an answer, so a logging failure is silent. A missing invocation record for a session that plainly involved a gateway call means the logging failed; it does not mean the call did not happen. A present record with an error result is positive proof of the failure and its timing. Trust presence; treat absence as ambiguous.

Controls

No incident record is deleted or rewritten after filing; corrections are appended. Access to incident records that contain protected health information is limited to the roles named in this standard. The AI Operations Lead may restrict or suspend an AI feature at any point during an investigation, and shall do so for any critical incident whose cause is not yet understood.

Records

This standard produces incident records with severity, classification, owner, and verification, telemedicine incident records where care is touched, and periodic pattern reviews. Incident records are retained permanently.

Escalation

A critical incident goes to the AI Operations Lead and the Clinical Reviewer immediately, and to support@aapawz.com the same day. An incident that may require notification to a regulator, a partner, or an affected customer goes to legal@aapawz.com the same day it is identified.

Review cadence

Incidents are reviewed weekly by the AI Operations Lead and the Clinical Reviewer, and pattern reviews are conducted monthly.