Give a forecast
the evidence it deserves.

New forecasts accept only lems.forecast-context.v3: declared numeric, categorical and timestamp data, with an explicit output variable and domain. Free-text questions, briefings, URLs, quotes and provenance do not enter the prediction packet. Chat can help prepare the data, but stays outside it. Category labels may be ordinary words or multiword Unicode text; they are declared data, not instructions. Identifiers retain their constrained grammar. Preserve all decision-relevant measurements, uncertainty and contrary evidence without adding padding or adjusting probabilities.

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 codes such as event_001 and entity_a, with declared typed predictive attributes: event type, relevant base rates, pre-cutoff measurements, constraints, incentives, and uncertainty. Codes must not encode public identifiers or outcomes. Preserve the information needed to predict, not a recognizable historical story. Short-code syntax is not a semantic natural-language detector.

Keep a separate audit record: store original identifiers, source URLs, full provenance, label mappings, and preprocessing decisions outside the model-visible packet. Do not paste that record into prediction data. A source handle is a constrained code; evidence quality and collection method, when material, require separately declared categorical or numeric variables, not descriptions. 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: discuss the target with the assistant outside prediction data, then supply declared pre-cutoff attributes such as an integer promo_active flag with value 0, numeric inventory value 0.91, and comparable local event records. Declare any categorical bands and their exact meanings before forecasting; there is no separate resolution object. Keep the original retailer, launch description and source links only in the separate audit record. This is illustrative data preparation, not a guarantee of anonymity.

Preserve the timestamp contract and chronology

Distinctive dates can reveal identity, but lems.forecast-context.v3 requires explicit RFC3339 timestamps or supported start/end uncertainty ranges. Do not replace time fields with relative strings such as “day -7,” or turn a date-only source into an exact instant. Only use chronology-preserving date preprocessing when explicitly supported by your evaluation design; preserve ordering, elapsed intervals, availability at or before the cutoff, seasonal information and uncertainty, then validate the packet. Record transformations separately. Otherwise retain honest timestamps/ranges and disclose residual recognition risk rather than 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.

The only new-inference version is lems.forecast-context.v3. Download the complete executable synthetic example and JSON Schema. The six required root keys are schema_version, variables, forecast, same_type_events, adjacent_events, and factors. Older saved results may be viewed historically; their packets cannot be resubmitted as new forecasts.

Declare every field

A variable is integer, number, categorical, timestamp or timestamp_range. Categories are user-defined strings of 1–100 Unicode code points, including spaces, punctuation, emoji and non-Latin text, such as Higher demand 📈 or 東京 / 大阪. Each ordered domain contains 2–100 unique labels; field and outcome values must match exactly. Use one category control per label: commas, quotes and backslashes are literal characters, not separators. Visual definitions apply NFC normalization and trim surrounding whitespace. Imported canonical JSON must already be NFC and trimmed: blank labels, controls, lone surrogates and line breaks are rejected without rewriting the document. Invisible format controls are rejected except supported ZWNJ/ZWJ joiners. Variable, event, unit and source IDs retain the constrained code grammar. Binary uses two declared string labels, not JSON booleans. Numeric measurements and numeric historical outcomes remain numbers. Missing data is omitted, never null, invented zero or arbitrary nested prose.

Preserve source equality and honest time precision

Every known target field requires an evidence_refs reference to an evidence record containing the exact same typed value. Evidence records require unique IDs, types, observed_at, available_at, a short source handle, and typed fields. Both times must precede or equal the cutoff. Use RFC3339 timestamps with seconds and explicit offset. A date-only observation becomes an explicit start/end uncertainty range, not an invented midnight observation. All of the range must fit before the cutoff, and observed/available ranges must prove ordering or be identical uncertainty windows. Source handles refer to an audit/provenance record outside the packet; URLs, source titles, excerpts and chat never become prediction data.

Define the target and outcome domain

The event type, information cutoff, target time and output variable define the target. Target time may be a timestamp or an increasing {start,end} range entirely after cutoff. In Visual editing, select timestamp or range and enter UTC times; both range endpoints commit together. The output contains either exact declared category labels or a bounded numeric lattice; measurement units belong in the variable declaration. There is no resolution object, operation selector or substitute policy-factor engine. Use explicit categories for no-event, timing bands or overflow instead of disguising them as exact numeric observations. Numeric bounds describe possible outcomes, never probability caps.

Same-type events have exactly the target event type and a known outcome: {variable, value}. Adjacent events and factors have different types; they retain relevant measurements but are not relabelled as completed trials. Empty evidence arrays are valid: do not pad the record to reach a minimum analogue count. The backend validator checks declarations, exact domain membership, typed source equality and chronology beyond JSON Schema. Visual and JSON edit the same canonical document.

Prediction request

{"maximum_tokens":32,"evidence":{"structured_context":PACKET}}

PACKET above is a schematic placeholder for the full downloaded object, not a JSON string. Do not add an outer question, briefing, output or possible_values. All examples are synthetic educational data, not verified sources, empirical base rates or calibration claims. Loading an example does not generate probabilities.

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.