Warmup diagnostic content generation

Warmup content is an explicitly simulated diagnostic exchange for consenting test mailboxes. It is not a customer conversation or evidence of inbox placement, authentication, improved reputation or human engagement. Hypothetical facts and closure must remain consistent across every rendered turn.

Effective policy and stopping

In Admin > Warmup content > Overview, the effective settings editor shows the configuration actually read from admin_settings.warmup_generation. Save supported operator values without removing provider credentials. Manage settings permission is required for writes; existing read access is unchanged.

PUT /admin/warmup-content/settings accepts a JSON settings object and returns { "data": effectiveSettings }. Omitted fields retain their current effective values. Unknown fields, non-object payloads, multiple JSON documents and documents over 64 KiB are rejected. The overview returns effective_settings, generation_enabled, reserved_today and provider_capability. This is an admin endpoint, not a workspace API-key scope.

Targets are configured floors; demand-based sizing may increase them, bounded at 5000. The scheduler also maintains the generic fallback segment. Supported values round-trip; out-of-range values clamp to the documented bounds. A backend that predates these controls must be upgraded before the admin editor is available.

Outstanding batches and capability

A committed stop serializes against new job reservations. Jobs reserved before it, including a provider submission already in progress, cannot be retroactively unsent. Already submitted batches continue polling and ingesting completed output. Jobs > Cancel remains an explicit, separate provider operation; cancellation may leave completed output to ingest. Do not remove credentials while batches still need polling or cancellation.

The provider must expose the configured model to the configured client. Model visibility alone does not prove Batch API or structured-output support. Submission errors from the provider determine those capabilities; the system does not silently substitute a different model. A configured client is not an assurance that a generation run will succeed.

Rendering, review and old data

New scenario and rendering provenance are diagnostic-v1 and canonical-v1. New jobs retain the requested reply count, so a later settings change does not reinterpret accepted output. Ordered body text, hypothetical numbers, dates, negation, promises and subject are immutable; there is no spintax, random appended question or body humanization. Rendered turns include truthful diagnostic disclosure and the sender identity. New generated content must pass structural checks and a semantic review of the complete rendered thread before activation.

Review states distinguish passed, rejected, unavailable, unreviewed, legacy_unknown and legacy_unreviewed. An unavailable judge is not approval. Rejected or unavailable newly generated conversations stay archived and cannot be activated through the status control. Existing stored conversations and their IDs are not replaced or relabeled as reviewed; their missing historical evidence is legacy_unknown. Existing provider job IDs remain pollable. Unversioned old-job output is retained archived as legacy_unreviewed, without claiming it meets the new contract.

Vetted static scenarios use a new stable UUID namespace; historical static source IDs must never be remapped to unrelated scenarios. Exact-parent continuation, exhaustion and missing/retired source handling are required at the live dispatch integration boundary.

Live continuation binds the exact task, token, recipient receipt and received Message-ID to the provider-reported sent Message-ID. It preserves subject, immutable source/version, ordered References and the original maximum of one opening plus the requested one to five replies, including the final closure. One parent has at most one successor. An unrelated mailbox pair, an expired/retired token or unversioned legacy lineage cannot substitute for that parent. Trusted configured display names, including Unicode and punctuation, remain intact in plaintext signatures and MIME headers; CR/LF/NUL are rejected.

This application-owned correspondence proof is not itself cryptographic authentication. Updated protocol-2 Gmail/Graph workers can additionally retrieve one exact authorized warmup diagnostic's bounded MIME and verify DKIM cryptographically. IMAP, legacy workers, unrelated seed/placement contexts, unavailable MIME and transient key lookup remain unknown. Copied Authentication-Results remains unverified metadata; SPF, DMARC and receiving-hop TLS remain unknown absent independent evidence. See actual-message authentication and limits. DNS discovery and prose cannot establish pass. Received text and model output do not authorize recipients, permissions or actions.

The vetted fallback bank includes eight small causal scenarios: the original fictional clock and sample-count examples, hypothetical document review, summary correction, fixed-offset date/time continuity, plaintext label review, conditional wording and a Hungarian summary. Each preserves its own facts, alternating sender identities and explicit closure. The Hungarian body retains the same English subject-prefix and per-turn diagnostic disclosure; it does not change language controls or translate existing scenarios. Existing scenario IDs and text are immutable; a revised scenario needs a new versioned ID.

These examples review hypothetical wording, not customer documents, relationships or real actions. The plaintext example uses application-constructed written labels; it does not claim an email client passed an accessibility test. A scenario saying a check is complete does not establish a provider result, authentication pass or delivery outcome. Genuine diagnostic facts must come from separately verified, application-owned observations, never from generated prose.

Upgrade order

Apply the additive content-provenance migration before starting the new backend. Deploy every backend instance before relying on generation_enabled=false; mixed old backends do not honor the new stop or resolve the new static scenario namespace. Pause warmup dispatch through existing controls during a mixed-version rollout, and resume only after all control-plane replicas understand exact-parent resolution. Deploy the matching admin frontend after the backend. Keep provider credentials while existing jobs drain. No migration replaces saved models, existing job IDs, source IDs or customer credentials, and no live efficacy claim follows from local tests.

For the integrated release, preserve released migrations through 265 and main's workspace-link migration 266, then apply additive migrations 267 through 274 in order. Upgrade all result consumers and control-plane replicas, then execution workers. New shared dispatch requires an active worker reporting warmup_send_protocol=2; protocol 1 remains only its earlier lineage capability. Duplicate commands replay a durable terminal result rather than executing another native send. An unresolved native outcome holds the mailbox until reconciliation, not a timed blind reset. Known legacy throttle codes produce a conservative mailbox/provider cooldown without fabricated HTTP/SMTP evidence. Authentication, permanent and conflict holds need confirmed repair/operator evidence, not elapsed time or an unrelated success.

Resolving a repair hold

There is no automatic hold reset or end-user override. Pause dispatch while an instance operator investigates the exact stored organization, mailbox, configured provider, held task and reason. An unknown send must first receive a correlated definite provider result; do not change its accounting or call it failed merely to release traffic. For an authentication hold, complete the normal authenticated credential repair and independently confirm the provider now accepts it. For permanent/configuration or conflicting results, reconcile that specific provider evidence and accounting first. Record the operator, time and evidence reference in the incident audit record without credentials or message bodies.

Only then use the existing organization-scoped mailbox PATCH with send_recovery_resolution, the exact inspected held_task_id and held_reason, and typed repair/provider evidence. A newer successful sync is required for authentication repair; operator provider confirmation requires a same-mailbox definitive evidence task and reference. The guarded transaction refuses inactive/mismatched authority and any unknown task, records durable history, and preserves cooldowns and separate restrictions. See the resolution contract. Re-read admission before resuming. A changed hold or missing evidence stays restrictive. On hosted Warmbly, ask the platform operator to review; reconnecting, sleeping or another identity is not a quota/hold bypass.

Old executors remain compatible with old commands but cannot retroactively cancel work already accepted before upgrade. Pause and drain/reconcile that work before resuming new dispatch; no stronger mixed-old-worker guarantee is claimed. Correlated managed OAuth requires upgrading every Cloud control-plane replica before linked instances, as described in Warmbly Cloud. No new environment variable is required. Rollback refuses unresolved dispatches, successors, recovery restrictions or durable managed consent history rather than deleting negative state.