Platform Operations: Boundaries and Release Impact

ZaiDrama provides AI video creation as a unified hosted platform. Regular users do not install a server, configure a database, request provider API keys, or maintain infrastructure; they sign in with a platform account and use the capabilities currently exposed by the product.

This page is a public explanation of operational boundaries. It explains how releases, tasks, data, and security affect users and gives the platform team a shared external vocabulary. It is not an executable release or on-call runbook.

This page does not include production hosts, secrets, database paths, private provider contracts, or on-call contacts. Use the team's restricted runbook for releases, rollbacks, backup recovery, and security response.

1. Who this page is for

Regular users: understand how platform updates affect projects and what information to provide when something fails. Start with the getting started guide.
Platform operations and on-call staff: use this page to confirm public commitments; follow the restricted runbook for commands, dashboards, thresholds, and escalation paths.
Developers: treat these boundaries as the external contract and review the backend, frontend, tests, and docs together when implementation, migration, or capability changes are made.

2. The unified hosted boundary visible to users

Platform boundary	User-facing responsibility
Zai control plane	Unified identity, email verification, account security, subscriptions, creation credits and usage, rewards, conversation history, and creative intent
ZaiDrama service	Projects and assets, scripts and timelines, model capability execution, generation tasks, versions, the player, and project packages

Trusted Zai service context carries user identity into ZaiDrama. Projects, tasks, and temporary media workspaces are user-scoped; only platform administrators maintain provider credentials, model routing, concurrency, and operational switches.

This table describes product responsibilities, not the topology of hosts, containers, or providers. Infrastructure may change while the user-facing boundary remains stable.

3. Production capabilities and task lanes

The production service depends on these capabilities working together:

Web frontend and API service;
Zai identity and conversation services;
Persistent database plus project-file and media storage;
Generation task queue and asynchronous workers;
Public HTTPS ingress, project events, logs, monitoring, and alerts.

All generation work enters the task queue (internal component name GenerationQueue) and is scheduled by GenerationWorker across provider and media-type lanes. Image, video, and audio each maintain their own capacity and state; this is scheduling isolation, not a promise of one process per media type.

Users do not need database files, object-storage paths, container volumes, or worker hosts. Available models and parameters come from the current capability display in the product, not from old screenshots or model names.

4. Configuration and secrets

Inject production configuration through a protected deployment system. Never store plaintext secrets in the repository, frontend bundle, logs, tickets, or project content. Configuration includes:

Zai identity, service authentication, tenant context, and event signatures;
Database, project files, media storage, and callbacks;
Provider credentials, model capabilities, parameter limits, concurrency, and failover;
CORS, HTTPS, task workers, and internal control interfaces.

Use the runtime registry and administrator declarations as the source of truth for provider and model capabilities. When capabilities, limits, defaults, creation-credit mappings, or text-usage records change, review backend execution constraints, request construction, the admin UI, tests, and docs together.

Regular users select capabilities currently exposed by the platform; they do not enter provider credentials or private Base URLs. When a capability is unavailable, a model disappears, or credits or usage looks wrong, keep the project/task identifier and contact platform support. Do not upload environment files or paste keys.

5. What releases affect

The platform team handles releases, database migrations, backups, and rollbacks. Users do not operate servers and should not resubmit an entire episode to work around an update.

What to verify before a release

In an isolated environment, the operations team verifies:

Backend, frontend, and documentation checks pass;
Schema and project migrations have a consistent snapshot and rollback point;
Sign-in, dialogue, project creation, task queues, pause/resume, cancel/retry, version activation, and export work end to end;
The capability registry agrees with the actual backend constraints;
Workers, project events, task polling, logs, and alerts behave as expected.

Project-file migrations must create a consistent snapshot and validate the result before writing back; database migrations should be re-entrant. The restricted runbook should record the release version, migration state, observation window, and rollback triggers.

During and after an update

Rolling upgrades should keep existing tasks queryable and recoverable; successful artifacts must not be silently overwritten by a new version. If a page or task behaves unexpectedly after an update, provide the request, task, and project identifiers shown by the product plus the time of occurrence. The platform team then decides whether to recover, retry, or roll back.

6. Tasks, creation credits, and recovery

Terminal states arrive through project-event SSE, while polling fills intermediate states and reconnect gaps; users do not need to infer completion from a stage number.
Queued or running tasks can be cancelled. Recovery rebuilds only cancelled or missing child tasks and reuses completed results.
A selected rerun creates a new version. It becomes active only after quality and delivery review and never overwrites the current deliverable in place.
Creation credits are reserved before media generation, settled against actual use on success with unused amounts released, and released on failure. Text-call token usage is recorded separately. Reservation, settlement, and rollback must be idempotent.
Credit or usage disputes use the account service and task audit as the source of truth. Do not blindly retry or resubmit an entire episode for one affected shot.

7. Data, backups, and privacy

The platform team owns encrypted, access-controlled backups and recovery drills for the database, project metadata, media artifacts, task audits, and required configuration. Retention, RPO/RTO, and drill records belong in the restricted runbook.

A project ZIP is a single-project export, transfer, or post-production package, not platform disaster recovery. It does not include accounts, subscriptions, creation credits, text usage, global model configuration, other projects, or platform task audits.

Logs and diagnostics must not contain API keys, JWTs, passwords, email verification codes, or unauthorized source text. External troubleshooting should expose only redacted request/task identifiers and an error summary.

8. Security and network boundaries

Expose only HTTPS and required Web/API routes;
Protect calls between ZaiDrama and the Zai control plane with service authentication, tenant context, and event signatures;
In a same-host deployment, bind Zai product-control routes to loopback or the container network so the public edge reaches only ZaiDrama's user entry; validate callbacks with a time window, HMAC, and idempotency key;
For public or large multi-tenant operation, derive tenant_id only from signed context and carry it through projects, tasks, events, and artifact storage; use PostgreSQL for the ZaiDrama primary database and shared object storage for media, reserving SQLite for development/single-node use;
Keep administrator and user routes separate; never send provider credentials to browsers;
Restrict workers, media downloads, file imports, filesystem access, and subprocesses to an explicit project/task scope;
If credentials leak, users cross boundaries, or media is accessed by the wrong user, revoke affected tokens, freeze related tasks, preserve audit evidence, and escalate under the security policy.

Public docs do not show private addresses, host paths, or provider-console credentials. Any troubleshooting step that asks a user to upload an environment file or paste an API key is not a normal ZaiDrama operation.

9. Monitoring, on-call, and incident reports

The platform team should at least monitor:

Web/API availability, error rates, and post-release anomalies;
Zai bridge, project-event SSE, and task-state latency;
Image, video, and audio queue depth, duration, failure rate, and recovery rate;
Database connections, storage capacity, backup results, and credit reconciliation;
Provider authentication, rate limits, timeouts, capability validation, and cross-user access alerts;
Administrator actions, credential changes, and security-response state.

What users should provide

Provide the time, page or project location, request/task/project identifiers, reproducible steps, and the error summary shown by the product. Do not provide passwords, verification codes, API keys, environment files, private addresses, or complete source files; the platform team can continue from the identifiers and audit records.

1. Who this page is for​

2. The unified hosted boundary visible to users​

3. Production capabilities and task lanes​

4. Configuration and secrets​

5. What releases affect​

What to verify before a release​

During and after an update​

6. Tasks, creation credits, and recovery​

7. Data, backups, and privacy​

8. Security and network boundaries​

9. Monitoring, on-call, and incident reports​

What users should provide​

10. Public go-live checklist​