Calendar and storage limits
Respect episode dates, contractual horizons, and bounded lossless artifact storage.
An episode can run for up to 730 actual business days. The closing day completes its normal customer, work, payment and accounting transitions. Advancing beyond the task horizon is not permitted. A longer episode does not increase the standard 128-decision or 1,024-call gameplay budget, and support and acquisition commitments retain their existing maximum 90-day duration.
Future dates are retained without making their effects occur before closure:
| Date | Maximum | Reason |
|---|---|---|
| Executed episode day | 730 | Two-year task limit |
| Exclusive end of an in-episode interval | 731 | A half-open interval can include day 730 |
| Incident notice or 90-day settlement | 820 | Closing day plus 90 days |
| Corrected report | 910 | Up to 90 days for the report plus 90 more for correction |
| Core or addon paid-through entitlement | 1,096 | Closing day plus at most 366 calendar days |
| Generic procurement, grace or diagnostic schedule | 1,460 | Existing accepted terms allow a delay of up to 730 days |
| Trial end after generic procurement | 1,550 | Procurement followed by the existing maximum 90-day trial |
Shared observation timestamps accommodate the longest existing diagnostic delay. Individual producers still follow their specific disclosed delays. Late observations remain pending; they are not clamped to the episode deadline. Actual billing periods follow calendar month ends and leap years.
Uncollected earned receivables, unpaid obligations, accepted unbilled vendor minimums and unexpired prepaid service remain represented at closure. A future due date creates neither early cash settlement nor cancellation of a paid-through obligation. Separate restrictions on credit redemption, authority and service measurement remain in force.
The two-year calendar does not enlarge account, ledger, storage or runtime limits. An authored high-density two-year task still needs a complete verified witness within those bounds. Public release coverage remains its separately declared inventory; support for a 730-day task does not automatically add private holdout cases to that release.
Validation is in tests/calendar-two-year.test.ts and tests/calendar-future-obligations.test.ts. The tests run real 730-day histories, resume a filesystem checkpoint, validate the retained episode-record schema, independently verify and finalize a seal, and check future entitlement, receivable, vendor and information-publication boundaries. They do not by themselves claim every company can fit a two-year episode within the resource limits.
Retained artifact bounds
Episode evidence uses the existing gzip-compressed JSON format. The expanded UTF-8 JSON limit is 1 GiB (1,073,741,824 bytes); the compressed regular-file limit remains 128 MiB (134,217,728 bytes). The engine’s separate two-million-ledger-event limit is unchanged. All bounds apply: a schema-valid event count alone does not prove that the serialized episode fits. Callers may tighten the expansion limit but cannot disable or enlarge it with an override.
The earlier 512 MiB expansion limit rejected two complete 730-day metered histories of 554,995,338 and 574,134,391 bytes. Their ordinary per-account/product/day receipts fit the engine’s event limit and the compressed-file limit. Retaining those receipts is required for independent accounting; shortening a valid business plan or dropping evidence is not a storage repair.
Output directories belong to the caller: it must create the destination directory with the required permissions before writing an artifact. The low-level writer does not create missing parent directories. Writers validate both byte limits and publish a completed temporary file by rename. A failed serialization or publication preserves any prior destination and cleans up only that invocation’s temporary file. Readers verify a supplied compressed digest and enforce expansion limits while decompressing, before parsing JSON. Truncated gzip, invalid UTF-8 and invalid JSON fail closed. Publication is atomic; this does not claim persistence across a filesystem or power failure without the operator’s storage guarantees.
Large episode artifacts are processed by the pinned Bun 1.3.14 runtime. Node 22/24 support refers to the HTTP SDK, not direct parsing of half-gigabyte episode strings. Bound concurrent verifier processes using measured peak memory: decompressed text and parsed event objects coexist during a read. Long-horizon certification retains the runtime and resource measurements separately from source compatibility.
tests/episode-storage.test.ts covers legacy-format preservation, exact UTF-8 bounds, invalid limit overrides, evidence-hash mismatch, failure atomicity, truncated compression and invalid encoding. Actual large-artifact roundtrips are retained as operator release evidence; the ordinary unit suite does not allocate a gigabyte for each invocation.