The bay certificate, and enforcing a tier

Normative.

10 §4 ends with certification deciding and the profile only evidencing. Nothing carried the decision back to the bay. A bay could be certified Diamond and then run a whole season with an unattested launch monitor, and the first anyone would know is when the rounds were assessed at ingest.

This chapter is the credential that closes that, and — more importantly — the limits on what it is allowed to mean.

Schema: bay-certificate.schema.json.

1. The certificate asserts a tier. The bundle defines the tier.#

{ "type": "BAY_CERTIFICATE",
  "bay_id": "sga:bay:0482-07",
  "facility_id": "sga:facility:diamond-austin",
  "tier": "diamond",
  "issued_at": "2027-04-02T00:00:00Z",
  "expires_at": "2028-04-02T00:00:00Z",
  "grace_days": 30,
  "profile_hash": "sha256:...",
  "issuer_key_id": "sga-cert-2027",
  "signature": { "alg": "ed25519", "key_id": "sga-cert-2027", "sig": "..." } }

The requirements are not in it. They live in the bundle, as named tiers in exactly the shape 10 §2 already describes:

{ "tier": "diamond",
  "rank": 30,
  "min_attestation_tier": "A2",
  "required_fields": ["ball.speed_mps", "ball.launch_angle_deg", "ball.spin_rpm"] }

rank is declared, never derived. Tier names are marketing words — Gold, Diamond, Platinum, Residential — and nothing about them says which outranks which. An engine that inferred an order would be wrong on the first tier SGA adds.

That split is the design, not an implementation detail. If requirements traveled inside the certificate, raising a floor would mean reissuing every certificate in the field — and the bays slowest to collect a new one would be the ones enforcing the least, which is precisely backwards. With the split, SGA raises the floor in the bundle and every bay at that tier enforces it at the next swap (13 §1).

1.0 Certification is not attestation#

This is the distinction the rest of the chapter rests on, so it goes first.

The engine can observe attestation. It verifies nothing, and certification is a larger claim still.

A bay's live attestation is observable: devices declare a tier, the handshake carries it, and the engine records what is connected right now. It does not check any of it. The engine holds no private key and verifies no participant's signature; the only signatures it checks are SGA's, on a bundle and on an Event Rules Package (02 §3a.3). An engine whose own integrity is in question cannot vouch for anything, and a verification result it reported would itself have to be trusted to be worth having.

So a declared tier is a claim the engine witnesses, and the server layer resolves it against the certificate it was issued under. Certification is larger again, and most of what goes into it happens nowhere near the bay:

That is the whole reason the certificate is a signed artifact rather than something the bay computes about itself. It carries the part of the decision the engine could never make, and it is why "this bay has good hardware attached" and "this bay is Diamond certified" are different statements that can disagree in both directions.

A Gold bay with immaculate A3 equipment is still not a Diamond bay, because nobody audited it as one.

1.1 It is not a feature key#

A credential that unlocks capability creates an incentive to crack it. A credential that asserts a fact the platform independently re-derives does not.

So the certificate turns nothing on. It does not gate features, unlock modes, or license software. It says one thing — this room met this tier on this date — and everything downstream is a consequence of that fact being true or false, checked elsewhere.

1.2 Why the check has to happen at the bay#

Local enforcement can look like a convenience, with ingest as the real check, because SGA can re-derive a round's tier from the provenance in its own shot records. It is not a convenience. Treating it as one fails in the direction that costs a member their round.

Ingest can tell that a round did not meet its tier. It cannot make that harmless. Consider what it is actually being asked to do:

A member enrolls in a tournament at a certified bay. Everything admits them. They play eighteen holes and they play well. Days later, verification staff find the bay was not attesting at the level the event required — and the score is invalidated.

The harm is not a bad score getting in. Ingest catches that, and a rejected round from a bay nobody promised anything about costs nobody anything. The harm is a good score being taken away from someone who already earned it, because of a condition that existed before they teed off and that nobody told them about.

Nothing downstream can prevent that. By the time ingest runs, the round is played and the member is expecting to win. The only moment at which this is preventable is before the first stroke, and the only thing standing there is the engine. So for sanctioned play the bay check is the protective mechanism, and ingest is the audit behind it — not the other way around.

That is why §3 makes a sanctioned round block unconditionally, whatever the bay's own setting says.

1.3 The honest limit on binding#

The certificate names a bay_id, and an engine refuses one issued to a different bay. That catches the accident and the casual copy.

It does not stop a determined copy. A certificate file moved to another machine still verifies there, and preventing that would need hardware attestation on arbitrary Windows PCs that SGA does not own. Detection is server-side and easy — two bays reporting rounds under one certificate — but prevention at the bay is not available, and claiming otherwise would repeat the error 02 §8.4 exists to warn about.

2. What makes a device critical#

Not its role. Not a maintained list of device types.

A device is critical if it is the resolved source for a field the tier requires.

The connection matrix already computes that (09, 03), so certification asks a question the engine is answering anyway. Three things fall out of it, all of them wanted:

• A wind machine at A0 is irrelevant, because no required field resolves to it. Nobody has to write that down.
• A weak device with a strong one beside it is harmless. If an A1 monitor and an A2 monitor both offer ball speed, the A2 one wins the field and there is no shortfall. The A1 unit stays connected and keeps contributing everything the tier does not require.
• Adding a requirement is a data change. Same property 10 §2 claims for tiers generally.

The same test decides which components are in a result's chain of trust: a result takes the lowest tier among the simulator, the devices it resolved its values from, and the bay itself (02 §2.3). A certified bay is what lets the room contribute A2 or A3 to that chain.

2.0 A certified bay's level should not fluctuate#

Certification says this room has the hardware and software to prove attestation at this level. That is a statement about the installed equipment, and it should not move because of who walked in.

A certified bay's level goes down when equipment was replaced with non-conforming equipment, when a firmware change broke the trust chain, or when calibration ran out. It does not go down because a guest plugged something in.

So the certificate records the equipment that earned the tier — certified_devices, as certification found them — and the question at round start is not does some device here meet the floor. It is:

Is the equipment that earned this certification still present, still attesting, and still on conforming firmware?

Those are different questions, and only the second is a certification question. A guest's A0 monitor joining a Diamond bay is not a shortfall of any kind: the house monitor still wins the fields the tier requires, and the guest device is just another participant.

2.1 The floor is an attestation tier, not a list of fields#

It is tempting to write a tier as must send a serial number, a firmware digest and a hardware secret. That would be theater.

Below A2, a device can claim any serial, any firmware version and any digest it likes (02 §3). Demanding them of an unattested device buys a populated field in a log and no assurance whatsoever. What makes a serial mean something is the signature over it — which is exactly what the attestation tier measures.

So a tier states min_attestation_tier, and the specific evidence follows from it. This is the same reasoning that limits unit denials in 13 §2.4, and it is worth stating twice because the mistake is so natural.

2.2 A tier the device invents clears nothing#

An unrecognized attestation value ranks below A0. A device answering A9 or PLATINUM does not clear an A2 floor by being creative about the vocabulary.

2.3 Attestation must not outrank provenance#

The floor is a veto, never a ranking dimension. A device below it is excluded from resolving the fields the tier requires; the surviving candidates are then ordered by the ordinary rules — provenance first.

Ranking attestation above provenance would let a well-attested calculated source beat a measured one, and quietly make the data worse in the name of making it more trusted. The point of a certified bay is better measurement, not better paperwork.

2.4 A shortfall names what changed#

Because a certified bay should not drift, a shortfall is an alarm that something changed, and an operator needs to know which thing.

The drift reasons are reported first, ahead of the field-level ones. When the certified launch monitor is unplugged, "no source for ball.speed_mps" is perfectly true and it is not the story — and an operator sent looking for a missing field will not think to look behind the bay.

3. What a shortfall costs#

**A round is evaluated against the tier it claims, never against the tier the bay holds.**

The certificate is a ceiling, not a floor.

That is the entire vocabulary. There is no third setting, and no per-bay knob.

3.0 A degraded bay still lets people hit balls#

A certified bay in a degraded state is not a broken room — it is a room whose paperwork no longer holds.

No tier setting stops casual rounds. One that did would contradict the rule this chapter keeps for a lapsed certificate (§4):

Losing a certification changes what a round counts for. It must never change whether golf can be played in the room.

A degraded Diamond bay is still a room with a simulator in it, and the people who booked it came to hit balls. Refusing them protects nobody, because there is no claim to protect — nobody promised them a ranked round. The degradation is announced, journalled and recorded against the round; the round happens.

What such a round should then count for — full rating posting, flagged posting, or none — is a policy question, not an engineering one, and this standard deliberately does not answer it. The bay records what happened and how well it was measured; what that is worth is decided by the ruleset in force (00 §7).

3.1 An event names the certification it requires#

Tournaments run on certified bays of a particular level, and the level is the event's to set. A bay does not get to decide that its own certification is good enough for someone else's tournament.

The Event Rules Package carries it (08 §2):

"bay_requirements": { "min_certification_tier": "diamond" }

At round start the engine makes two checks, in this order, and both must pass:

They fail differently and an operator needs to know which, because one is a phone call to SGA and the other is a walk behind the bay. A bay can pass either and fail the other:

• Certification fine, equipment absent → check 2 fails, eligibility is not set.
• Certification too low, equipment beyond reproach → check 1 fails, no shortfalls are reported, because the equipment did nothing wrong.

A lapsed certification is the one place expiry has teeth. §4 says a lapse never stops play, and that stands — but it stops an event, because an event was promised something and casual play was not.

A tier the bundle cannot resolve is refused, not guessed. A stale bundle that has never heard of the tier an event requires cannot be assumed to satisfy it.

3.1a A sanctioned round always blocks#

A round played under an Event Rules Package (08) — or any round a member has been told will count — MUST NOT start while a shortfall stands. There is no downgrade for a tournament: the member did not enter one in order to receive an unranked round, and quietly recording one is the same harm as invalidating it later, arriving by a politer route.

Refusing to start is not the bad outcome. Taking away a score somebody earned is the bad outcome, and refusing to start is the only thing that prevents it (§1.2).

3.2 A certified bay never refuses a device for its attestation#

No certification tier, at any level, denies a device admission because of what it can prove about itself.

A high certification means the bay prefers the best-attested source for the fields its certification rests on. It does not mean the bay turns everything else away at the door. No tier, championship included, has a setting that denies admission.

The preference is already complete without denial:

• A device below the floor cannot win a required field. That is the whole protection, because a field it cannot win is a field it cannot influence.
• The floor applies to those fields and nothing else. Everything else the device offers, it still wins on the ordinary rules.

And the reason denial would be a loss rather than a safeguard: the devices below the floor are mostly not competing for the certified fields at all. A pressure mat, a swing camera, a wearable, a club rack — these are not launch monitors trying to report ball speed. They are different kinds of sensor reporting things nothing else in the room can see, and how they capture it is already declared in the handshake (03) with its own provenance (01). Refusing them would throw all of that away to protect a field they were never going to win.

The one thing that still refuses a device is 13 §2 — a known vulnerability, which is a hazard to everyone in the bay rather than a question about anyone's paperwork. Different justification, different answer.

4. Lapsing#

Nothing expires all at once. A certification and a calibration both run out on a schedule: warned long before, graced for a while after, and only then gone.

    -90  -60  -30      -10 -5 -3 -2 -1    0        +10   +20  +25      +30
     |    |    |         |  |  |  |  |    |         |     |    |        |
     └────┴────┴─ warnings ─┴──┴──┴──┴─ expires ─── reminders ──┴─ grace ends
          background        attention   interrupt

Grace and the schedule are carried in the bundle, not in the certificate:

"lapse_policy": {
  "grace_days": 30,
  "calibration_grace_days": 30,
  "warn_before_days": [90, 60, 30, 10, 5, 3, 2, 1],
  "warn_after_days": [10, 20, 25],
  "extensions": {
    "sga:bay:0482-07": { "grace_days": 90, "reason": "technician backlog",
                         "not_after": "2027-09-01T00:00:00Z" }
  }
}

Grace is a term of the certification agreement, not a tuning knob. A facility that certifies is promised 30 days, and an engine that has never seen a lapse policy honors that figure. A tier may lengthen it; shortening it below the contracted figure is a change to what facilities were promised when they signed, and belongs in an agreement rather than in a bundle release.

Why the bundle and not the certificate: grace is policy. In the certificate it could never be changed without reissuing every certificate in the field — the same argument that keeps tier requirements out of it (§1). SGA shortens or lengthens grace in a bundle and every bay follows at the next swap. An engine with no policy at all uses the contracted 30 days, so an old bundle still behaves sensibly rather than granting none.

A tier may carry its own clock. A residential bay and a championship venue do not obviously deserve the same one, so a tier definition may override any of these values:

{ "tier": "platinum", "rank": 40,
  "lapse": { "grace_days": 30, "calibration_grace_days": 14 } }

Unset fields inherit — from the bundle policy, then from the contract baseline — so a tier that wants only a tighter calibration window says so and does not silently lose the reminder schedule. Extensions are always bundle-wide: an extension names one bay, and which tier that bay happens to hold is not what the exception is about.

4.0 And then it lapses — without stopping play#

Past the grace period the bay drops to uncertified, and keeps playing.

Losing a certification changes what a round counts for. It must never change whether golf can be played in the room.

A bay can be offline for weeks (07). An engine that bricked a paying customer's simulator because a credential lapsed while the internet was down would be an engine operators were right to remove, and one outage would undo more goodwill than certification could earn back.

What a lapse does stop is an event (§3.1) — because an event was promised something and casual play was not. That is the one place expiry has teeth.

Renewal arrives the way everything else does: in the bundle, or on a player's phone (07 §1).

4.1 Calibration gets grace too#

Calibration expiry is not a cliff: expired at midnight, bay decertified.

A calibration expiry is a date on a certificate, not the moment a sensor becomes wrong. A monitor does not start lying at midnight.

Treating it as a cliff decertifies a bay over a technician's scheduling rather than over its equipment — and the operator who booked that technician for next Tuesday did nothing wrong. Same grace, defaulting to the same number, separately settable because a facility may reasonably want a tighter one for calibration than for paperwork.

4.2 The reminders escalate, and continue past expiry#

Each mark raises one notice. Crossing 60 is a new notice; sitting at 60 is not — the same de-duplication the club-ambiguity notices use (12 §4), doing the same job.

A ninety-day warning that interrupts somebody is a warning they will turn off before it matters.

And the reminders continue after expiry, at +10, +20 and +25 days. A bay in grace is still working perfectly, which is exactly why its operator can keep ignoring the email — so the channel keeps going rather than falling silent at the moment it starts mattering most.

The engine raises operator notices; the platform decides email, SMS or push from the member's or operator's own preferences (12 §6), and an offline bay's reminders ride out on a player's phone like everything else (12 §9).

4.3 An extension is granted centrally, and expires itself#

A bay can be given more grace than the default — a technician backlog, a facility mid-sale, a supplier who has not shipped.

The grant lives in the bundle, because that is how SGA reaches a bay it may have no other route to, including one that has been offline for weeks. It is a deliberate central act; a facility cannot award itself an extension, which is the property that makes grace a courtesy rather than a loophole.

An extension carries its own expiry. The reason is institutional rather than technical: an open-ended exception granted once and never revisited is how temporary becomes permanent. A dated one has to be renewed by somebody who looks at the situation again.

An extended bay's assessment says so (grace_extended), so a lapse that looks survivable is visibly survivable because somebody granted it, not because the deadline was never real.

And it is removed at the next publish#

A bundle published after an extension's not_after MUST NOT carry it.

The engine already ignores an expired extension, so this is hygiene rather than enforcement — deliberately two mechanisms for one rule. Publish-time removal keeps the bundle readable: the live extension list is a thing people review, and one that accumulates dead exceptions is one where nobody can tell at a glance which bays are currently running on an indulgence. Engine-side expiry covers the other direction, a bay that has not seen a new bundle in months and would otherwise still be running on an exception that ended in the spring.

4.4 The lapses nobody causes#

Two things lower a bay's level with no equipment touched and nobody at fault:

• Calibration runs out. Time passes; one morning the bay does not qualify.
• SGA raises a floor. A tier tightens in the bundle and a bay that met it yesterday does not today.

Both are foreseeable, and both MUST be announced with time to act on them — a calibration expiry is warned at least three weeks out, because announcing it on the day is announcing it too late to book a technician. A tier change ships with the bundle that makes it, so the warning arrives before the requirement does.

4.5 A lapse is announced when it happens#

Not when somebody tries to play. The engine evaluates on topology change and raises an operator notice immediately, which travels the ordinary way — including on a player's phone from an offline bay (12 §9).

The timing is the whole value. A bay whose certified monitor was unplugged on Tuesday should stop being offered for Saturday's event on Tuesday, while there is still time to repair it or move the event. Discovering it when a member walks in is already too late to do either well, and discovering it after they play is §1.2.

5. In the configuration application#

The certificate is installed, viewed and removed in the password-locked configuration application (05 §4a), beside the bay roster.

A shortfall names its reason, because "nothing provides this field" and "something provides it and cannot be trusted with it" call for completely different actions — buy a device, or fix the one you have. Collapsing both to unmet throws away the half the operator needed.

6. What this must not become#

• Not a license check. It asserts a certification, never an entitlement to run the software. An engine whose certificate has lapsed is a working engine.
• Not a reason to stop recording. Every round is recorded at whatever tier it honestly met, including none.
• Not a bouncer. It never refuses a device for its attestation (§3.2).
• Not a rubber stamp. For sanctioned play the bay check is what protects the member; ingest audits it afterwards. A bay that waves a round through and leaves the argument to verification staff has moved the cost onto the player (§1.2).