Governance of SGA-OIS

Status: draft, pending adoption.

The goal is a standard that a vendor can ship inside a commercial product without asking anyone's permission, that no single vendor can fork into a private dialect, and that vendors themselves get to extend.

Those three goals pull against each other. The resolution below is the one most hardware standards bodies use for their compliance marks: the body controls the mark. SGA goes further than most and gives the specification itself away.

The split that makes it work#

Anyone may implement SGA-OIS. Anyone may ship it. Only SGA may say something is SGA Certified.

Locking the copyright would defeat the redistribution that makes a standard worth adopting in the first place, so the copyright is open and the mark is not. Nothing is needed from SGA to build, ship or sell a product that speaks SGA-OIS. The mark says a product passes the conformance suite, which anyone can run in private, and proves who it is by signature, at trust level A2 or higher (what SGA Certified means).

What a technology partner agrees to#

Using the standard needs no agreement. Becoming a technology partner, which is free, means accepting the Technology Partner Agreement. It asks four things: report data as it really happened, label how each value was obtained, never build a feature that lets a player cheat, and tell SGA promptly about any defect or exploit you find that could make a product report false data. That commitment, plus a published digest of each release, is trust level A1, where rounds start counting toward an SGA Player Rating (trust levels). The signing levels, A2 and A3, add the Conformance & Endorsement Agreement.

The anti-fragmentation clause#

The failure mode to design against is SGA-OIS settling into a second-class path, with the good data kept on a private channel beside it — "there's the proprietary way and the open way." That is how open standards die, and it usually happens by drift rather than by decision.

So, as a condition of certification, not of licensing:

A certified device MUST expose through SGA-OIS every capability it exposes through any other interface on the same unit. A field a device will emit on a proprietary channel is a field it MUST declare and emit on SGA-OIS, at the same provenance and no worse resolution or latency.

A vendor that also maintains a private interface may keep it, provided SGA-OIS is never the lesser of the two. And this is a certification condition rather than a license term for a specific reason: the consequence is that a product is not certified, and never a legal action. SGA does not sue implementers, and the license deliberately gives it no grounds to.

The same clause, closed on the inside#

The rule above says a capability must be exposed through SGA-OIS, and read strictly that is also satisfied by a vendor-namespaced field — the minimum core needed to operate, with everything else under x-<vendor>.. Every letter is met and very little is interoperable, which is nobody's intent but is easy to arrive at one release at a time. So the condition has a second half:

Where a ratified core field covers a capability, a certified product MUST emit the core field. Emitting a richer vendor-namespaced version alongside it is welcome. Emitting only the private spelling is not.

This costs nothing to implement, because the value is already being produced — it is only a question of which name it goes out under. What it prevents is a standard that fragments through its own extension mechanism rather than around it.

And if the core field genuinely does not fit — wrong unit, wrong semantics, too little resolution — that is a Tier 2 proposal, and the committee wants it. A vendor with a shipping implementation is already holding most of what a proposal requires. A gap nobody reports is a gap that never gets fixed.

Normative text: spec/00 §5a.

Own equipment, or everyone's#

A vendor that makes more than one part of a bay may want its products to work only with each other. That is a decision about its own equipment, and the standard leaves it to the vendor. What the standard does not allow is picking favorites among everybody else:

For each device role it connects to, a certified product MAY limit that role to its own vendor's devices. If it accepts that role from any other vendor, it MUST accept it from every conforming device.

Each product decides for itself, whether it is a device or software. A vendor's simulator may work only with its own launch monitor while that same launch monitor is open to every simulator. The simulator may still accept any club sensor or camera. But a simulator that accepts one other company's launch monitor accepts them all.

Two conditions keep this honest. A product may limit only a role in which its vendor ships a device of its own: "own-only" for a kind of device the vendor does not make would simply mean "none", and a simulator refusing every club sensor or RFID bag is not pairing its own products, it is shutting the player's equipment out. And the limit is declared, never silent: the product states it when it connects, and the bay tells any device it excludes why. Normative text: spec/03 §2.1c.

Why all or nothing. Pairing one's own products is a product decision. Choosing which competitors to admit is a commercial arrangement, and a market that divides one partnership at a time is the fragmentation this standard exists to end. A player or a facility can see and plan around "this simulator works with its own launch monitor only". They cannot plan around a list of private deals that changes every season.

Carrying the standard forward#

A second condition of certification, cheap for the vendor and load-bearing for everyone:

A certified product that installs software on a bay host MUST ship two files in every package — updates as well as first installs — and its installer MUST replace either one on the device when the copy it carries is newer. The two are the engine updater and the current standards bundle, and both MUST sit in the same folder as the installer when it runs. "Current" means no more than two bundle releases behind at package build time. Products that install no host software are exempt.

Two files, versioned and compared independently. They fail in opposite directions, which is why neither alone is sufficient: a bay with a current bundle and a two-year-old engine cannot read the standard it is holding, and a current engine with a stale bundle does not know the fields that have shipped since. Each carries its own version, and the installer touches only what is actually older — so a vendor shipping an already-current pair moves nothing.

Neither file can regress the other's work, and neither can regress its own: a shipped copy older than the one on the device is a safe no-op, because the highest verified version always wins.

Size is SGA's obligation, not the vendor's: SGA keeps both the engine and the standards bundle as small as it can.

This does not make SGA a silent code-distribution channel. The distinction in spec/04 §4 holds exactly as written. The bundle is declarative data and applies silently at runtime. The updater is executable, and it moves only when a person runs a vendor's installer — the ordinary consented channel the platform already provides. Nothing in this clause lets SGA push a binary to a bay.

The effect is that every participating vendor's update channel becomes a distribution channel for the standard, so a bay with no internet is brought current by whoever happens to update anything on it.

This is the clause that makes the ecosystem maintain itself rather than depending on SGA reaching every machine. See spec/04-bundle-distribution.md.

Two deliberate carve-outs, so this stays reasonable:

1. Vendor-internal diagnostics and calibration are out of scope. A device's own service tooling is not a capability under this clause.
2. Contractually restricted data (a manufacturer under an OEM agreement that forbids redistribution of some field) may be declared as restricted in the capability descriptor rather than omitted silently. Declaring it is the requirement; silently omitting it is what the clause is there to prevent.

Extending the standard#

Velocity matters more than tidiness at this stage, so extension is permitted immediately and promotion is what gets reviewed.

Tier 1 — vendor extension. No permission needed, ship today. Namespaced: x-acme.ball.spin_tilt_deg. Any vendor may define any field in their own namespace and emit it immediately. Conformance ignores unknown x- fields; a consumer that does not understand one skips it. Nothing about adding a vendor extension can break another vendor.

Tier 2 — candidate. 30-day public comment. When a vendor wants a field in the core namespace, they open a proposal: the field, its unit, its provenance semantics, its sign convention, why an existing field does not cover it, and at least one shipping implementation. It goes to a public list. Other technology partners and SGA comment for 30 days. Silence is consent.

Tier 3 — core. Ratified into a numbered release. The Technical Steering Committee ratifies. Core fields are permanent: they may be deprecated but never removed and never redefined. A consumer written against v1.2 keeps working against v3.0.

Technical Steering Committee. Seats for implementing vendors — hardware and software both — plus SGA. SGA holds the tie-break and the veto on anything that would break backward compatibility or weaken the provenance model, and nothing else. SGA does not get to veto a field because it is commercially inconvenient to SGA. That limit is written into the governance rather than left to good intentions, because neutrality only means anything when it is visible: everyone is better served by a standards body whose own constraints are on the record and can be checked against its conduct.

Fast path. A new sensor class shipping in 60 days cannot wait for a 30-day comment cycle plus ratification. It ships as a vendor extension on day one and promotes later. The standard should never be the reason a product slips.

The key SGA signs with#

Ratification produces a bundle, and a bundle is signed. Everything in this standard that says "signed by SGA" rests on one Ed25519 key pair: the public half is pinned into every engine build, and the private half is the association's authority over what the standard says.

How that key is handled is therefore a governance question rather than an implementation detail. These are commitments, not aspirations.

• Generated offline. The key is created on a machine disconnected from any network, and the private half never touches a build server, a repository or a continuous integration system.
• Two copies, in separate custody. One in a secret store, one offline and physical, held where a second person can reach it. A standard only one person can publish is a single point of failure, and SGA treats it as one.
• Signing is a ceremony, and it is recorded. Named steps, run deliberately, with a log of when a ceremony ran, who ran it and which bundle resulted. The log never contains the key.
• A key that is not published cannot sign. The tooling refuses to sign with a key that is not already pinned and committed, and the last check of any signing run verifies the result against the pinned key rather than against a key file — so what it proves is that an ordinary engine build accepts the bundle.
• Rotation is signed by the outgoing key, distributed in a bundle like anything else, with an overlap measured in years (spec/04 §3). A root compromise therefore requires a client update. That is deliberate: recovering from a root compromise should be hard to do quietly.

What SGA publishes, and what it does not. The commitments above are public. The runbook implementing them is not, because it names where copies are kept.

That asymmetry is the ordinary one, and it is not where the trust comes from in any case. You are not asked to take this process on faith — you are asked to check the output, and the verification guide is how. Verify the signature to establish who issued a bundle, then rebuild it from this repository to establish what is in it. The second check holds even against a compromised signing key: a bundle whose contents were altered does not reproduce, however impeccably it was signed.

What SGA Certified means#

A product carries the SGA Certified mark when it passes the conformance suite and reaches trust level A2 or higher, with its signature verified by SGA. Any product from any vendor can earn it, hardware or software. It is the level of trust that earns the mark: not an endorsement, not a quality rating, not a competitive ranking, and not for sale. No commercial relationship with SGA has anything to do with whether a product earns it. Bays are certified separately, by an SGA audit, under the SGA Certified Bay mark (spec/14).

The conformance kit is public and runnable offline. A vendor should be able to know they pass before they contact us, and should never be surprised by the result.

How SGA enforces#

The instinct is to reach for the signing key, because revoking it is the most obvious lever. It is also the one least usable in practice: pulling a major vendor's key stops every bay running that product, so the cost lands on facilities and golfers who did nothing — and revocation has to reach offline bays through the bundle, so it is slow as well as blunt. A remedy nobody would actually deploy deters nobody.

There is a second way, and it does nearly all the real work.

Per round: automatic checks at upload#

Every round arrives as a hash-chained journal, and the journal carries the evidence already: manifest_hash, the engine's own binary measurement (02 §2.2), every round.settings declaration with its actor, and the attestation tier and vendor assurance of every participant. So the judgment can be made one round at a time.

This is immediate, proportionate, reversible, and requires no cooperation from the vendor at all — it works against a party who never signed anything, which no contractual remedy does.

The data is always ingested, and the round always stays with the player. There is no verdict that discards a round, and none that takes a golfer's scorecard away from them. Somebody played that golf; the record is theirs.

What a finding changes is the assurance recorded against the round — and that is deliberately the same pair of axes every participant already carries (02 §2.1):

This needs no new enforcement machinery, which is the point. An event already states min_attestation_tier and min_vendor_assurance in its rules package. Lower the assurance recorded on a round and that round simply stops satisfying the requirement the event already declared — so it leaves the sanctioned result on its own, through the mechanism the event itself defined, with no special case anywhere.

Everything below a sanctioned event carries on. The shot record stays with the player, their stats keep working, and the round remains in their history with the finding attached to it.

A round may also be marked invalid#

A downgrade and an invalidation are different findings, and collapsing them would lose the distinction that matters most.

A downgrade says the round is real but less well attested. Nothing contradicts itself; there is simply less evidence behind it than the top tier requires.

Invalid says the record is not internally consistent — the tamper-evident machinery itself disagrees with the data. A broken journal hash chain, a signature that does not verify against the key that claimed it, a manifest chain with a gap in it, a scorecard whose checkpoints do not chain, strokes that do not reconcile against counted records. In that state the round cannot be treated as a true account of what happened, because the thing whose whole job is to prove it has not been altered is reporting that it has.

The data is still ingested and still retained — the evidence is exactly what a vendor audit would need, and discarding it would destroy the only record of the failure. But an invalid round is excluded from anything that depends on the record being true, and it is marked so the exclusion is visible rather than mysterious.

Invalid is a statement about the record, not an accusation about a person. A failed hash chain is far more often a crashed write, a clock jump, a disk error or a bad build than anyone's misconduct. It is grounds to look, never a finding on its own — which is the same rule that governs everything else here: machines flag, humans adjudicate.

Which uses survive a downgrade is a rulebook question, not a technical one. The ladder — personal record, statistics, player rating, league, sanctioned event — is where that policy lives, and it stays changeable retroactively like every other posting-eligibility question. The standard's job is to record faithfully what was and was not demonstrated; deciding what a given level of assurance is good enough for belongs to the competition rules.

Refusing data at ingest would also destroy the evidence a vendor audit depends on, which is a second reason the answer is always to take the round.

A build SGA cannot match to a published digest counts at a lower level. Its rounds are recorded and stay with the player, but they take the trust level the round can actually show, below A1, so they do not count where A1 or higher is required. Publishing the digest later does not raise rounds already recorded. SGA support can re-ingest specific records on request.

A mismatch at one bay is ambiguous; the same unpublished digest at four hundred bays overnight is a release. Neither the bay nor the vendor can tell those apart. SGA can, because it holds the population, and that fleet-level view is what turns a per-round flag into a defensible judgment.

Whatever the verdict, a round that does not post carries a reason code the facility can see. Silently withholding a result generates distrust and support tickets in equal measure.

Per vendor: escalation for a pattern#

Escalation, for a pattern rather than an incident. Each step is meant to be one SGA would actually use:

1. Inquiry. Ask, with the evidence.
2. Audit, under NDA where the vendor requires one.
3. Corrective plan, with a deadline.
4. Suspend certified. They fall to verified_build: data stays admissible and casual play at every bay continues untouched, but they stop qualifying for events that demand the top tier.
5. Suspend verified_build. They fall to none. Rounds still record; they no longer carry an attestation anyone is accountable for.
6. Revoke the key. Last, and rare — but not the cliff it sounds like. Because the tiers are cumulative, a revoked certificate drops a product to A1 rather than out of the ecosystem (02 §3.1). The digests that A1 requires are already being published by anyone holding a certificate at all, so the fallback needs no release and no customer action: rounds keep counting toward player ratings from the moment the key is killed. What is lost is sanctioned competition, until a new certificate and an update restore the tier.

A compromise is scoped before it is punished. Revoking a key and nullifying everything it signed are separate decisions, and the second is almost never the right size. Most rounds a leaked key touched are ordinary players who did nothing — so an affected set is identified from the evidence (a member, a bay, a window) and re-adjudicated by recording a lower effective attestation level for those records. The rounds survive; what they count for changes.

This is also what makes disclosure survivable. A vendor who believes a reported key leak will void every round their product ever produced has a strong reason never to report one, and would be right to worry. Scoping the response is what makes telling us the sensible move: a remedy so heavy that nobody will invoke it protects nothing.

The two differ in direction. Per-round checks respond to evidence in a round's own journal. Escalation changes what a vendor may claim from now on — including when a build process is found compromised while every deployed build still hashes correctly, which no single round can show.

Patent posture#

Contributors to the specification grant a royalty-free license to any patent claims necessarily infringed by implementing the ratified portions they contributed. Standard W3C/OASIS-style RF terms. A contribution that comes with an undisclosed patent encumbrance is not ratified.

What is deliberately not governed here#

Commercial terms of any kind. Whether a facility must use certified gear to run an SGA tournament is a competition-rules question, decided in the rulebook. Keeping that out of the technical standard is what lets a vendor adopt SGA-OIS without adopting SGA's commercial program.