Give a forecast
the evidence it deserves.

Use the narrative briefing and structured JSON together. The narrative should explain the decision context; the JSON should preserve precise, time-stamped facts and comparable events. Neither should include information that was unavailable at the cutoff.

Two different leakage risks: post-cutoff or lookahead leakage supplies information that was not available at the forecast cutoff. Recognition leakage lets the model infer the event identity from otherwise timely clues and retrieve an outcome learned elsewhere, including during pretraining. Enforce the information cutoff and review for recognition clues.

Review every model-visible surface

For historical training and contamination-aware evaluation, avoid event names, identifying narrative, real entity names, URLs, public IDs, and distinctive combinations of facts or dates that fingerprint the event. Apply this review across the question, narrative briefing, all JSON keys and values, event IDs, fields, source and provenance text, outcome labels, assumptions, and examples—including comparable and adjacent events. Do not merely anonymize the headline while leaving an identifying description elsewhere.

Use local neutral labels such as event_001 and entity_A, with structured predictive attributes: event type, relevant base rates, pre-cutoff measurements, constraints, incentives, and uncertainty. Labels must not encode public identifiers or outcomes. Preserve the information needed to predict, not a recognizable historical story.

Keep a separate audit record: store original identifiers, source URLs, full provenance, label mappings, and any preprocessing decisions outside the model-visible packet. Do not paste that record into a briefing or JSON provenance field. Model-visible provenance should contain only non-identifying descriptions of evidence quality or collection method. This separation is a data-preparation responsibility, not a promise that LEMs automatically redacts submitted fields.

Example: retain the signal, remove the fingerprint

Avoid: “Will [named retailer] repeat its widely reported holiday launch result on [distinctive date]?” Renaming the retailer to “entity_A” but keeping that story or a news URL still identifies the event.

Prefer: “For entity_A, which demand band applies at the target time?” Supply structured pre-cutoff attributes such as promotion_active: false, inventory_index: 0.91, and comparable local event records. Define the low/base/high thresholds in advance. Keep the original retailer, launch description, and source links only in the separate audit record. This is an illustrative rewrite, not a guarantee of anonymity.

Preserve the timestamp contract and chronology

Distinctive dates can reveal identity, but lems.forecast-context.v1 still requires ISO 8601 timestamps in its timestamp fields. Do not replace forecast_time, target_time, observed_at, or available_at with relative strings such as “day -7.” Only use chronology-preserving date preprocessing when explicitly supported by your data pipeline and evaluation design; preserve ordering, elapsed intervals, availability at or before the cutoff, and relevant seasonal information, then validate the resulting schema-compliant packet. Record transformations separately for audit. If safe preprocessing is not supported, retain valid timestamps and disclose the residual recognition risk rather than silently changing dates or claiming anonymity.

Evaluate beyond anonymization

Anonymization cannot guarantee that an event is unrecognizable. Use event-grouped train/validation/test splits so variants, repeated forecasts, and related records of the same underlying event do not cross splits. Grouping does not remove an outcome already learned in pretraining: complement historical tests with prospective evaluation on genuinely unseen, unresolved events, recording forecasts before outcomes become available. Keep each target's realized outcome out of its model input; training targets and evaluation answers belong in their designated label or scoring channel. Comparable-event outcomes are evidence only if known by the forecast cutoff.

Live forecasts are different: forecasting a real, unresolved event can legitimately require its identity and precise context. Do not remove decision-relevant information indiscriminately. For historical training and contamination-aware evaluation, prioritize predictive conditions over recognizable identity and document any unavoidable exposure and its limits.

Forecast Studio accepts a typed evidence packet defined by lems.forecast-context.v1. Use ISO 8601 timestamps. Every evidence event should have an ID, type, observed time, fields, and—when it became knowable—available_at. That availability time must be at or before forecast.forecast_time.

{
  "schema_version": "lems.forecast-context.v1",
  "forecast": {
    "event_type": "retail.weekly_demand",
    "forecast_time": "2026-08-01T14:00:00Z",
    "target_time": "2026-08-08T00:00:00Z",
    "question": "Which demand band will apply next week?",
    "output": {"kind": "categorical", "values": ["low", "base", "high"]}
  },
  "same_type_events": [{
    "event_id": "event_001", "event_type": "retail.weekly_demand",
    "observed_at": "2026-07-25T00:00:00Z", "available_at": "2026-07-25T00:00:00Z",
    "fields": {"promotion": false, "inventory_index": 0.91}, "outcome": "base",
    "source": "internal weekly demand record"
  }],
  "adjacent_events": [],
  "assumptions": ["No unannounced promotion before the target week"],
  "provenance": {"collection_method": "weekly aggregate measurement"}
}

Formatting rules: valid JSON uses double-quoted keys and strings, no trailing commas, and no comments. Keep raw evidence in fields; use outcome only for resolved historical events. Never place credentials, customer secrets, or post-cutoff facts in the packet.

Define the uncertain event first, then use one exhaustive outcome set and the same evidence for all candidate actions. Enter the value of each action under each outcome. Decision Studio compares expected values; it does not guarantee an outcome or replace approval controls.

Account owners and authorized billing administrators manage organization access, payment methods, auto recharge, credit packages, receipts, invoices, statements, notifications, and API keys. They can inspect the full immutable credit ledger and download monthly or custom-period CSV/PDF statements for their accounting teams.

Failed or unsettled payments do not create credits; a reversal can stop paid work or make a credit balance negative. A verified payment chargeback is different: it suspends the tenant, stops paid work, and leaves account owners/billing administrators read-only access to the ledger, statements, receipts, dispute status, and remediation workflow until a server-authorized resolution.

This guide supports effective use of LEMs. Results depend on the quality and timing of evidence, sound outcome/value design, implementation discipline, and ongoing evaluation.