Event record schema

The full shape

{
  0: {
    1: 2,
    3: {
      4: 5,
      6: 7,
      8: 9,
      10: 11
    },
    12: 13,
    14: 15,
    16: 17,
    18: {
      19: 20,
      21: {
        22: [23, 24, 25],
        26: 27
      },
      28: 29
    }
  },
  30: [
    {
      31: 32,
      33: 34,
      35: 36,
      37: {
        38: { 39: 40, 41: 42 },
        43:  { 44: 45,  46: 47 }
      },
      48: {
        49: 50,
        51: 52,
        53: 54,
        55: {
          56: 57,
          58: {
            59: [60, 61, 62],
            63: 64
          },
          65: 66
        },
        67: 68
      },
      69: {
        70: 0.62,
        71: 0.39,
        72: 73,
        74: 75,
        76: 142351.20,
        77: 4821550.00,
        78: 4,
        79: 9,
        80: 81
      },
      82: {
        83: true,
        84: 1.8,
        85: 86,
        87: 88,
        89: 90
      },
      91: 92
    }
  ],
  93: {
    94: 95,
    96: 97,
    98: 99,
    100: true,
    101: true,
    102: 103
  }
}

Top-level fields

The event block

The interpretive fields

Two fields in the schema are interpretive: aggregate_event_relevance at the event level and news_effect.relevance_score at the per-market level. Both carry their own definition field stating what they are and, explicitly, what they are not. The text in these fields is part of the public schema; we do not change it without a versioning event.

Estimated relationship strength between the event and the referenced market outcome. This is not a probability, expected return, confidence level, or trading signal.

The values are simple levels (low, moderate, high) rather than numeric scores, by design. The product is interpretive, not quantitative. Levels keep you from reading too much into a 0.7-vs-0.8 score that doesn't exist, and leave the precise weighting to you.

The news_effect block

The market_snapshot block

A snapshot of the market at the moment the event was processed, included for reference and mapping only. The note field says so explicitly. Do not treat it as a live price feed; the WebSocket is the live feed.

The momentum tag

Each related market may carry a momentum object, the field most consumers filter on. It flags whether the related market visibly movedaround the event, inside our latency window, by more than this category's threshold, marking a higher signal-to-noise subset of the feed. It is explicitly descriptive, not predictive: it says the market reacted, not that any position would profit.

The whole momentum object is null until the gate logs the event (about a minute after publish), or when no live price existed at event time. To consume only the tagged subset, filter on momentum.passed. What it is not: not a probability, not an expected return, not an accuracy or win-rate claim, not a trading signal. Net of the bid/ask spread the tagged subset is not, in itself, a profitable strategy. It is a signal-to-noise filter for your own analysis.

Known limitations at v1 launch

A few field-level and record-level limitations exist on the v1 payload that you should design around. This section captures the user-visible shape.

Versioning

Schema version is reported at meta.schema_version. Breaking changes ship under a new URL prefix (/v2/); non-breaking additions ship in-place. Additive changes you should expect to see ship without a major bump: new optional fields on existing objects, new credibility tiers, new venue identifiers.

What Vera is not

Repeating from Overview because it bears repeating in the same place a developer reads the schema for the first time: the output is informational and interpretive. It is not investment advice, not a trading signal, and not a recommendation. The interpretive fields are simple low / moderate / high levels and carry self-documenting definitions stating as much. Build accordingly.