SGA‑OISOpen Interoperability Standard
1.0 Draft
SGA-OIS/Specification

Provenance

Normative.

Two devices report ball_speed_mps: 71.3. One measured it with Doppler radar. The other looked it up from club type and a swing-speed estimate.

Those are not the same number. A system that treats them as the same number cannot produce a defensible player rating, cannot settle a tournament dispute, and cannot tell a manufacturer anything true about their equipment.

Provenance is the field that makes the difference visible. It is the part of this standard with no equivalent in any existing simulator protocol, and it is why the data is worth more than the sum of the sensors.


1. The three tiers#

tiermeaningrequired attribution
measuredA sensor on this device directly observed this quantity on this shot.—
calculatedDeterministically computed from other quantities measured on this same shot.from: the fields used
inferredEstimated using assumptions, models, or history not measured on this shot.model: named and versioned

The dividing line between calculated and inferred is not "was there math." It is: if you re-ran it on a different shot with the same inputs, would you get the same answer for a knowable reason?

  • Smash factor from measured ball speed and measured club speed is calculated. It is division.
  • Carry from measured ball speed, launch angle, and spin, through a published ballistics model, is calculated. The inputs are all real, and the model always gives the same answer for the same inputs and can be disclosed.
  • Spin estimated from club type and ball speed because the device has no spin sensor is inferred. There is an assumption in there about a golfer who is not necessarily this golfer.
  • Club speed back-solved from ball speed via an assumed smash factor is inferred, and this is the one vendors most often present as if it were measured.

A fourth value, absent, means the device cannot supply the field at all. Absent is honest and costs nothing. Guessing and calling it measured is the only real failure, and it is the thing certification exists to catch.


2. Provenance is declared once, not per shot#

Provenance is a property of the device, firmware, and configuration — not of the individual shot. A launch monitor that measures ball speed measures it on every shot; it does not measure it on Tuesdays.

So provenance lives in the capability descriptor, exchanged once at handshake and signed. Shot records carry values, plus a manifest hash pointing at the descriptor that was in force. Consumers resolve provenance by lookup.

This matters for three reasons:

  1. Wire size. Per-shot provenance roughly doubles a shot record for information that changes approximately never. The standard has to be fast enough for the shot to reach the simulator without the golfer noticing.
  2. Tamper resistance. The descriptor is signed once. A per-shot field is a per-shot opportunity to lie.
  3. Auditability. "What was this device claiming to measure at 14:22 on September 5th" resolves to exactly one signed document.

2.1 Per-shot downgrade#

A field can genuinely degrade mid-session — a camera blocked, a radar losing lock, a device falling back to estimation. That is reported as an explicit, exceptional downgrade:

JSON
{
  "shot_id": "sga:shot:01J9X4...",
  "manifest": "sha256:7a3f...",
  "ball": { "speed_mps": 71.3, "spin_rpm": 2698 },
  "downgraded": { "spin_rpm": { "provenance": "inferred", "reason": "no_spin_lock" } }
}

Rules:

  • Provenance may only ever be downgraded at runtime, never upgraded. A device that declared inferred cannot claim measured on a good shot; if it can measure, it declares measured and downgrades when it cannot.
  • A downgrade MUST carry a reason from the registered vocabulary.
  • Sustained downgrade — a threshold set in the competition ruleset, not here — is a certification and integrity signal, not just a data-quality note.

3. Descriptor form#

JSON
{
  "field": "ball.spin_rpm",
  "provenance": "measured",
  "resolution": 50,
  "unit_note": "rpm, per 00-conventions",
  "conditions": ["requires_ball_marker"],
  "latency_ms": 180
}
JSON
{
  "field": "club.speed_mps",
  "provenance": "inferred",
  "model": { "id": "acme.smash_estimate", "version": "2.1" },
  "confidence": 0.6
}
JSON
{
  "field": "ball.carry_m",
  "provenance": "calculated",
  "from": ["ball.speed_mps", "ball.launch_angle_deg", "ball.spin_rpm"],
  "model": { "id": "acme.flight", "version": "7.0" }
}
  • model.id is namespaced to the vendor. The model does not have to be published; no vendor will hand over their ballistics. But it MUST be named and versioned. That is what lets a change in results across a season be attributed to a model change rather than to a player.
  • confidence on an inferred field is the vendor's own stated reliability. It is a claim, not a measurement, and consumers should treat it as such.
  • conditions declares what has to be true for the field to be valid at its declared provenance — a marked ball, a lighting range, an indoor requirement. A device operating outside its declared conditions is operating outside its certification.

3.1 Provenance belongs to a firmware build, not to a product#

The descriptor is signed by the device and carries firmware and firmware_digest. That is not only an anti-tamper measure — it is what makes the model survive contact with how hardware is actually shipped.

Manufacturers routinely ship a product without a feature they intended, then add it in firmware. A value that was inferred at launch becomes measured two years later on the same model number.

So a fleet is mixed, and the vendor's website cannot describe it. Ten thousand units of one model may be calculating a value while two hundred freshly updated units measure it. A product page states one thing. Reality is two populations at once, and it keeps shifting as owners update at their own pace.

The device declares its provenance at runtime, keyed to the firmware build it is actually running. So the record is right in every one of those cases, and nobody has to maintain a compatibility table. Three consequences worth naming:

  • Historical re-analysis becomes a query. "Re-rate every shot where spin was measured rather than modeled" is answerable across a fleet in mid-migration, years later. Without runtime provenance it is unanswerable at any price, because the information was never recorded.
  • It catches a corruption nobody would otherwise notice. If a firmware update silently improves how a value is obtained, a player's statistics shift for reasons that have nothing to do with their golf. With provenance and firmware digest on every shot, that discontinuity is visible and correctable instead of being absorbed into their player rating.
  • It is a product we can hand back to the manufacturer. What fraction of your fleet runs which firmware, and what that does to data quality, is information no vendor can currently obtain about their own installed base. Nobody else is positioned to produce it.

4. Why this is worth the trouble#

Player rating. A player rating needs score, not ball speed, so provenance is not on the critical path for the first release. But the integrity checks around a player rating have to separate "this player's numbers changed" from "this device's model changed." Without provenance, that distinction cannot be recovered after the fact.

Tournament forensics. When a result is disputed, the question is always "what actually produced this number." A signed capability descriptor plus a manifest hash on every shot answers it in one lookup, months later.

Equipment data. Aggregate shot data is only commercially meaningful if you can filter to directly measured values. A dataset that silently mixes measured and modeled spin is worth close to nothing to a ball manufacturer, because the modeled rows encode the sensor vendor's assumptions, not the ball's behavior. Provenance is what makes the corpus saleable.

Certification. A device's declared provenance is a testable claim. The conformance kit checks a device against reference shots and verifies it declares no more than it can demonstrate. That is the difference between a certification that means something and a sticker.


5. The one rule vendors will push on#

A device MUST NOT declare a higher provenance tier than it can demonstrate under the conformance suite.

Expect resistance, because marketing pages routinely present inferred club data as measured. The standard's answer is not to argue about the marketing: a device may present whatever it likes to its own users. What it emits over SGA-OIS is a technical claim, tested, and certification depends on it.

This is also the friendliest possible framing for a vendor with real sensors, and they are the vendors we most want first. A manufacturer who genuinely measures spin has spent money to do it, and today competes against spec-sheets that imply everyone measures spin. Provenance is the first mechanism in this industry that lets them prove the difference. The best hardware in the market has a commercial interest in this standard existing. That is the opening line of the partnership conversation.

Simulated Golf Association · SGA-OIS · generated from the specification sources