Fairness, limits, and retention

Durable work is decomposed into bounded quanta and scheduled using estimated cost across tenants, then active runs. A five-second aging threshold prevents an admitted run from losing every scheduling decision; users cannot self-assign priority.

Current request limits bound a run to 1–1,000 items, a 5 MiB body, and 100,000 declared result cells. Interactive overload returns 429 with Retry-After. An admitted run continues independently of its creating client.

Each chemical-space worker has separate capacity pools for low-latency default Morgan search, slower singular work such as CHEESE, native substructure, and sampling, and durable run execution. The operation and scorer choose the pool; callers cannot assign themselves a higher-priority lane. This keeps slow singular work and admitted durable runs from consuming the default Morgan slot. Default and slow pools currently have one slot per worker. Durable execution capacity is a deployment control, not caller-selectable priority. Each basic run item has a hard 60-second execution limit.

Run admission atomically reserves the following in-flight budget for the authenticated tenant:

These are concurrency safeguards, not billing counters. The complete reservation is released when the run becomes terminal, including after cancellation. A request that would exceed any current tenant budget returns retryable 429 tenant_run_quota_exceeded with Retry-After: 5; another tenant's reservation does not consume your budget. GET /api/v2/catalog is the authoritative machine-readable source in case limits change.

Compatible items may be coalesced only after fair selection and privacy review. Selection quantum and engine batch size are separate deployment controls. Successful four-item batches commit item results, run progress, and ordered events atomically; metadata-sequence races retry the atomic batch before falling back to conditional, idempotent per-item commits. Coalescing is an execution optimization, never a cross-tenant chemistry result cache. Production may tune the quantum and batch controls independently without changing the public contract.

The retention policy is 30 days, reported as expires_at. Run metadata, inputs, results, items, idempotency markers, and events carry the same expiry. DynamoDB expiry is asynchronous, so records may remain physically present for a short period after that timestamp but are no longer an active run contract. All reads remain tenant-authorized. Raw structures and hit tables do not enter general logs, metrics, events, analytics, or docs tools.