[jpn--]

This PR adds a coherent, registered model step that decides who has a recurring fixed work schedule. It does not implement the downstream assignment or enforcement of fixed work hours. The new attribute currently has no effect on mandatory tour scheduling, mode choice, trip scheduling, or other activity availability.

Implemented: fixed-schedule worker classification

constraint_fixed_work_schedule runs in both single-process and multiprocess model sequences and persists a person-level works_fixed_schedule attribute. It uses a binary logit with industry intercepts and an income effect. The coefficients are explicitly labeled prototype assumptions, not estimated or validated survey parameters.

• Includes full-time and part-time employed nonstudents, including remote workers. Commuting is not required.
• Excludes all students, including employed students. Initialization preserves source student status before existing recodes can obscure it.
• Proxies personal income with household income divided by the number of employed household members counted directly from person records. Employed students and remote workers contribute to this denominator; the shared household num_workers field is unchanged.
• Uses ActivitySim simulation and random streams, validates required inputs, and records probabilities, assignments, income provenance, and eligibility status. Known excluded people have a null Boolean result rather than being labeled flexible.
• Provides industry/income summaries, tracing, configuration files, focused tests, and operational documentation.

“Fixed” means the same recurring required work hours across days, not merely a preference for regular hours. Someone outside this category is not necessarily free to change hours: employer-controlled rotating schedules, for example, are distinct from recurring fixed schedules.

Planned, not implemented: schedule assignment and enforcement

The design document proposes approximately 32 shared work start/end pairs and a separate probability table by industry and full-/part-time status. These are conditional distributions among people already classified as fixed, not another model of whether they are fixed. No runtime schedule catalog, schedule draws, scheduling wrapper, timetable reservations, or downstream enforcement has been added in this PR.

The intended implementation would draw and persist required work hours, reserve fixed obligations first, take fixed work tours out of the ordinary mandatory scheduling choice set, and run the existing scheduling model for the remaining tours. Remote workers would receive a work reservation without an artificial commute.

Why the downstream work is more complicated than filtering a chooser set

1. Work hours and tour times are different. An 08:00 work start is an arrival requirement, not the time to leave home. Congestion may change travel departure, but must not move the fixed work interval.
2. Mode and stop choices occur later. Mandatory tour scheduling precedes tour mode choice, stop generation, and trip scheduling. A reservation based on auto time or an arbitrary buffer cannot guarantee feasibility for every later mode or stop chain. Final trips must meet workplace arrival/departure anchors as well as the tour bounds.
3. The current frequency model can create multiple work tours. It includes work2 and work_and_school. The one-episode assumption must be enforced before tour creation, preserving consistent IDs, counts, and person frequency attributes; deleting a second tour afterward is insufficient.
4. Home work is modeled separately. The existing arrangement/duration models can imply home work alongside an on-site tour. Fixed workers need one consistent daily work location and interval, including on days with no mandatory tour. Their home-work duration cannot independently contradict the fixed interval.
5. Other activities must yield to the reservation. Nonmandatory choices, household participation, escorting, and at-work subtours must respect fixed work. A valid no-activity outcome is necessary when an optional activity cannot fit.
6. The current time framework is limited. Tour alternatives use hourly values from 05:00 to 23:00. Exact work anchors, outward rounding of reserved windows, travel at the horizon boundaries, and timetable persistence require explicit handling. Overnight work would require a broader time-framework change.

Confirmed policy for the first scheduling prototype

• One work episode per working day for a fixed worker; no split shifts or multiple daily work episodes.
• Daytime/evening coverage initially; overnight shifts deferred and documented as unsupported.
• Block the entire work interval against other activities, including at-work lunch and errand subtours.
• Fixed work is the only fixed-schedule commitment for this eligible population; other activities and travel must fit around it.
• Required work hours must not change in response to transportation incentives, congestion, or infeasible optional activities. Do not redraw shifts to conceal failures.

Decisions needed before successful downstream implementation

• Daily attendance and home/on-site reconciliation: determine when an assigned recurring schedule is active, and resolve cases where current models predict both home work and on-site work. The plan proposes on-site work taking precedence over additional home work, but that priority remains for review.
• Schedule probabilities and duration interpretation: review the complete industry-by-employment-status weights, the meaning of the required interval versus paid hours, and treatment of repeating weekly patterns. Part-time workers may work full-length individual days. The eventual survey and validation method are not yet known.
• Travel feasibility and time resolution: agree on arrival/waiting allowances, rounding, and how modes and stop chains fit around the anchors. The proposed conservative envelope is one option, but can suppress otherwise feasible optional activities. Decide whether that approximation is acceptable or whether fixed-tour mode choice must move earlier.
• Failure handling: specify run-level handling of an unsupported schedule or an impossible work-only commute. Report person/household/schedule IDs, anchors, failed stage, and reason; distinguish true infeasibility from correctly excluded optional activities. Few or no failures are expected, but diagnostics must capture them and report zero counts explicitly.

The detailed proposal and example schedules are in docs/fixed-work-scheduling-plan.md; implemented behavior and limitations are in docs/fixed-work-schedule.md.

Validation

• 15 focused component tests passed, including actual CSV/YAML evaluation, all industry anchors, income response, employed-student exclusion, denominator counting, invalid/empty inputs, row-order and process-partition repeatability, explicit error terms, reversed alternative ordering, and Parquet persistence.
• A seed-0, 100-household CLI smoke run through initialization, classification, and export matched the two-process run and the resumed run exactly. The sample contained 270 people and 125 eligible workers; all 88 source-identified students were excluded.
• Ruff lint/format, strict YAML lint for the new settings, Markdown formatting, and Git whitespace checks passed.
• The repository-wide run before the final two focused tests had 71 passes and 38 failures, all in unchanged system-monitor tests expecting APIs missing from the current monitor implementation. This PR does not fix those failures.
• No complete downstream transport-model validation, behavioral calibration, or scheduling performance benefit is claimed. Downstream enforcement remains unimplemented.

Branch scope / inherited changes

This is the requested PR from wsp-sag:feature/fixed-work-schedule to CTPSSTAFF:main. The feature branch was created from local workshoppe, not upstream main. At opening it contains 73 commits ahead of upstream, including inherited telework, other constraints, developer tooling, model-test infrastructure, execution/backend changes, and input updates. Several have separate open upstream PRs (#17, #18, #19, #20, #21, #23, and #24); this PR is not an isolated four-commit diff against current upstream main.

The fixed-work-schedule work itself consists of:

• 2050809 — design and prototype assumptions
• 15c9466 — classification component and initial tests
• 0d3b310 — validation and operational documentation
• 6fb4fb3 — downstream scheduling integration plan

These four commits can be reviewed as the feature-specific increment; the larger inherited diff needs coordination with the existing upstream work before merging.