# General Broadcast Contract This contract records product-wide behaviour for ViewRegatta broadcasts. It applies to live coverage, delayed live coverage, replays, programme holds, demonstrations, and future events unless an explicit event configuration says otherwise. It is deliberately independent of the behaviour used to simulate boats; simulated-boat navigation and collision avoidance are maintained in the simulator only and are not part of this contract. ## Accepted-decision registry and regression policy This document is also the retroactive registry of accepted broadcast decisions. A decision may not silently regress because a later feature is implemented in a different module, renderer, feed path, or event profile. Each accepted decision is classified before it is protected: - **Locked system invariant** — reusable engine behaviour. It requires a stable identifier in the implementation and at least one automated regression test. - **Validated event configuration** — event-owned data such as a logo, venue polygon, boat skin, or race format. It must be schema-validated and covered by an event-profile test, rather than copied into the reusable engine. - **Operational acceptance criterion** — production behaviour that needs a rehearsal or a long-running integration test in addition to unit tests. - **Simulator-only experiment** — kept isolated from the broadcast contract. It may be reverted or replaced without changing live, delayed-live, replay, or rendering behaviour. The following previously accepted decisions are registered now. `LOCKED` decisions cannot be changed without an explicit replacement decision, an updated test, and a documented migration note. | Identifier | Status | Decision | Protection | | --- | --- | --- | --- | | BCAST-001 | LOCKED system invariant | An event-configured local contest-water polygon is the sole water-elevation authority inside the competition area. It is fixed for the programme and does not sample, calibrate to, or re-seat against streamed Cesium water. | `scene.js`, `sea.test.mjs`, `water_decal_plane.test.mjs` | | BCAST-002 | LOCKED system invariant | Course-zone rings, route arrows, traces, distance aids, start/finish fields, and other laid graphics share one low water-decals plane. Physical boats, marks, and vessels occlude them naturally. | `scene.js`, `water_decal_plane.test.mjs` | | BCAST-003 | LOCKED system invariant | The upright partner frame/rink derives its perimeter from the same declared event polygon and local datum as BCAST-001. It must meet at the boundary without a raised platform, a second water sheet, or corner protrusions. | `scene.js`, `water_decal_plane.test.mjs`, event-profile validation | | BCAST-004 | VALIDATED event configuration | Event identity, central logo, partners, sponsor spacing, boat class/skins, venue, course geometry, language, and race naming are data and assets, never reusable engine assumptions. | event-profile schema and asset checks | | BCAST-005 | LOCKED system invariant | Commentary hand-overs, course introductions, countdowns, music fades, and programme holds preserve audible continuity and never emit internal production instructions. | editorial/audio tests and end-to-end rehearsal | | BCAST-006 | LOCKED system invariant | Camera movement is purposefully tied to editorial context; course narration, moving route arrow, and camera have one shared timing contract. | camera/programme tests and rehearsal | | BCAST-007 | SIMULATOR-ONLY | Experiments requested for simulated-boat collision avoidance, right-of-way movement, and path finding are excluded from this contract and are to be restored to Ulf's simulator model. | simulator-specific review only | When a reported defect concerns a locked decision, the correction must extend the existing regression test before the visual version is declared fixed. A screenshot alone is evidence of a defect; it is not evidence that the contract has changed. ## Event configuration, not engine code The following are event-owned inputs. They must be selectable from event configuration and assets, not embedded as assumptions in the generic broadcast engine: - event title, event logo, languages, dates, time zone, round and race naming; - venue, chart imagery, course coordinates, marks, start and finish geometry, and venue camera references; - boat class, 3D model, skins, sail colours, crew presentation assets, reserve-boat substitutions, and source imagery; - partner list, approved artwork, display order, brand treatment, and placement inventory; and - event-specific race format, course sequence, penalty policy, and approved commentary material. Changing an event must therefore change a profile and its assets, while retaining the editorial, visual, timing, accessibility, and reliability rules below. ## Editorial and audio rules - Commentary describes observed racing evidence in viewer language. Internal instructions, test language, unverified conclusions, and implementation terminology never go to air. - Audience-facing claims about tactics, right of way, wind effects, relative position, and results are bounded by the evidence and confidence available to the commentary engine. They never imply an umpire decision unless an official source provides one. - Commentary that follows a developing sequence is incremental: describe a verified manoeuvre when it happens, then add its verified consequence or tactical interpretation when that consequence is observable. A later conclusion must not be spoken before its premise is visible. - Routine descriptions, team context, course context, weather, rules education, and standings fill quiet periods with varied phrasing. A wording variant must not be reused consecutively within the rolling programme history. - Announcements at a race hand-over identify the event, round where known, race, teams, and whether coverage joins an already-running race. The actual current leg must be described, rather than a fixed leg label. - Finish and recap editorial beats complete before the next race introduction takes ownership of the programme. A change of race must never truncate an audible sentence. - Countdown signals are timely and intelligible (for example, “one minute to start”). They remain audible without needlessly silencing an already-running commentator unless the production policy explicitly requires an exclusive signal. - Neural voices are the preferred on-air voices. Browser speech is a monitored fallback, not a silent substitution for missing production audio. ## Picture, camera, and programme flow - Every spoken boat-specific observation owns a camera opportunity for the named boats. Camera moves are smooth, restrained, and purposeful; repeated fast in/out moves are avoided. - Camera context is retained when the fleet is compact and changes only where the related editorial beat or viewer orientation benefits from it. - A course presentation is a picture-and-voice contract. Its camera and route arrow do not start to travel before the opening narration has actually started. Every subsequent chapter, the moving arrow, and the final overview use the same timing offset. - Race transitions use a clear title, teams, and spoken orientation. Programme-hold and reserve-queue states use the same continuity principle: music, voice, card, and return to racing have intentional fades and no unexplained silence or picture cut. - A normal programme may show the current course, venue, race, replay status, recap, and next-race context. Text panels reveal rather than obscure the live sailing picture whenever that picture is relevant. ## Graphics, geometry, and overlays - On-water graphics have a stable depth order: the water/background is below hulls and fixed course objects; course-zone rings, route arrows, track traces, and relative-position aids remain attached to the water plane and do not cover boats, marks, or vessels. - Mark and finish-zone graphics are shown when relevant to the leg being sailed. A mark identifier is only displayed when that identity is currently meaningful for the course state. - Relative-position graphics use the declared measurement model, stable anchoring points, and clear animation. They must never flutter or imply a different quantity from the number displayed. - Rule-aid colours and circles are explanatory aids, not rulings. They appear only where the underlying geometry is sufficiently close and relevant to create a real interaction. - Wind presentation is visually continuous, directionally consistent with the published wind, and efficient enough to preserve broadcast frame rate. Its implementation may be simplified without changing its meaning. - Logos are rendered from approved event assets, with consistent visible-size treatment, adequate spacing, no unintended background plate, and predictable rotation. A central event logo is an event configuration item; it is not a permanent TRWC assumption. ## Reliability and quality - For an event configured with a presentation water surface, the declared flat local surface inside the exact contest polygon is the sole authority for water elevation. Cesium supplies city and terrain imagery outside that presentation area, but its native water must not re-seat, calibrate, or occlude the local course world. This prevents elevated or tilted water planes, flooded venue imagery, and course objects appearing above or below the water. - The programme maintains a stable frame rate and resolution. Adaptive quality may reduce detail briefly to protect continuity, but it must recover automatically when capacity returns. - Long-running broadcasts bound scene, feed, audio, and visual-history resources. Telemetry is used to identify growth and stalled rendering before a viewer loses the programme. - Cache revisions are applied at visual hotfix boundaries so a normal operator reload cannot retain a stale rendering module after a production correction. - The rendering plane, terrain reference, and venue imagery must share one declared vertical datum. No auxiliary water surface may occlude course objects or create a false raised/tilted water plane.