The bay capability profile
Normative.
The capability handshake is already a certification audit. It just was not being written down.
Every session, every device at a bay presents a signed descriptor stating what it is, what firmware it runs, what it can measure and at what provenance, whether its calibration is current, and what attestation it can demonstrate. That is the equipment inventory a certification inspector would otherwise assemble by hand — self-reported by the hardware, cryptographically signed, and already sitting in the engine.
A bay profile is that, collected and signed: bay-profile.schema.json.
1. Why it is generated, not filled in#
An inspection checklist records what a person saw on one day. A generated profile records what the equipment says about itself, continuously, and goes stale on its own when something changes.
That difference matters most for the requirements that are true on inspection day and false on event day:
- firmware updated since certification
- calibration expired
- a device swapped out
- an entitlement lapsed, so a field the bay was certified for is no longer emitted
- internet access, which is the one most likely to be demonstrated once and then quietly degrade
A profile is regenerated on any topology change and on a schedule, and carries valid_until. A bay whose profile has expired is not decertified — it is simply not currently evidenced, and the operator can see why.
2. Certification tiers are requirement bundles#
The event rules package already expresses what an event needs from the hardware: device_requirements with a minimum attestation tier, certified models, a firmware allowlist, required fields at measured provenance, and a calibration age limit.
A certification tier is the same shape, given a name. Gold, Diamond, Platinum and Residential become named bundles of those requirements, evaluated against the bay profile by exactly the mechanism that evaluates an event.
Two consequences worth having:
- A bay certified for a tier is, by construction, eligible for events at that tier. There is no second rulebook to keep in step, and no class of bug where a bay is certified and then rejected at the door.
- Adding a requirement to a tier is a data change, not a code change. The requirement vocabulary already exists.
3. What the profile carries beyond the equipment list#
Three areas the handshake does not cover on its own, and all three are things an operator would otherwise assert without evidence.
3.1 Connectivity#
Measured by the engine over a sampling period, not declared: reachability, uptime percentage, median latency, throughput, whether a redundant path exists, and — decisively for competition — the best time anchor the bay can reach.
A bay that cannot obtain signed time cannot host an event with an enforceable deadline (08 §2.2). That is a hard, mechanical fact about the bay, and it belongs in its profile rather than being discovered on the morning of a qualifier.
3.2 Presence#
Whether BLE scanning and advertising are available, and whether the adapter supports the rotating proximity token (07 §2).
Placement matters as much as presence. An adapter in a cupboard forty feet away technically scans and proves nothing. So the profile records observed signal strength from a device held at the swing position during commissioning, not merely that an adapter exists. adapter_at_swing_position declared alone is not evidence; corroborated by RSSI, it is.
3.3 Video#
Camera count, whether the swing position and bay entry are covered, resolution, frame rate, and retention.
For human review of swings only. Automated identity confirmation from video is deliberately absent from this profile and from the standard: it is biometric identification, and it is not built.
4. Certification decides; the profile only evidences#
The split follows this standard's scope boundary. The engine generates and signs the profile; SGA's certification service decides, and a human reviews.
The profile carries an assessment block — the engine's own read of which tiers it appears to satisfy and what is unmet. That is a pre-check, not a certification. Its value is that an operator can see they are two requirements short before anyone travels, and can fix it first. Self-assessment that anyone can run is what makes certification cheap to scale; the same argument as shipping the conformance kit publicly.
4.1 And the decision comes back#
The profile goes to SGA; a signed certificate comes back, and the engine enforces the tier locally from then on. That is 14, along with the limits on what such a credential is allowed to mean — it asserts a tier and unlocks nothing, and the authoritative check stays at ingest where the bay cannot argue with it.
5. What does not go in a profile#
- Device serial numbers. A profile records that a serial was supplied. The serial itself goes to SGA for certification and audit and never into a document that circulates.
- Anything about players. A profile describes a room and its equipment.
- A residential bay's location. Residential installations are certified and numbered but never publicly listed. The profile exists; the address does not leave SGA.
6. A commissioning by-product, within limits#
The operations block carries bay count, operating hours, whether the facility is staffed and whether it takes bookings. Gathering those at certification costs nothing extra — the visit is happening anyway.
It does not extend to availability. A facility's tee sheet is real-time, perishable, takes walk-ins, and lives in a booking system SGA does not control. Commissioning is the right moment to record which booking system a facility runs and whether it has an API; it cannot capture what the bay is doing on Thursday. Live availability is a question for that booking system, asked at the time, and deliberately outside this profile.
operations is the one part of the profile that exists purely for the platform rather than for the protocol.