See which model scores a source

The Model readiness page of the automatic console (Automatic, then Models) shows, for each source, where it stands on getting a model. It reads two things the API serves, the source's onboarding status (GET /sources/{source_id}/onboarding) and its processing counts (GET /sources/{source_id}/processing-counts), and says only what they say. When no compatible model is available the page says so: it never substitutes predictions.

What each state means

State	What it means	Next step
Manual	The source uses manual controls.	Choose, evaluate and activate its models under Models and Deployments.
Needs attention	The service reported an exception that needs a person. The exception is listed as the service worded it.	Open the source and review its exceptions.
Needs approval	A guided source has a proposed interpretation that is not in use until it is approved.	Review the proposal on the source page.
Interpreting	No interpretation has been accepted yet. A guided source is waiting for a proposal.	Keep sending records.
No eligible model	An interpretation is accepted, but no compatible model is selected and none is active. The page quotes the service's own reason.	Usually nothing: the state changes when a compatible model is selected. When the quoted reason says a prepared model waits for your decision, accept or reject it (A model waiting for your decision).
Selected	A compatible model is selected for the source and named on the card. It is not active in a deployment yet.	Wait for activation.
Active	The deployment that scores the source has an active model. The card names the deployment, the model, the activation generation and the deployment binding.	None.

A source counts as Active only when the processing counts name an active model in its deployment. A model that is merely selected is shown as selected, and a source is never shown as scored by a model the API does not name.

Notices that are not exceptions

Two things the status reports sit beside the model state without asking anything of you.

• The daily enrichment budget is used up (budget_exhausted). Deferred enrichment resumes on its own after the next UTC day while the source records are retained, and records are still accepted. To resume sooner, raise budgets.inference_requests_per_day in the source's onboarding policy with PATCH /sources/{source_id}/onboarding (updateSourceOnboarding). The console has no control for this yet.
• Tessera is retrying some enrichment automatically. While a transient failure of an event's semantic preparation is retried, the status carries an incompatible_drift exception whose message is "Canonical events are queued; original semantic preparation needs attention." That is a retry in progress, not drift, and it clears when the retried work is published, expires or is stopped. Any other incompatible_drift exception, including one that says preparation is blocked, is listed as an exception that needs a person.

A model waiting for your decision

Automatic preparation never accepts a finding for you. When the model it prepared for a source is evaluated with quality findings only (the needs_acknowledgement verdict: failed advisory gates G1-G3), the model is kept and the preparation waits with reason owner_decision_required. The source's status quotes "A model was prepared and evaluated with findings and waits for the owner's decision", so Model readiness shows it, and the diagnostics say where to act: the source's diagnostics show a decision panel with both choices. Nothing happens on its own until you decide.

GET /sources/{source_id}/automatic-preparation/decision (getSourceAutomaticPreparationDecision) names the parked model (model_id, report_id), the shared export and binding it was prepared with, its findings (promotion), the gates to acknowledge (accept.acknowledge_gates) and the two choices:

• Accept. Import the model with acknowledge_gates covering exactly those gates and your reason (importSharedCheckpoint with the decision's registered_export_id and binding), or create its bundle with the same acknowledgement (createModelBundle on model_id). In the console, the source's diagnostics show a decision panel: review the findings (with the numbers of the decision's report_id), select each one, give your reason, choose one of the eligible deployments and select Accept and activate (the model's page under Model readiness, Shared models is the alternative). Through the API, then activate the bundle (activateSlot) on one of the decision's accept.eligible_slots: a live, realtime deployment of the source's entity type that is not another source's automatic deployment (activating there would end that source's automatic serving and is never recorded for this one). A listed deployment that already serves a bundle is replaced. The decision names the source's own automatic deployment (accept.source_automatic_slot, listed or not); when its handed_back_on_accept is true, accepting on another deployment hands it back: it stops serving its current model (audited slot.withdraw, reason owner_accept_moved, so a deployment's active bundle can now also clear this way), and reads, schedules and monitors bound to it go dormant. Accepting on that deployment itself replaces its model instead. Within minutes the preparation records that bundle as the source's compatible model, takes that deployment as the source's, replays the source's history and ends active; the audit log records onboarding.owner_accept with your acknowledgement.
• Reject. Archive the model (archiveSharedModel, Archive on the model's page), optionally with your reason ({"reason": "..."}). The preparation records onboarding.owner_reject with that reason, never prepares that export again and waits for another model (owner_rejected).

Automatic selection never activates a bundle that has findings or an acknowledgement, even one you created; only your activation does. A rejection that is not a choice: an integrity failure (G4-G6, or an evaluation that cannot be read or verified) rejects the model with evaluation_gates_rejected, and so does a gate your project's promotion policy makes blocking. That policy is an org admin's choice (strict mode or a raised gate) and is changed with PUT /promotion-policy (Settings, Promotion policy). A storage error while reading the evaluation is retried, never read as a rejection, and it never holds up the automatic preparation of the project's other sources.

While a model waits for your decision its preparation keeps its snapshot window, so an erasure of an entity in that window waits (awaiting_snapshot_release); the dataset file state names it (blocking_erasures). Rejecting releases it once the archived model's files are purged; an accepted model keeps its window while it serves.

Edge cases: the console reads the decision again before the import and before the activation, and refuses (asking you to choose again) when the deployment you chose is no longer eligible, now serves another bundle, or the decision now names another model, another evaluation report or other findings to accept; the findings you selected, your reason and the deployment are then cleared. The console also previews the import and sends its expected_preview_fingerprint, so an evaluation that changes just before the import is refused (stale_preview) with nothing created, and the panel says the facts changed. activateSlot itself takes no precondition yet, so another writer can still move the deployment in between (HD-774). An Accept on a deployment that never becomes eligible is never recorded for the source; the decision stays "Accept in progress" with the activation error shown, and you can activate on an eligible deployment or reject the model.

A source stopped by the leakage gate

Before Tessera approves a source's interpretation it evaluates the whole project contract, this source's new section and every approved section, against the project's leakage policy. When that fails, the status carries a leakage_rejected exception. Its message starts "Leakage validation failed:" and names each failing rule, event type and attribute (never a record value); source_paths lists this source's fields behind it. "An approved section of the project contract" means the conflict is with another source's approved attribute: for example an attribute another source approved as a model feature that this source reads as an identifier. An identifier is never a model feature, so review that attribute's role on the contracts page (the card's Review the contract link), or the project's leakage policy. When an approved identifier role came from an earlier rule that no longer applies (for example a price or quantity column an older release marked as an identifier), the message says "price is approved as an identifier in order.line_item; review that role": change that role on the contracts page and approve the contract, and the source continues with the column as a feature.

Tessera never proposes as a feature an attribute the project already approves as an identifier when its current rules agree it is one; it proposes it as an identifier instead. It also excludes a feature from the event types the leakage policy denies it for (only those). Neither happens silently: the status carries a manual_review_required notice that starts "Roles set for consistency with the project contract and leakage policy:" and names each such field and why. The notice is informational: the source stays active, and the console shows it as a notice, not an exception. If a role is wrong, review it on the contracts page (Review the contract) and approve the contract.

When the status and the counts disagree

Both reads carry the onboarding revision they describe. If they differ, the card shows the newer read, says which revision each came from and reads the older one again once. Refresh now reads it again on request.

Raw input retention in the onboarding policy

The onboarding policy's limits.retention_seconds sets how long raw records are kept for interpretation (24 hours by default, at least one hour). A shorter retention is a valid choice, for example to keep less raw data. Below 24 hours, enrichment deferred by the daily budget may expire before it resumes, a receipt can expire before it is processed when processing is behind, and a receipt waiting for a person's review (a guided approval, or a decision that needs attention) expires if the review is not settled within the retention. An approval is applied over exactly the records its proposal was derived from (the batches whose records its samples took, up to the policy's limits.sample_records, 256 by default), so once any batch held for the review expired it is refused with review_records_expired: send the batch again (or land the same rows again) first, then approve within the retention. A stored policy below one hour shows a notice on this status. See Raw input retention for what each case looks like and how to recover.

Authorized shared checkpoints

The same page lists the shared checkpoints authorized for the project and environment (GET /shared-checkpoint-exports), twenty at a time. An authorized checkpoint is a candidate, not a result: a source is scored only after a compatible checkpoint is evaluated and activated for it. Listing them needs the organization admin or owner role; other roles see a note saying so, and the console does not send the request for them. If none is authorized the page says that sources keep accepting and interpreting records but none can be scored until a compatible model is authorized, evaluated and activated.

An import whose local evaluation fails only advisory gates (G1-G3 under the default policy) can go ahead when you acknowledge those gates with a reason, by sending acknowledge_gates with POST /models:import-shared (importSharedCheckpoint). The console has no control for this yet. Blocking gates and provenance mismatches can never be acknowledged. See Acknowledge at a shared-checkpoint import.