Model Inventory and Lifecycle

This standard governs the register of AI models the Company operates and the lifecycle each model follows from registration to retirement. It is used by the AI Operations Lead, who owns the register and approves activations; by AI Operators, who keep the register accurate against what is actually serving; and by the Clinical Reviewer, whose approval is required for any change to a model that classifies triage urgency. Every model that serves a customer is a model the Company operates on its own infrastructure and its own data, reached through the Company's own gateway. A model that is not in the register shall not serve traffic.

Roles and duties

• AI Operations Lead: owns the register; approves registration, activation, and retirement.
• AI Operator: verifies the register against serving behaviour, including the model identifier recorded on triage sessions; reports any mismatch the same day.
• Clinical Reviewer: approves or refuses any model change affecting Pawzly triage, on the evaluation evidence.

The register

The model register is the authoritative list. Each entry records the model's human name, its exact model reference (the identifier the gateway uses for it, and the key by which invocation records are joined to the register), its version, its status, and its serving configuration: temperature, output limits, timeout values, and any fallback order. Invocation records resolve to a register entry by that reference; an invocation that cannot be resolved is a register defect and shall be corrected.

Status follows one path: registered, then in evaluation, then active, then retired. Exactly one entry per serving position shall be active at a time. A model entry that ever served production shall never be deleted; retirement is its final state, because evaluation and incident records join to it, and deleting it destroys the ability to answer, months later, which model produced a given answer.

Serving positions

The register covers, at minimum, one entry for each serving position: triage classification for Pawzly; the Pawzly conversational reply, product selection, and grounding steps, including any fallback order among Company models for those steps; and the classroom tutor. Where a fallback order exists, it is recorded in the configuration: the primary Company model serves first, and a further Company model serves only if the primary errors or returns empty content. A fallback that returns incorrect content with a successful result is not caught by the fallback order; it is caught by Evaluations, which is why evaluation gates activation.

Changing a model

A model change for Pawzly is treated with the gravity of a clinical-safety change. The procedure is

1. Register. Enter the candidate in the register with status registered, and record why the change is proposed: quality, capacity, or retirement of the current model.
2. Evaluate. Run the candidate, with the production prompts, against the evaluation suite under Evaluations. For triage, the comparison that decides is urgency accuracy on the reviewed session dataset and the safety checks. A less costly model that misses one more emergency is not less costly.
3. Assess cost. Compare the candidate's expected usage profile per feature against the incumbent's, using the invocation records under Cost Tracking and Budgets, before activation.
4. Activate. On the AI Operations Lead's approval: and the Clinical Reviewer's, for triage: set the candidate active and the incumbent retired in the same action, then set the serving configuration to match. The register and the serving configuration shall never disagree overnight.
5. Watch. For the first hours after activation, an AI Operator monitors invocation records for error rate by feature and latency, and the Clinical Reviewer reads a sample of triage sessions for urgency drift.

Credentials

The gateway credential that reaches these models is a Company credential, held in the protected secret store, never in the register, never in a document, and never in chat or tickets. Rotation follows the order in Payments and Gateway: store the new credential, redeploy, verify with a live request, then revoke the old. A sudden wave of authentication failures with no configuration change is the signature of a rotation performed out of order, and is worked under AI Troubleshooting.

Controls

No model serves traffic unless its register entry is active. The AI Operator shall check weekly that the model identifier recorded on new triage sessions matches an active register entry; a value that matches no entry means the serving configuration changed without the register changing, and is filed as an incident under AI Incident Handling. Register changes are recorded with the operator, the time, and the reason.

Records

This standard produces register entries and their status history, change proposals with their reasons, evaluation references for each activation, and post-activation watch notes. Register history is retained permanently.

Escalation

A serving model that cannot be identified in the register, or a triage model change proposed without evaluation evidence, goes to the AI Operations Lead immediately and to support@aapawz.com the same day. Questions about the lawful use of training or evaluation data go to legal@aapawz.com.

Review cadence

The AI Operations Lead reviews the register quarterly against what is actually serving, and reviews each active model's evaluation standing at the same time.