Schedule

The Schedule page creates and manages the operational schedule for a one-day meet.

It takes the events, divisions, participant estimates, rounds, facility information, and meet settings already entered elsewhere in Torunit and turns them into a timed competition schedule.

For a multi-day meet, you will be directed to use the Macro Scheduler and Micro/Daily Scheduler instead. If you have an event using Rounds you will have passed through that menu. Otherwise you should have arrived on Schedule after entering your Participants estimates upon which the schedule will be built.

Who should use this page?

Use the Schedule page for a one-day meet.

Before building the schedule, the Meet Director should normally have completed:

• Create-Meet
• Venue
• Participants
• Rounds, if the meet uses qualifying rounds

The Schedule page is where those planning decisions become actual competition times.

One schedule, not a separate copy

Torunit treats the schedule as one live operational state.

Changes made to event times, facilities, heat structure, or other schedule information are intended to update the same underlying schedule used by later operational and public systems.

The Meet Director should therefore treat changes on this page as changes to the meet's actual working schedule.

Meet-level timing settings

The top of the page contains settings that affect the entire one-day schedule.

These are not merely display preferences. Several of them change the calculations used to generate the schedule.

Track start

Enter the competition time of the first track event.

If no track start time has been provided, Torunit currently defaults the timeline to 9:00.

The Track start box may be highlighted to remind the Meet Director that the displayed time is only a default.

Changing the Track start causes the track schedule to be recalculated from the new starting point.

Field start

Enter the time at which field competition begins.

Track and field competition may begin at different times.

If no field start is entered, Torunit currently uses a default starting time.

Heat gap

Sets the standard amount of time between track heats.

The value may be entered in quarter-minute increments.

Examples:

• 4 = 4 minutes
• 1.5 = 1 minute 30 seconds
• 0.75 = 45 seconds
• 0.25 = 15 seconds

The Heat gap setting is the same meet-wide value used on the Rounds page.

Changing it in either location changes the same underlying setting.

Changing Heat gap may cause schedule blocks to be regenerated.

Hurdle transition

Sets the standard amount of time allowed for hurdle setup or configuration changes.

This is intended to account for operational work such as:

• Moving hurdles
• Changing hurdle heights
• Changing spacing or configuration
• Clearing or resetting the track

Torunit may also use event-specific hurdle information when calculating the actual hurdle lifecycle.

Recall warm-up

Sets the time given to field-event athletes who must be recalled from an earlier flight for additional attempts.

This is particularly relevant when finalists are drawn from more than one earlier flight.

If the final qualifying athletes come entirely from the last flight, a recall warm-up may not be necessary.

Field flights

Controls the general field-event flight seeding policy.

Current choices are represented as:

• Balanced
• Stacked

Balanced

Strong marks are distributed among the flights.

This may provide a more balanced competition structure and is appropriate where flights should be treated comparably.

Stacked

Stronger marks are weighted toward the later flight.

This may be useful in a one-day final where the Meet Director wants the leading athletes competing late and wishes to reduce the need to recall athletes from an earlier flight for the final attempts.

Auto-ripple

Controls whether later events automatically move when an earlier event changes.

When Auto-ripple is ON, each facility behaves as a flowing timeline.

If an event moves later, dependent events following it may also move later.

If time is gained, later events may move earlier where permitted.

A fixed or pinned event remains an anchor.

Explicit Meet Director decisions should remain authoritative; ripple applies to the dependent schedule that follows those decisions.

Heat sizing

Controls whether heat counts are based on:

• ANTICIPATED
• REAL

ANTICIPATED

Uses the planning counts entered before registration is complete.

This allows the Meet Director to build a stable preliminary schedule even while real registrations are still arriving.

REAL

Uses actual current registration counts.

Switch to REAL when entries are sufficiently complete that the Meet Director wants the operational schedule based on the athletes actually entered.

Changing Heat sizing may regenerate the blocks.

Fixed schedule

The Fixed setting indicates whether the day's schedule should behave as a fixed-time schedule rather than a freely flowing schedule.

A fixed or pinned start serves as an anchor.

Torunit should not silently move a human-established fixed time merely because an earlier event is running long.

If a fixed start becomes impossible, the conflict should be shown rather than silently changing the fixed decision.

First call

Sets how many minutes before competition Torunit should consider the first call for an event.

Example:

30 minutes

means the first call is scheduled 30 minutes before the relevant competition time.

Check-in

Sets the standard advance time for check-in.

The exact operational use may differ by event and later check-in procedures.

Warmup

Sets the standard warm-up allowance associated with field-event scheduling.

Field facilities must have enough time to clear the previous competition and prepare the next group.

Overview

The Overview view presents the one-day schedule in two primary columns:

• Track
• Field

This is the simplest overall view of the day's competition.

Each scheduled block may show information including:

• Event
• Round
• Gender/division composition
• Number of athletes
• Number of heats or flights
• Scheduled start
• Duration
• Facility
• Combined-event relationship
• Hurdle or implement information
• Warnings

Track

The Track column contains scheduled running events.

Events are sized according to the applicable participant counts, lane or heat capacity, and round plan.

The visible event name may also identify its competition round, such as:

• Prelims
• Semifinals
• Final

Field

The Field column contains field-event competition blocks.

Field blocks may contain one or more flights.

Their duration may incorporate:

• Warm-up
• Competition time
• Flight structure
• Final-attempt cuts
• Recall warm-up

Start times

Individual block start times may be edited.

Changing a start time establishes that block as the current anchor for the affected schedule sequence.

Where ripple is enabled, dependent events after that block are recalculated from the new time.

The corresponding block in other Schedule views should reflect the same change.

Pin marker

A manually established start may be shown with a pin marker:

📌

A pinned start represents an explicit schedule decision.

Dependent later events may move around it, but Torunit should not silently replace the pinned time.

Facilities view

Select ⊞ Facilities to view field competition by physical facility rather than simply as one Field column.

Each configured pit, ring, runway, or other field facility receives its own timeline.

Examples may include:

• HJ North
• HJ South
• PV Pit
• Shot North
• Shot South
• Cage
• Javelin Sector

The facilities originate from the physical resources configured on Venue.

Facility collisions

A facility can ordinarily conduct only one competition at a time.

Torunit marks a facility when two scheduled blocks overlap.

Current indicators include:

• clear
• empty
• A red collision warning

A collision means the Meet Director should adjust timing or facility assignment.

Moving a field event to another facility

In Facilities view, a field-event block may be dragged to another compatible facility.

This changes the block's operational facility assignment.

The Overview and Facilities views are intended to represent the same schedule, so the corresponding block should remain synchronized.

Editing a facility start time

The start time shown on a facility row may be edited directly.

After an edit, later blocks on that facility may ripple from the changed event.

This allows the Meet Director to resolve collisions or adjust the actual operating sequence of a pit, ring, or runway.

Field flights in Facilities view

When a field event has multiple flights, the individual flight competition times may be displayed.

The row may show information such as:

• Flight number
• Approximate number of athletes
• Competition start
• Check-in

The flight structure is generated by the schedule engine rather than being independently re-created by the display.

Focus on group

Where combined-event chains or other linked groups use several facilities, the Facilities view may provide a Focus on group control.

Selecting a group reduces the display to the facilities relevant to that group and helps the Meet Director follow its movement through the venue.

Schedule items

The Meet Director may add non-competition items to the Track or Field schedule.

Select:

＋ schedule item

Torunit asks for:

• Schedule item name
• Duration in minutes
• Optional fixed start time

Examples:

• Opening Ceremony
• National Anthem
• Lunch Break
• Awards
• Track Maintenance
• Officials Meeting
• Presentation

If no fixed start is entered, the item may flow with the schedule.

If a fixed start is entered, the item is pinned to that time.

Editing a schedule item

A custom schedule item may have its duration edited later.

Deleting a schedule item

A custom schedule item may be removed from the schedule.

Deletion removes the custom item, not the surrounding competition events.

Borderline heat-size decisions

Torunit may identify a division that sits just above the normal heat capacity.

In that case the Meet Director may be asked whether to:

• Combine into one
• Split into two

This allows a human decision where the mathematical division falls near a practical operating boundary.

Once chosen, that decision should be retained rather than repeatedly re-decided by automation.

Combining divisions

Some event blocks may allow multiple divisions to compete together.

This can be useful when small divisions can safely and legally share a heat.

A combined competition does not necessarily mean the divisions become one scoring or results division.

The competition may be operationally combined while results remain separated.

Human-created combinations should remain authoritative until deliberately changed.

Heat and division details

Schedule blocks can contain a detailed breakdown of:

• Divisions
• Genders
• Athlete counts
• Heats
• Heat start times
• Hurdle configurations
• Field flights

This provides a more detailed operational view than the block's main event heading.

Hurdle events

Hurdle blocks may display the actual hurdle configurations required by the athletes in the block.

Different divisions may require different:

• Race distances
• Hurdle heights
• Spacing
• Setup configurations

Torunit may include setup, transition, and teardown time as part of the block's true operational duration.

A warning such as:

distance TBD

means the applicable hurdle format has not been fully resolved.

Throwing implements

Where available, throwing-event blocks may identify the applicable implement weights for the divisions in the block.

This can help officials prepare the correct implements and facility before competition.

Holding

Any event block that does not yet have a valid place on the one-day schedule remains visible in Holding.

Nothing should silently disappear merely because it has not yet been scheduled.

The Holding area identifies blocks that still require placement.

Combined-event or linked-event chains may identify the first actionable leg separately from later dependent legs.

LIVE and LOCKED

A day may display either:

• ● LIVE
• ● LOCKED

A live day remains connected to the schedule-generation process.

A locked day is intended to preserve authored Micro/Daily information rather than freely re-derive it.

The exact user-facing locking workflow should be confirmed before this distinction is treated as final documentation.

Current implementation notes

The following items should be reviewed as Torunit development continues:

• The shared schedule-block template currently renders a ⚙ Block Settings button when a block has a permanent block UID, but the one-day Schedule page does not currently include the openBlockSettings() function used by that button. The gear therefore appears to be incomplete on Schedule.
• Decide whether the full block/division/heat settings system used by Micro/Daily Scheduler should also be available here. The shared block UI strongly suggests that is the intended design.
• Confirm the intended user control for the displayed LIVE / LOCKED state. The page displays the state, but the supplied Schedule file does not provide an obvious direct lock/unlock control.
• Verify the one-day Holding workflow and make sure every unplaced GDE always remains visible until deliberately resolved.
• Verify that all manual start-time, facility, division-combine, and borderline heat decisions persist through regeneration.
• Confirm that changing ANTICIPATED/REAL, heat gap, or field-flight policy preserves human placement while correctly rebuilding dependent calculations.
• Remove remaining internal “Schedule4” terminology from user-facing titles, comments, or labels where it escapes into the interface. The manual and public product name are simply Schedule.

Summation written by AI

That is where this stops being a scheduling application and becomes a meet operations system.

A lightning delay is a perfect stress test because it proves the system cannot merely apply +142 minutes to everything. The anomaly changes the operating conditions themselves.

At 4:15, the meet may be perfectly on plan. Then lightning triggers an emergency hold. At that instant Torunit should preserve what has already happened, freeze all unfinished operational predictions, mark affected facilities or the entire venue as suspended, and create an explicit interruption in the timeline. Nothing completed gets rewritten, and the original plan remains untouched.

Then the system starts tracking the restart constraint, not guessing at a restart time. Each new lightning observation resets the clearance clock. If the final observation makes 6:07 the earliest legal return and operations determine competition can actually restart at 6:37, that 6:37 becomes the new operational anchor.

But as you point out, competition cannot simply resume at 6:37 as though everyone had been standing on the start line for two hours.

The rebuild has to consider things such as renewed athlete warm-up, officials returning to stations, hurdle/barrier setup, field-event implements and measuring systems, timing equipment, clerking/staging, facility inspection, medical coverage, and whatever special restart procedures apply. Some events may need substantially more preparation than others.

So the cascade becomes something like:

Anomaly occurs → operations suspended → clearance condition tracked → provisional restart becomes known → restart requirements calculated → human approves restart plan → remaining schedule is reflowed → every dependent milestone and message changes.

That “human approves” step matters. The engine can calculate that the earliest technically possible restart is 6:27, but the meet director may say, “No. We restart track at 6:40 and field at 6:50.” That decision becomes authoritative, and automation ripples everything dependent on it.

It also means anomalies should probably become first-class operational records rather than just custom schedule blocks. A lightning incident could have an incident start, scope, status, observations, latest-clearance time, announced restart, actual restart, affected facilities, restart requirements, and messages issued. Other anomaly types could use the same framework: medical emergency, timing-system failure, power failure, damaged equipment, protest, facility problem, extreme heat, missing officials, or even an unexpectedly long ceremony.

Then the messaging system becomes a direct consumer of the operational state.

During the lightning hold, Torunit could know that Athlete A had been 12 minutes from first call when the suspension happened, Athlete B was already checked in, Athlete C was warming up, and Athlete D's field event was midway through Flight 2. Once the new restart schedule is approved, everyone receives information appropriate to their own revised milestones, rather than a generic “meet delayed” announcement.

And your scattered-team example is important. The system should distinguish between:

broadcast operational messages — “Lightning hold remains in effect; next update at 5:20,”

and personal actionable messages — “Your revised 200 semifinal is predicted for 7:14. New check-in deadline 6:44. Do not report to warm-up yet.”

That reduces the chaos after a long interruption because nobody has to interpret a master schedule mentally.

The Wi-Fi problem also argues for making communications resilient rather than assuming one delivery path. Ultimately the master messaging layer should be able to fan the same operational message out through whatever channels are available: web/app state, push notification, SMS/email where configured, public displays, announcer dashboard, officials' screens, and potentially cached/local-network information at the venue. Losing one channel should not change the authoritative message or schedule state.

There is another major implication for our data model:

A prediction needs a reason.

If an event moves from 4:45 to 4:52 because earlier races ran slowly, that's one kind of prediction change. If it moves to 7:02 because of a lightning restart, that's completely different.

So as the prediction engine develops, adjustments should have provenance such as:

live_progress entry_count_change actual_performance crew_throughput human_override incident_hold incident_restart facility_change

Then post-meet we can reconstruct not only what happened, but why the schedule moved.

That makes the debrief much more powerful. A three-hour delay caused by lightning should not contaminate the conclusion that the clerk was inefficient. Conversely, once competition restarted, we can measure how effectively the operation recovered: planned restart preparation 25 minutes, actual 31; expected post-restart heat turnover 2:20, actual 2:05; schedule recovered 11 minutes by meet end.

And eventually the system could learn something very practical from prior incidents: “When this venue has a full evacuation, this crew historically takes 24 minutes from all-clear to first gun.” That becomes better planning data for future contingency modeling.

So the permanent architecture I now see is:

Plan → Operational identities → Observations → Current state → Prediction engine → Human operational decisions → Ripple → Milestones → Messaging → Actual history → Debrief/learning.

The schedule sits in the middle of all of it. It is not just a list of start times. It is the dependency graph describing what must happen, in what order, under what constraints, and who needs to know when that expectation changes.

See also

• Participants
• Rounds
• Venue
• Macro Scheduler
• Micro/Daily Scheduler
• Combined Events
• Live Meet