AI Troubleshooting

This standard gives the diagnostic order for failures of the Company's AI services. It is used by AI Operators investigating a fault, by Support staff handling customer reports about the assistant, and by the AI Operations Lead deciding whether a fault is also an incident under AI Incident Handling. Every failure mode below is taken from the services' actual handling paths as described in AI Operations Overview. Operators shall work the diagnostic order at the end of this standard, in sequence, rather than beginning with the component they suspect.

Roles and duties

• AI Operator: performs the diagnosis, applies the corrections within operator authority, and records the finding.
• Support: reports the customer's exact experience, the time, and whether products, urgency guidance, or the whole reply were affected.
• AI Operations Lead: owns faults this standard does not resolve and decides on restriction or suspension of a feature.

The time budget

A Pawzly turn runs inside a total budget of 45 seconds. Inside that budget sit the triage call (up to 30 seconds) and the subsequent gateway calls for the reply, product selection, and grounding steps. Operators shall understand the arithmetic: a slow triage followed by slow gateway calls can exceed the total budget, and when the budget is reached the turn ends wherever it stands and the customer sees a general failure. Slowness anywhere in the chain therefore converts to total failure at the budget line, not to graceful delay. The diagnostic signature is a partial record: a selection record with no grounding record after it, or a triage attempt with nothing after it, in a turn the customer reports as "the chat died." The correction is to bring the inner timeouts down so the budget adds up: the 30-second triage allowance is the loosest figure in the chain and the first candidate: not to raise the total budget without that analysis.

Gateway failures

The Company's gateway is the single path to the Company's models. Its failure handling, in order

1. Authentication failure. The gateway credential is wrong or revoked. A wave of these failures with no configuration change is the rotation signature: the old credential was revoked before the change carrying the new one took effect. Correction follows the rotation order: store the new credential, redeploy, verify, then revoke the old: under Model Inventory and Lifecycle.
2. Throttling by the gateway. Distinct from the Platform's own customer-facing limit of 20 requests per 60 seconds per network address: gateway throttling appears as error records in the invocation log, while the Platform's own limit never reaches the gateway and leaves no invocation record. Operators shall establish which limit produced a "slow down" report before acting; tightening the Platform limit does nothing for gateway throttling.
3. Successful result with empty content. Treated as a failure, and the next Company model in the recorded fallback order serves. A burst of these on the primary model, with clean successes, means the primary is degrading quietly and the fallback is silently carrying: and costing: the traffic. The model reference on the successful records shows which model actually served.
4. Timeouts. Classified by their error signature in the invocation records. A timeout pattern on one model while another is healthy is a model-side fault; on all models, a gateway or network fault.

Every gateway failure degrades the turn step by step, not all at once: no selection step means no products; no grounding means the ungrounded reply requires incident review where the turn was care-related; no reply step means the customer is told the assistant could not be reached. A single turn may succeed at one step and fail at the next, and the stored message does not show which; the invocation records do.

Triage service failures

Where the triage service does not answer, answers too slowly, or returns an error, the conversation continues on the conversational path, with these consequences, which the operator shall treat as the dangerous degradation in this system: no urgency classification has occurred; the stored message carries no triage identifier; and the customer receives an answer that looks normal while the safety step is absent. Operators shall check for this state whenever chat traffic continues while new triage session records stop accumulating. Answers that change character with no prompt or model change recorded are checked first against the triage service's model setting, observable in the model identifier on new triage sessions, and against the register under Model Inventory and Lifecycle.

Product path failures

Products are drawn from the Company's own product search index. Where the index is unavailable or slow, the turn shows no products and the conversation otherwise works: the shopping half of the service disappears silently. Where "the assistant stopped recommending products" is the report, the operator shall check the search index before the model: the selection step may be producing sound queries into a failing index. The assistant drawer and the recommendations surface share this dependency, so simultaneous failure across product surfaces is one index fault, not several model faults.

The abuse limit's limits

The 20-per-60-seconds-per-address limit is held in process memory. Operators shall know its three consequences: restarts clear all counters, so a burst timed to a restart passes through; multiple running instances each enforce their own limit, so the effective limit multiplies; and the limit keeps no record: a customer reporting "it told me to slow down" leaves no trace to query, and the message on the customer's screen is the only record. The limit is a tripwire, not a quota system. If misuse becomes sustained rather than theoretical, the AI Operations Lead shall move the limit to shared storage with recording, as a change under AI Operations Overview.

The logger's silence

The invocation logger never interrupts an answer, by design, and logging failures are therefore silent. A missing invocation record is ambiguous: the call happened and logging failed, or the call never happened; the table cannot distinguish the two. What can be trusted: a present record with an error result is positive proof of the failure and its time; a record with no model join means the register has no matching entry, which is a register defect under Model Inventory and Lifecycle; no usage counts on an error record means nothing was computed and no cost arose; no usage counts shall be read as zero usage where the record is incomplete.

Classroom tutor failures

The tutor's serving model is selected by configuration. Where the tutor changes behaviour or stops answering, the operator shall check the configuration first: a changed or missing configuration value can switch which Company model serves, and the two possibilities behave differently. Tutor errors reach the learner as a general failure message; the underlying status is in the invocation records for the tutor features.

The diagnostic order

1. Invocation records, last hour, by feature and result. An error concentration on one feature points to that step. Errors on all features point to the gateway or the credential. No records at all during reported failures means the request never reached the gateway: the abuse limit, input limits, or the time budget above.
2. The feature's handling path. Read the actual handling for that step: its timeout, its fallback, and what occurs on empty content, under AI Operations Overview.
3. The gateway and credential. Service state, credential validity, fallback-order behaviour.
4. The data. Triage session records for classification quality; the product search index for relevance; the knowledge base documents: where a care protocol is wrong, correct the document, not the prompt.
5. The registers. Model and prompt records identify exactly what served the failing turn.

And the closing rule, carried from AI Incident Handling: a correction is verified against the original failing case, not a paraphrase. The fault is closed when the correction is proven, not when it is shipped.

Controls

Diagnosis shall not be performed by altering prompts or models speculatively; one change at a time, recorded, so the record shows what corrected the fault. Every fault affecting triage classification is also filed as an incident, whatever its cause.

Records

This standard produces diagnostic notes attached to the fault or incident record: the invocation pattern found, the step at fault, the correction applied, and the verification against the original case.

Escalation

A fault unresolved within one business day, any fault affecting triage classification, and any suspected credential compromise go to the AI Operations Lead and to support@aapawz.com the same day. Legal process arising from an AI failure goes to legal@aapawz.com.

Review cadence

The AI Operations Lead reviews fault patterns monthly and amends this standard where a new failure pattern has been established.