When Two Event Contracts Are Not the Same Contract

An index team, data provider, or risk system needs records that remain interpretable after the screen has changed. A probability without a stable event definition can mix unlike instruments; a price series without a source timestamp can hide staleness; a mapping without its review context can turn a cautious judgment into an apparent fact.

Illustrative example: one contract asks whether a policy committee cuts rates at its December meeting; another asks whether the year-end target range is below a stated level. Both concern the same policy cycle, but they are not automatically the same event or payoff. An institutional comparison begins by specifying the question, the observation time, and the contract terms that make the answer true or false.

Natural-language similarity is a discovery aid. Economic equivalence depends on the full settlement condition: outcome space, threshold, time window, authoritative source, cancellation treatment, and the consequences of ambiguous or missing information. A one-word change such as “announced” versus “effective” may move the settlement boundary by days or weeks.

Illustrative example: “Candidate X wins the election” and “Candidate X is inaugurated” can resolve differently after a death, disqualification, delayed certification, or constitutional process. A text matcher may rank the contracts as close. A verification process must surface the conditions that make their payoffs diverge before anyone interprets their prices together.

A canonical event is a stable record of the real-world proposition under analysis, separate from any one venue’s contract wording. It should say what event is being measured, identify its outcome boundary and relevant time period, and point to the authority that determines the result when that authority is known.

Canonicalization does not make the record authoritative by itself. The event can be defined locally or can reference a method maintained elsewhere. In the latter model, the reference authority governs meaning; an operational layer relates listed contracts to that reference and preserves which definition was used. Predict Here’s current external-authority workflow is architectural, not an enabled production integration.

A relationship should state what kind of connection is being asserted. Exact complements describe outcomes that exhaust the same binary proposition; mutually exclusive outcomes cannot occur together; exhaustive sets cover the stated outcome space. Other relationships may be nested, conditional, correlated, or merely similar. These labels answer different questions and should not be collapsed into one generic “matched” state.

Illustrative example: “rain in City A tomorrow” and “rain above 10 mm in City A tomorrow” are nested, not equivalent. The second implies the first only if the source, location, and time window align. A useful catalog preserves the relation type and its review status so downstream users can choose whether a particular relation is suitable for their task.

A four-state display can communicate review posture: VERIFIED, PARTIAL, NOT_EQUIVALENT, and UNREVIEWED. In Predict Here’s current mapping, VERIFIED is a reviewed VERIFIED relationship; PARTIAL is a public display of the REVIEW_REQUIRED workflow status; NOT_EQUIVALENT displays REJECTED or RETIRED; and SUGGESTED or missing relationships display as UNREVIEWED. PARTIAL therefore means further review is required, not a final partial-equivalence approval.

These labels do not replace the underlying workflow vocabulary. A system should retain both when they differ. An event-level rollup can also be more cautious than one relationship row: if a relevant contract remains unresolved, the overall event should not be upgraded merely because another pair was verified.

A contract’s resolution source is part of its meaning. Two contracts may cite separate authorities, apply different data releases, or use different fallback language when a primary source is unavailable. Even when the headline measure is the same, the source’s publication schedule, correction policy, and interpretation can alter the payout.

Illustrative example: one contract may settle from an official statistical release; another may settle from a named newswire’s report of that release. If the first source corrects its publication and the second does not specify whether later corrections count, the records can split. The comparison should retain each source reference and flag unresolved differences instead of treating the labels as interchangeable.

Time rules are economic terms. A date may mean local midnight, a named exchange close, a scheduled announcement, or a deadline stated in a particular time zone. “By Friday” and “during Friday” differ; a market that closes before a delayed publication may not observe the same information set as one that remains open.

Illustrative example: two inflation contracts may use the same monthly figure, while one asks whether it is published by 8:30 a.m. Eastern and the other asks whether it is the value shown at the end of the day. A delayed release or later revision can separate their outcomes. A mapping should record the operative cutoff, time zone, and treatment of late information where those facts are available.

Contract wording and venue rules can change after a relationship was reviewed. The comparison needs an effective version: which terms were examined, when the source showed them, and which reviewed relationship was active for the record being interpreted. Silent replacement erases the reason a historical result was reached.

A change signal is not a legal judgment. Predict Here’s collector code stores append-only observed rule/metadata hashes and can emit RULES_CHANGED; the signal says that observed source material changed. It does not automatically determine materiality, invalidate a mapping, or ingest an external authority’s new methodology. Those steps require an explicitly defined workflow.

A contract moves through a lifecycle: it may be open, paused, closed, delisted, or resolved. Those states affect whether a price is current, whether trading remains possible, and whether an observation belongs in an analysis window. Lifecycle state should be stored alongside the semantic relationship, because a correctly mapped contract can still be unusable for a particular comparison.

Illustrative example: a venue closes a contract early after a source event becomes impossible, while another venue leaves a related contract open pending clarification. Their prices no longer represent matching opportunities. A lifecycle alert can prompt review, but the alert alone does not explain the legal effect of the venue’s action.

External sources revise data. Venues can correct rules, outcomes, or notices. A sound methodology distinguishes a correction to an erroneous record from a prospective change in method, records what was corrected and when, and makes the effect on prior outputs understandable. These are different events and should not be combined into a single overwritten value.

The exact historical retention and notification policy matters. Predict Here publishes a corrections page for disclosed incidents and keeps specific append-only rule and mapping versions where implemented. It does not claim a universal audit archive or automatic notification to every recipient for every revision. Readers should inspect the correction record and the source version relevant to their use.

A comparison is reproducible only when its inputs and context travel with it. Useful provenance includes a source identifier, source as-of time, canonical event and contract IDs, relationship type and review status, mapping version, applicable methodology version, freshness or quality state, entitlement context, and a reference to the rule version where available.

These are not interchangeable version numbers. An API envelope’s methodologyVersion can identify signal or consensus processing; algorithmVersion identifies execution math on relevant price-at-size data; a taxonomy version identifies event classification. A service should state which identifier it provides on each response and avoid suggesting that every endpoint carries every field.

An external reference authority may maintain the definition or methodology for an event family. This division can preserve institutional ownership of the underlying standard while allowing a separate data layer to map venue contracts to it. The operational layer must identify the referenced authority and version, then show how a contract conforms, differs, or remains unreviewed.

This is a design principle, not a claim that a specific authority has integrated with Predict Here. The current architecture separates canonical events from venue contracts, but external methodology ingestion and dedicated reference-authority version fields are not enabled in production.

A benchmark or research process should define inclusion rules before comparing prices: which relationship types qualify, which semantic states are acceptable, how stale or degraded sources are treated, and what happens when rules or lifecycle signals change. The resulting benchmark methodology should disclose its reference definition, effective version, source entitlements, and unresolved exceptions.

Price comparison should follow semantic verification, not precede it. For institutional use, a cautious “not comparable” or “review required” state can be more valuable than a larger but ambiguous sample. The framework in this paper organizes those decisions; it does not claim that Predict Here has solved all event-market standardization or that every described control is already in production.