System Requirements Document for leave-management-employees

1. Introduction

This document specifies the system requirements for leave-management-employees, an internal, web-based leave management system for a single company in Singapore, initially serving approximately 500 employees.

The product intent is to give one company a single, trustworthy place to record and process employee leave: employees create and submit their own annual and medical leave applications; Direct Managers provide single-level approval or rejection; and HR Administrators maintain leave rules and correct leave data with auditable records. Leave is calculated in full or half-days against the Singapore work calendar, and leave balances are synced daily from Workday. Submissions are blocked when balances are insufficient or data is missing, and those blocked cases are escalated to HR for handling.

The audience for this document is the delivery team building the system, the HR function that owns the leave rules, and the company's identity and integration owners who provide the existing OIDC-based Single Sign-On and the Workday balance feed.

Two items remain deliberately open and are recorded as pending clarification rather than assumed: the notification channels and timing, and the employee-facing confirmation message shown on successful submission. No suggestion for either item is auto-confirmed on the user's behalf.

2. System Overview

The system is a single-company internal web application. It is not a consumer product, not a mobile application, and not a multi-tenant service. It supports exactly three fixed roles — Employee, Direct Manager, and HR Administrator — and enforces role-based data access on top of the company's existing OIDC-based Single Sign-On.

Current delivery covers:

• Leave types: annual leave and medical leave only, in the initial phase.
• Leave duration: calculated in full or half-days based on the Singapore work calendar.
• Balances: synced daily from Workday.
• Submission gate: submissions are blocked if balances are insufficient or data is missing; such cases are escalated to HR for handling.
• Process statuses: Draft, Pending Approval, Approved, Rejected, and Cancelled.
• Withdrawal and cancellation: pending requests can be withdrawn for modification; cancellations after approval require re-confirmation by the Direct Manager.
• Approval shape: single-level approval or rejection by the Direct Manager. Multi-level approval, delegation, and automatic approval or rejection are not supported.
• Audit: immutable audit logs of approvals and changes, retained for two years.
• Service targets: 95% of applications processed within two working days; 99.5% monthly availability.

2a. Product Interpretation and Delivery Boundary

Delivery ownership. The product is delivered as a first-party internal web application. The company's existing OIDC-based Single Sign-On is the authentication authority: it authenticates returning users and supplies the role information (Employee, Direct Manager, HR Administrator) that the application uses for role-based data access decisions. The application does not create, store, or manage credentials, and it does not offer self-service account creation, password reset, or profile administration. Workday is the external owner of leave balance data; the application consumes the daily sync and does not become the system of record for balances.

Access boundary. The public entry surface is anonymous and explains the internal leave service, its three roles, and its purpose before authentication. All working destinations — personal leave requests, new leave requests, cancellation requests, approvals, leave rules, data corrections, and escalations — require an authenticated session with the appropriate role. The anonymous entry surface never exposes protected leave state.

Current versus future. Everything described in this document is current-phase scope. The initial phase explicitly excludes mobile apps, payroll integration, attachment storage, and multi-tenant/cross-company support. Notification channels and timing, and the employee-facing submission confirmation message, remain pending clarification and are not treated as decided behavior.

2b. Source Content Inventory

Not applicable. No reference directive in this project declares a content_source, so no source content inventory is produced.

2c. Page Content and Component Coverage

Landing

• Information and state: Anonymous first impression of the internal Singapore leave service. States the company context, the three fixed roles (Employee, Direct Manager, HR Administrator), the two supported leave types (annual leave, medical leave), full/half-day calculation against the Singapore work calendar, daily Workday balance sync, and the five process statuses. No protected leave data is shown.
• Primary action: Sign in with the company's existing OIDC-based Single Sign-On.
• Supporting actions: Read the role descriptions; read the status legend (Draft, Pending Approval, Approved, Rejected, Cancelled); read the escalation note explaining that blocked submissions go to HR.
• Domain entities: Role, Leave Type, Process Status, Singapore Work Calendar (public holidays and weekends), Workday balance sync (described, not displayed per person).
• Component responsibilities: Wordmark and company line; balance-board hero composed of ruled label/value rows with signal rules; primary SSO action; secondary "View my requests" affordance that routes to authentication; current-month calendar strip showing public holidays as ink ticks and today as a red rule; status legend; escalation note.
• States: Loading — static content, no data fetch required. Empty — not applicable. Success — page renders and the SSO action is available. Error — if the identity provider is unreachable, the SSO action surfaces an inline message stating that sign-in is temporarily unavailable and to retry. Recovery — retry the SSO action; no partial session is created.

Leave Requests

• Information and state: The authenticated Employee's own leave requests across all five statuses. Each request row shows leave type, date range, day count in full/half-days, current status, and last change timestamp. Requests are the employee's own only.
• Primary action: Open a request to view its detail and available actions.
• Supporting actions: Start a new leave request; withdraw a Pending Approval request for modification; open the cancellation workflow for an Approved request; filter by status.
• Domain entities: Leave Request, Leave Type, Process Status, Day Count, Date Range, Audit reference.
• Component responsibilities: Request list as a ruled label/value table; status chip per row (1px ink border, 2px left signal bar, uppercase status name); status filter; "New leave request" action; per-row actions appropriate to the row's status.
• States: Loading — ruled skeleton rows hold column widths. Empty — a plain statement that no leave requests exist yet, with the "New leave request" action. Success — rows render with status chips and day counts in tabular figures. Error — if the request list cannot be loaded, an inline error states the list is unavailable and offers retry; no stale data is presented as current. Recovery — retry the load; if the failure persists, the employee is told to contact HR.

New Leave Request

• Information and state: A focused form for creating, validating, submitting, and modifying an annual or medical leave request. Shows the employee's current Workday-synced balance for the selected leave type, the requested day count, and the resulting balance position.
• Primary action: Submit the leave request.
• Supporting actions: Save as Draft; select leave type (annual or medical); select date range; choose full-day or half-day via a two-cell segmented control; modify a withdrawn request and resubmit.
• Domain entities: Leave Request, Leave Type, Date Range, Day Part (full/half), Day Count, Workday-synced Balance, Singapore Work Calendar, Escalation.
• Component responsibilities: Label/value form table with hairline rules; leave-type selector; date-range input; half-day segmented control with a hard 1px divider; live balance gauge rendered as a ruled gauge above the submit button; validation summary; submit action; save-as-draft action.
• States: Loading — balance and calendar data load before the form becomes submittable. Empty — a new, unsaved request begins in Draft with no dates selected. Success — the request is submitted and moves to Pending Approval, and the confirmation message is displayed (see pending clarification). Error — insufficient balance or missing data blocks submission, the balance gauge turns red, and the case is escalated to HR for handling; a Workday sync failure or unavailable calendar data also blocks submission with an explanatory message. Recovery — the employee adjusts dates, day part, or leave type and resubmits; a blocked case remains visible as escalated to HR until HR handles it.

Cancellation Requests

• Information and state: A shared workflow for requesting and re-confirming cancellation of approved leave. The Employee sees their approved requests and the cancellation state of each; the Direct Manager sees cancellation requests awaiting their re-confirmation.
• Primary action (Employee): Request cancellation of an approved leave request.
• Primary action (Direct Manager): Re-confirm the cancellation.
• Supporting actions: View the original approved request detail; view the reason recorded for the cancellation request; view the resulting status after re-confirmation.
• Domain entities: Leave Request, Process Status (Approved, Cancelled), Cancellation Request, Re-confirmation, Audit entry.
• Component responsibilities: Approved-request list; cancellation request form; pending re-confirmation queue for the Direct Manager; status chip showing Approved or Cancelled; audit reference for the re-confirmation.
• States: Loading — queue and request detail load with ruled skeletons. Empty — no approved requests available to cancel (Employee), or no cancellation requests awaiting re-confirmation (Direct Manager). Success — the cancellation request is recorded and awaits re-confirmation; after re-confirmation the request status becomes Cancelled. Error — if the cancellation request or the re-confirmation cannot be recorded, an inline error states the action did not complete and offers retry; the request remains in its prior status. Recovery — retry the action; the prior status is preserved until the action succeeds.

Approvals

• Information and state: The Direct Manager's queue of submitted leave requests from their team, with leave type, date range, day count, employee, and current status. Each item shows the request detail needed to decide.
• Primary action: Approve or reject a submitted request.
• Supporting actions: Open request detail; review the employee's balance position at submission; record a rejection reason; view the audit reference for the decision.
• Domain entities: Leave Request, Process Status (Pending Approval, Approved, Rejected), Employee, Day Count, Audit entry.
• Component responsibilities: Approval queue as a ruled table; request detail panel; approve action; reject action with reason; status chip; audit reference line.
• States: Loading — queue loads with ruled skeletons. Empty — a plain statement that no requests are awaiting approval. Success — the decision is recorded, the request moves to Approved or Rejected, and the decision is written to the immutable audit log. Error — if the decision cannot be recorded, an inline error states the decision was not saved and offers retry; the request stays in Pending Approval. Recovery — retry the decision; no partial decision is recorded.

Leave Rules

• Information and state: The HR Administrator's view of the annual and medical leave rules, including entitlement values and how leave is calculated in full or half-days against the Singapore work calendar.
• Primary action: Maintain a leave rule (create, update, or retire a rule for annual or medical leave).
• Supporting actions: View the current rule set; view the Singapore work calendar basis used for day calculation; view the audit reference for each rule change.
• Domain entities: Leave Rule, Leave Type (annual, medical), Entitlement, Day Part (full/half), Singapore Work Calendar, Audit entry.
• Component responsibilities: Rule list as a ruled label/value table; rule editor; calendar basis reference; audit reference per change.
• States: Loading — rule list loads with ruled skeletons. Empty — a plain statement that no rules are defined yet, with the create action. Success — the rule change is saved and written to the immutable audit log. Error — if the rule change cannot be saved, an inline error states the change was not saved and offers retry; the prior rule remains in force. Recovery — retry the save; the prior rule is preserved until the save succeeds.

Data Corrections

• Information and state: The HR Administrator's workspace for correcting leave data, showing the current value, the corrected value, and the auditable change record for each correction.
• Primary action: Apply a data correction.
• Supporting actions: Search or select the leave record to correct; view before/after values; view the audit reference for the correction.
• Domain entities: Leave Record, Correction, Before/After Values, Audit entry, Retention Window (two years).
• Component responsibilities: Record lookup; correction form as a label/value table; before/after comparison; audit reference line; retention label.
• States: Loading — record lookup loads with ruled skeletons. Empty — a plain statement that no record is selected. Success — the correction is saved and written to the immutable audit log with before/after values. Error — if the correction cannot be saved, an inline error states the correction was not saved and offers retry; the original value remains. Recovery — retry the correction; the original value is preserved until the save succeeds.

Escalations

• Information and state: The HR Administrator's queue of submissions blocked by insufficient balances or missing data, showing the employee, the leave type and dates requested, the blocking reason, and the current handling state.
• Primary action: Handle an escalated case.
• Supporting actions: View the blocking reason (insufficient balance or missing data); view the employee's Workday-synced balance; record the handling outcome; view the audit reference.
• Domain entities: Escalation, Blocking Reason (insufficient balance, missing data), Employee, Workday-synced Balance, Audit entry.
• Component responsibilities: Escalation queue as a ruled table; case detail; blocking-reason label; handling action; audit reference line.
• States: Loading — queue loads with ruled skeletons. Empty — a plain statement that no cases are escalated. Success — the case is handled and the outcome is written to the immutable audit log. Error — if the handling outcome cannot be recorded, an inline error states the outcome was not saved and offers retry; the case remains escalated. Recovery — retry the handling action; the case stays in the queue until the outcome is recorded.

3. Functional Requirements

Each requirement is stated as a story point with provenance, lifecycle facts, and observable acceptance.

FR-01 — Employee creates and submits their own leave application (explicit) As an Employee, I should create and submit my own leave application so that my leave is recorded and routed for approval.

• Trigger/input: authenticated Employee opens New Leave Request and provides leave type, date range, and full/half-day selection.
• Observable result: the request is created and, on successful submission, moves to Pending Approval.
• Access state: authenticated Employee session; the employee can act only on their own applications.
• Failure/recovery: if submission is blocked, the blocking reason is shown and the case is escalated to HR (FR-08).
• Continuation: the request appears in Leave Requests with its current status.

FR-02 — Employee tracks request status across all defined statuses (explicit) As an Employee, I should see the status of each of my requests so that I know where it stands.

• Trigger/input: authenticated Employee opens Leave Requests.
• Observable result: each request shows one of Draft, Pending Approval, Approved, Rejected, or Cancelled.
• Access state: authenticated Employee; own requests only.
• Failure/recovery: if the list cannot be loaded, an inline error offers retry.
• Continuation: the employee opens a request to act on it.

FR-03 — Employee withdraws a pending request for modification (explicit) As an Employee, I should withdraw a Pending Approval request so that I can modify and resubmit it.

• Trigger/input: authenticated Employee selects a Pending Approval request and withdraws it.
• Observable result: the request leaves Pending Approval and becomes modifiable.
• Access state: authenticated Employee; own Pending Approval requests only.
• Failure/recovery: if the withdrawal cannot be recorded, an inline error offers retry and the request stays Pending Approval.
• Continuation: the employee modifies the request in New Leave Request and resubmits.

FR-04 — Employee requests cancellation of approved leave (explicit) As an Employee, I should request cancellation of an approved leave request so that leave I no longer need is released.

• Trigger/input: authenticated Employee selects an Approved request and requests cancellation.
• Observable result: a cancellation request is recorded and awaits re-confirmation by the Direct Manager.
• Access state: authenticated Employee; own Approved requests only.
• Failure/recovery: if the cancellation request cannot be recorded, an inline error offers retry and the request stays Approved.
• Continuation: the Direct Manager re-confirms (FR-05).

FR-05 — Direct Manager re-confirms cancellation after approval (explicit) As a Direct Manager, I should re-confirm a cancellation of approved leave so that the cancellation is authorized.

• Trigger/input: authenticated Direct Manager opens Cancellation Requests and re-confirms a pending cancellation.
• Observable result: the leave request status becomes Cancelled and the re-confirmation is written to the immutable audit log.
• Access state: authenticated Direct Manager; cancellation requests for their team.
• Failure/recovery: if the re-confirmation cannot be recorded, an inline error offers retry and the request stays Approved.
• Continuation: the employee sees the Cancelled status in Leave Requests.

FR-06 — Direct Manager provides single-level approval or rejection (explicit) As a Direct Manager, I should approve or reject a submitted leave request in a single step so that my team's leave decisions are made promptly.

• Trigger/input: authenticated Direct Manager opens Approvals and records an approve or reject decision on a Pending Approval request.
• Observable result: the request moves to Approved or Rejected and the decision is written to the immutable audit log.
• Access state: authenticated Direct Manager; submitted requests from their team.
• Failure/recovery: if the decision cannot be recorded, an inline error offers retry and the request stays Pending Approval.
• Continuation: the employee sees the resulting status in Leave Requests.
• Constraint: approval is single-level only; multi-level approval, delegation, and automatic approval or rejection are not supported.

FR-07 — Leave is calculated in full or half-days on the Singapore work calendar (explicit) As an Employee, I should have my leave calculated in full or half-days against the Singapore work calendar so that my day count is correct.

• Trigger/input: the employee selects a date range and a full-day or half-day option.
• Observable result: the requested day count is computed in full or half-days using the Singapore work calendar.
• Access state: authenticated Employee.
• Failure/recovery: if calendar data is unavailable, submission is blocked with an explanatory message.
• Continuation: the computed day count is shown on the request and used for balance validation.

FR-08 — Submissions are blocked and escalated when balances are insufficient or data is missing (explicit) As an Employee, I should be blocked from submitting when my balance is insufficient or data is missing, and have my case escalated to HR, so that incorrect leave is never recorded.

• Trigger/input: the employee attempts to submit a request whose requested days exceed the Workday-synced balance, or whose required data is missing.
• Observable result: submission is blocked, the blocking reason is shown, and the case is escalated to HR for handling.
• Access state: authenticated Employee.
• Failure/recovery: the employee adjusts the request and resubmits, or HR handles the escalated case.
• Continuation: the escalated case appears in the HR Escalations queue.

FR-09 — HR Administrator handles escalated blocked cases (explicit) As an HR Administrator, I should handle cases escalated because of insufficient balances or missing data so that blocked leave is resolved.

• Trigger/input: authenticated HR Administrator opens Escalations and handles a case.
• Observable result: the case is handled and the outcome is written to the immutable audit log.
• Access state: authenticated HR Administrator.
• Failure/recovery: if the outcome cannot be recorded, an inline error offers retry and the case remains escalated.
• Continuation: the employee can resubmit or the request proceeds according to the handling outcome.

FR-10 — HR Administrator maintains leave rules (explicit) As an HR Administrator, I should maintain the annual and medical leave rules so that leave is calculated correctly.

• Trigger/input: authenticated HR Administrator creates, updates, or retires a leave rule in Leave Rules.
• Observable result: the rule set reflects the change and the change is written to the immutable audit log.
• Access state: authenticated HR Administrator.
• Failure/recovery: if the change cannot be saved, an inline error offers retry and the prior rule remains in force.
• Continuation: subsequent leave calculations use the updated rule.

FR-11 — HR Administrator corrects leave data with auditable records (explicit) As an HR Administrator, I should correct leave data so that records stay accurate, with every correction auditable.

• Trigger/input: authenticated HR Administrator selects a leave record in Data Corrections and applies a correction.
• Observable result: the corrected value is saved and the before/after values are written to the immutable audit log.
• Access state: authenticated HR Administrator.
• Failure/recovery: if the correction cannot be saved, an inline error offers retry and the original value remains.
• Continuation: the corrected record is visible with its audit reference.

FR-12 — Daily Workday balance synchronization (explicit) As an Employee, I should have my leave balances synced daily from Workday so that my balance position is current.

• Trigger/input: the daily Workday sync runs.
• Observable result: balances used for validation and display reflect the latest completed sync.
• Access state: system process; no human interaction required for the sync itself.
• Failure/recovery: if the sync has not completed or current data is unavailable, submission validation is blocked and the condition is surfaced.
• Continuation: once current data is available, validation proceeds normally.

FR-13 — Immutable audit logging with two-year retention (explicit) As an HR Administrator, I should rely on immutable audit logs of approvals and changes retained for two years so that every decision and correction is traceable.

• Trigger/input: an approval, rejection, cancellation re-confirmation, rule change, or data correction occurs.
• Observable result: an immutable audit entry is written with timestamp, actor, action, and before/after values where applicable, and is retained for two years.
• Access state: audit entries are written by the system; HR Administrators can view audit references.
• Failure/recovery: if an audit entry cannot be written, the associated action does not complete.
• Continuation: the audit register remains the authoritative record of approvals and changes.

FR-14 — Role-based data access (explicit) As an HR Administrator, I should have role-based data access enforced so that each role sees only what its work requires.

• Trigger/input: any authenticated request to a protected destination.
• Observable result: access is granted or denied according to the authenticated role (Employee, Direct Manager, HR Administrator).
• Access state: authenticated session with role information supplied by the existing OIDC-based SSO.
• Failure/recovery: a denied request returns an access-denied state without exposing protected data.
• Continuation: the user returns to a destination their role permits.

FR-15 — Authentication via existing OIDC-based Single Sign-On (explicit; entry mechanics required_inference) As an Employee, I should sign in with the company's existing OIDC-based Single Sign-On so that I reach my leave work without a separate account.

• Trigger/input: an unauthenticated visitor selects the sign-in action on Landing.
• Observable result: the identity provider authenticates the user and returns role information used for access decisions.
• Access state: anonymous entry on Landing; protected destinations require an authenticated session.
• Failure/recovery: if the identity provider is unreachable, an inline message states sign-in is temporarily unavailable and offers retry; no partial session is created.
• Continuation: the authenticated user reaches the destinations their role permits.

FR-16 — Employee modifies a withdrawn request and resubmits (explicit) As an Employee, I should modify a withdrawn request and resubmit it so that corrected leave is submitted without starting over.

• Trigger/input: authenticated Employee opens a withdrawn request in New Leave Request, changes it, and resubmits.
• Observable result: the modified request is validated and, if it passes, moves to Pending Approval.
• Access state: authenticated Employee; own withdrawn requests only.
• Failure/recovery: if validation blocks submission, the blocking reason is shown and the case is escalated to HR.
• Continuation: the request appears in Leave Requests with its current status.

4. User Personas

Employee

Product context. An Employee works at the single Singapore company covered by this system. They apply for their own annual and medical leave, in full or half-days, against the Singapore work calendar, and their balances come from the daily Workday sync. They are the only role that creates and submits leave applications.

Primary goal. Have their leave recorded accurately and processed without balance or data blockers.

Distinct accepted responsibilities. Creating and submitting their own leave applications; tracking each request across Draft, Pending Approval, Approved, Rejected, and Cancelled; withdrawing a Pending Approval request so it can be modified and resubmitted; requesting cancellation of an approved leave request; and responding when a submission is blocked by insufficient balance or missing data.

Relevant inputs and decisions. Leave type (annual or medical); date range; full-day or half-day selection; whether to save as Draft or submit; whether to withdraw and modify a pending request; whether to request cancellation of approved leave.

Interactions with other accepted participants. The Employee's submission is decided by their Direct Manager, who approves or rejects it in a single step and re-confirms any cancellation after approval. When a submission is blocked by insufficient balance or missing data, the case is escalated to the HR Administrator, who handles it.

Observable success. The request shows the correct status, the day count matches the Singapore work calendar in full or half-days, and no balance or data blocker remains unresolved.

Direct Manager

Product context. A Direct Manager manages one or more Employees at the same company. Their work is a decision queue, not an application form: they review submitted leave requests from their team and record a single-level decision.

Primary goal. Have their team's leave decisions made promptly and recorded in the audit trail within the two-working-day processing target.

Distinct accepted responsibilities. Reviewing submitted leave requests in Approvals; approving or rejecting each request in a single step; recording a rejection reason; and re-confirming cancellations of approved leave in Cancellation Requests.

Relevant inputs and decisions. The request detail (employee, leave type, date range, day count, balance position at submission); the approve-or-reject decision; the rejection reason; the re-confirmation decision on a cancellation.

Interactions with other accepted participants. The Direct Manager acts on submissions created by Employees and produces the Approved or Rejected outcome the Employee sees. Their re-confirmation is what turns an approved request into a Cancelled one. Their decisions are written to the immutable audit log that HR Administrators rely on.

Observable success. Every submitted request in their queue reaches a recorded decision, and every cancellation re-confirmation is recorded, within the processing target.

HR Administrator

Product context. An HR Administrator owns the rules and the record. They maintain the annual and medical leave rules that drive calculation, correct leave data when it is wrong, and handle the cases that the submission gate escalates to them.

Primary goal. Keep leave rules and balances accurate, and make every correction traceable in the immutable audit log.

Distinct accepted responsibilities. Maintaining annual and medical leave rules based on the Singapore work calendar; correcting leave data with auditable before/after records; and handling submissions blocked by insufficient balances or missing data.

Relevant inputs and decisions. Entitlement values and rule definitions; the leave record selected for correction and its corrected value; the blocking reason on an escalated case (insufficient balance or missing data) and the handling outcome.

Interactions with other accepted participants. The HR Administrator receives escalations triggered by Employee submissions that the submission gate blocked, and their rule maintenance determines how Employees' leave is calculated. Their corrections and rule changes are recorded in the same immutable audit log that captures Direct Manager approvals.

Observable success. Rules reflect current policy, corrections are saved with before/after values, escalated cases are handled, and every change is traceable for two years.

5. Core User Flows

Flow 1 — Employee submits an annual or medical leave request

1. The Employee opens Landing and selects the sign-in action.
2. The existing OIDC-based Single Sign-On authenticates the Employee and returns their role. If the identity provider is unreachable, an inline message states sign-in is temporarily unavailable and the Employee retries.
3. The Employee opens New Leave Request.
4. The Employee selects the leave type (annual or medical), the date range, and full-day or half-day using the two-cell segmented control.
5. The system computes the day count in full or half-days against the Singapore work calendar and shows the Workday-synced balance and the resulting balance position on the ruled gauge above the submit button.
6. The Employee submits.
7. Observable result: the request moves to Pending Approval and the confirmation message is displayed (see pending clarification). The request appears in Leave Requests with its status chip.
8. Failure/recovery: if the requested days exceed the synced balance, or required data is missing, or the daily Workday sync has not delivered current data, submission is blocked, the gauge turns red, the blocking reason is shown, and the case is escalated to HR for handling (Flow 7). The Employee adjusts the request and resubmits.
9. Continuation: the Employee tracks the request in Leave Requests until the Direct Manager decides (Flow 3).

Flow 2 — Employee withdraws a pending request, modifies it, and resubmits

1. The Employee opens Leave Requests and selects a request in Pending Approval.
2. The Employee withdraws the request for modification.
3. Observable result: the request leaves Pending Approval and becomes modifiable. If the withdrawal cannot be recorded, an inline error offers retry and the request stays Pending Approval.
4. The Employee opens New Leave Request, modifies the leave type, dates, or day part, and resubmits.
5. Observable result: the modified request is validated and, if it passes, returns to Pending Approval.
6. Failure/recovery: if validation blocks submission, the blocking reason is shown and the case is escalated to HR (Flow 7).
7. Continuation: the request is tracked in Leave Requests until the Direct Manager decides.

Flow 3 — Direct Manager approves or rejects a submitted request

1. The Direct Manager signs in through the existing OIDC-based Single Sign-On and opens Approvals.
2. The Direct Manager reviews the queue of submitted requests from their team, each showing employee, leave type, date range, day count, and status.
3. The Direct Manager opens a request and reviews its detail, including the balance position at submission.
4. The Direct Manager records a single-level decision: approve, or reject with a reason.
5. Observable result: the request moves to Approved or Rejected, and the decision is written to the immutable audit log with timestamp, actor, action, and before/after values.
6. Failure/recovery: if the decision cannot be recorded, an inline error states the decision was not saved and offers retry; the request stays in Pending Approval and no partial decision is recorded.
7. Continuation: the Employee sees the resulting status in Leave Requests. If the queue is empty, the Direct Manager sees a plain statement that no requests are awaiting approval.

Flow 4 — Employee requests cancellation of approved leave, and the Direct Manager re-confirms

1. The Employee opens Cancellation Requests and selects an Approved leave request.
2. The Employee requests cancellation.
3. Observable result: a cancellation request is recorded and awaits re-confirmation by the Direct Manager. If the cancellation request cannot be recorded, an inline error offers retry and the request stays Approved.
4. The Direct Manager opens Cancellation Requests and reviews the pending cancellation, including the original approved request detail.
5. The Direct Manager re-confirms the cancellation.
6. Observable result: the leave request status becomes Cancelled and the re-confirmation is written to the immutable audit log.
7. Failure/recovery: if the re-confirmation cannot be recorded, an inline error offers retry and the request stays Approved.
8. Continuation: the Employee sees the Cancelled status in Leave Requests. If no cancellation requests are pending, the Direct Manager sees a plain statement that none await re-confirmation.

Flow 5 — HR Administrator maintains leave rules

1. The HR Administrator signs in through the existing OIDC-based Single Sign-On and opens Leave Rules.
2. The HR Administrator reviews the current annual and medical leave rules and the Singapore work calendar basis used for full/half-day calculation.
3. The HR Administrator creates, updates, or retires a rule.
4. Observable result: the rule set reflects the change and the change is written to the immutable audit log.
5. Failure/recovery: if the change cannot be saved, an inline error states the change was not saved and offers retry; the prior rule remains in force.
6. Continuation: subsequent leave calculations use the updated rule. If no rules are defined yet, the HR Administrator sees a plain statement with the create action.

Flow 6 — HR Administrator corrects leave data

1. The HR Administrator opens Data Corrections and selects the leave record to correct.
2. The HR Administrator reviews the current value and enters the corrected value.
3. The HR Administrator applies the correction.
4. Observable result: the corrected value is saved and the before/after values are written to the immutable audit log.
5. Failure/recovery: if the correction cannot be saved, an inline error states the correction was not saved and offers retry; the original value remains.
6. Continuation: the corrected record is visible with its audit reference. If no record is selected, the HR Administrator sees a plain statement prompting selection.

Flow 7 — HR Administrator handles an escalated blocked submission

1. An Employee's submission is blocked because the requested days exceed the Workday-synced balance or because required data is missing.
2. Observable result: the case is escalated to HR and appears in Escalations with the employee, leave type and dates requested, and the blocking reason.
3. The HR Administrator opens Escalations and reviews the case, including the employee's Workday-synced balance and the blocking reason.
4. The HR Administrator handles the case and records the outcome.
5. Observable result: the outcome is written to the immutable audit log.
6. Failure/recovery: if the outcome cannot be recorded, an inline error states the outcome was not saved and offers retry; the case remains escalated.
7. Continuation: the Employee can resubmit or the request proceeds according to the handling outcome. If no cases are escalated, the HR Administrator sees a plain statement that none are pending.

Flow 8 — Daily Workday balance synchronization

1. The daily Workday sync runs as a system process.
2. Observable result: the balances used for display and for submission validation reflect the latest completed sync.
3. Failure/recovery: if the sync has not completed or current data is unavailable, submission validation is blocked and the condition is surfaced to the Employee attempting to submit.
4. Continuation: once current data is available, validation proceeds normally and the Employee can submit.

6. Visuals Colors and Theme

The visual system follows the supplied creative direction: typographic infrastructure for a Singapore leave desk, after the muse Erik Spiekermann. The headline idea is that a leave system is a wayfinding problem — five statuses, three roles, two leave types, half-day granularity, a Singapore work calendar, Workday-synced balances, and escalation to HR — and it should read like public infrastructure you can read at a glance: warm, ordered, signal-coded, human inside the rules.

Colour tokens (light mode).

Proportions: ~70% paper ground, ~20% white working surfaces, ~8% ink, ~2% signal colour. No gradients anywhere. No blue-indigo primary; the only blue in the system is the declared information signal #1F5C8B, used like a transit line, never as a button fill.

Typography.

• Headings and body: Fira Sans across both roles, so the system reads as one infrastructure.
• Headings at 700–800 weight, tight tracking (−0.01em), sentence case, never all-caps headlines.
• Labels and status names: 600 weight, +0.08em tracking, uppercase, 12–13px — signage, not shouting.
• Numerals are the ornament: leave balances, day counts, and audit timestamps set in Fira Sans with tabular figures (font-variant-numeric: tabular-nums) at 700 weight, so 12.5 days and 0.5 day align in a column like a timetable.
• Body at 400/16px with 1.55 line-height for long HR rule text.
• Scale: 1.250 modular on a 4px baseline — display clamp(3.5rem, 6vw, 5.5rem) (56px mobile → 88px desktop), h1 32/40, h2 24/28, h3 20/24, body 16/25, label 13/16 uppercase +0.08em, micro 12/16. Weights: 800 display, 700 headings and numerals, 600 labels, 400 body.

Shape language. Functional and honest: 4px radius on inputs, buttons, and chips — no pill buttons, no 24px soft cards. 2px solid rules do the structural work (section dividers, table header underlines, the signal line beside a status). Status chips are small rectangles with a 1px ink border and a 2px left signal bar in the status colour, not filled lozenges. The half-day toggle is a two-cell segmented control with a hard 1px divider, reading like a mechanical switch. Nothing decorative that is not also functional.

Layout. A strict 12-column grid on a 1200px content measure with 48px outer margins at desktop, 24px at tablet, 16px at mobile. The left rail (240px) is the wayfinding spine: role, name, and a numbered nav — 01 Apply, 02 My Requests, 03 Approvals, 04 Balances, 05 HR Rules, 06 Audit Log. Content is single-column and tabular: label/value pairs flush-left with a hairline rule between rows, so a leave request reads like a departure board. The apply form is a two-column label/value table, not a floating card stack. Status always sits in the same screen position (top-right of the request header). At 375px the rail collapses to a horizontal numbered tab strip; the label/value table stacks label above value; nothing is cropped or overlapped.

Imagery. No photography and no illustration for its own sake. Imagery is diagrammatic and drawn from the product's own data: a Singapore public-holiday calendar strip as a horizontal timeline with holiday dates as ink ticks and weekends as muted bands; a leave-balance bar as a ruled gauge with entitlement and taken lines labelled at the ends; audit-log entries as numbered rows with timestamp, actor, action, and before/after values. Icons are 24px, 2px stroke, geometric and consistent — a departure-board pictogram set, not clip art.

7. Signature Design Concept

The public entry is a departure board, not a SaaS hero.

Full-width warm paper ground #F4F1EA. Top-left: the wordmark Leave set in Fira Sans 800 at 40px with a 2px ink rule under it, and beneath it the company line in 13px uppercase +0.08em muted.

The dominant element is the balance board: three ruled rows spanning the full content width — Annual leave 12.5 days, Medical leave 8.0 days, Pending approval 2 — each set as a label/value pair with the numeral at clamp(3.5rem, 6vw, 5.5rem) in 700 weight tabular figures, right-aligned in its own column, with a 2px signal rule at the left edge of each row (green for sufficient, red for pending).

Below the board, one wide primary action cut into the paper as a solid red #B3121B rectangle with white 700 text Apply for leave, and a hard-edged secondary View my requests in ink with a 2px underline. Both route to the existing OIDC-based Single Sign-On.

To the right at desktop, a narrow vertical calendar strip for the current month shows public holidays as ink ticks and today as a red 2px rule.

No centred headline, no subtext stack, no gradient, no illustration — the numbers are the hero and they are set like a timetable you can read from three metres away. The concept recomposes only accepted content, states, and controls: it introduces no new behaviour, page, or destination.

8. Interaction Model & Motion Direction

Interaction Model: Static Motion Tempo: restrained Hero Dimensionality: flat

Landing Hero Motion Brief

• Focal subject: the balance board — three full-width ruled rows with tabular numerals right-aligned in their own columns and a 2px signal rule at each row's left edge.
• Input → transformation → outcome thesis: on first paint, the balance numerals count up once over 400ms with tabular figures holding their column width; the outcome is a board that has settled into its final, readable state, exactly as a departure board settles. The motion uses only accepted behaviour — it displays the employee's Workday-synced balance position and pending count; it does not create, submit, or change anything.
• Motion vocabulary: functional and short — 120–160ms linear-ish transitions on hover, focus, and status change; a status chip cross-fades its signal bar colour rather than sliding. No bounce, no float, no parallax, no particles.
• Composed first frame: warm paper ground #F4F1EA; wordmark Leave in Fira Sans 800 at 40px with a 2px ink rule beneath it and the company line in 13px uppercase +0.08em muted; the three ruled balance rows with their signal rules already in place; the solid red Apply for leave rectangle and the ink-underlined View my requests; the narrow vertical calendar strip at the right with holiday ink ticks and today's red 2px rule.
• Reduced-motion state: under prefers-reduced-motion the count-up resolves instantly and all transitions become 0ms; the board renders in its final state with no motion at all.

9. Non-Functional Requirements

NFR-01 — Authentication via existing OIDC-based Single Sign-On (explicit) The system must use the company's existing OIDC-based Single Sign-On. Rationale: the company already operates an identity provider, and the system must not introduce a separate credential store.

NFR-02 — Role-based data access enforcement (explicit) The system must enforce role-based data access for the three fixed roles. Rationale: each role's work requires a different slice of leave data, and access must follow the authenticated role.

NFR-03 — Immutable audit logs retained for two years (explicit) The system must retain immutable audit logs of approvals and changes for two years. Rationale: approvals and corrections must remain traceable for the stated retention window.

NFR-04 — Processing target: 95% within two working days (explicit) 95% of applications must be processed within two working days. Rationale: the company's stated service level for leave decisions.

NFR-05 — Monthly availability: 99.5% (explicit) The system must achieve 99.5% monthly availability. Rationale: the company's stated availability target for this internal service.

NFR-06 — Daily Workday balance synchronization (explicit) Leave balances must be synced daily from Workday. Rationale: balances used for validation and display must reflect the authoritative external source.

NFR-07 — Scale: single company in Singapore, ~500 employees initially (explicit) The system must serve a single company in Singapore, initially approximately 500 employees. Rationale: this bounds the deployment and capacity envelope.

NFR-08 — Singapore work calendar basis (explicit) Leave calculation must use the Singapore work calendar. Rationale: full/half-day calculation depends on which days are working days in Singapore.

NFR-09 — Web-based delivery only in the initial phase (explicit) The initial phase excludes mobile apps. Rationale: the stated phase-one boundary.

NFR-10 — No payroll integration in the initial phase (explicit) The initial phase excludes payroll integration. Rationale: the stated phase-one boundary.

NFR-11 — No attachment storage in the initial phase (explicit) The initial phase excludes attachment storage. Rationale: the stated phase-one boundary.

NFR-12 — No multi-tenant or cross-company support in the initial phase (explicit) The initial phase excludes multi-tenant/cross-company support. Rationale: the stated phase-one boundary; the system serves one company.

NFR-13 — No multi-level approval, delegation, or automatic decisions (explicit) Multi-level approval, delegation, and automatic approval or rejection are not supported. Rationale: the stated approval model is single-level, human-decided.

NFR-14 — No auto-confirmation of pending clarifications (explicit) No suggestion for the two pending clarification items may be auto-confirmed on the user's behalf. Rationale: the user explicitly reserved both decisions.

10. Tech Stack

• Frontend: React (web application; no mobile app in the initial phase).
• Backend: Python with FastAPI.
• Storage: a relational database for leave requests, leave rules, corrections, escalations, and the immutable audit log, with the audit log retained for two years.
• Identity: the company's existing OIDC-based Single Sign-On provider (external, company-owned).
• External integration: Workday, as the source of the daily leave balance sync.
• Packaging and deployment: Docker with docker-compose for local and single-host deployment. Kubernetes is not required by any stated constraint and is therefore not included.

11. Assumptions and Constraints

Constraints (explicit, binding).

• Single company in Singapore; approximately 500 employees initially.
• Three fixed roles only: Employee, Direct Manager, HR Administrator.
• Employees may only create and submit their own applications.
• Approval is single-level only; multi-level approval is not supported.
• Delegation is not supported.
• Automatic approval or rejection is not supported.
• Leave types are limited to annual leave and medical leave in the initial phase.
• Leave is calculated in full or half-days based on the Singapore work calendar.
• Leave balances are synced daily from Workday.
• Submissions are blocked when balances are insufficient or data is missing; such cases are escalated to HR for handling.
• Cancellations after approval require re-confirmation by the Direct Manager.
• The system must use the existing OIDC-based Single Sign-On.
• Role-based data access must be enforced.
• Immutable audit logs of approvals and changes are retained for two years.
• Target: 95% of applications processed within two working days.
• Target: monthly availability of 99.5%.
• Initial phase excludes mobile apps, payroll integration, attachment storage, and multi-tenant/cross-company support.
• No suggestions may be auto-confirmed on the user's behalf.

Assumptions (narrow, labeled).

• [Assumption — required_inference] The existing OIDC-based SSO authenticates returning users and supplies role information for Employee, Direct Manager, and HR Administrator access decisions. The application does not create or manage credentials.
• [Assumption — required_inference] The daily Workday balance sync must complete, or expose current data, before submission validation can pass; otherwise submission is blocked.
• [Assumption — required_inference] Submission validation checks balance sufficiency and required data before allowing submission, and blocked cases are escalated to HR.
• [Assumption — required_inference] Direct Manager approval or rejection is required for submitted requests, and Direct Manager re-confirmation is required for cancellation of approved leave.
• [Assumption — required_inference] Immutable audit logging records approvals and changes and retains them for two years.
• [Assumption — required_inference] The anonymous Landing surface is the pre-authentication entry point; protected destinations require an authenticated session with the appropriate role.

Pending clarification (not decided; no suggestion auto-confirmed).

• Notification channels and timing. Multiple comparable directions exist. This must be confirmed in a single round of clarification using an options question that presents the choices and provides a single recommended option. Until confirmed, no notification channel or timing is treated as accepted behavior.
• Employee-facing confirmation message on successful submission. This is an open-ended content question that cannot be exhaustively enumerated. It must be confirmed in a single round of clarification using a free-text question that proposes a recommended answer along with its rationale. Until confirmed, the confirmation message content is not treated as accepted behavior.

Presentation and technology defaults.

• [Default — not specified by user] React for the web frontend, Python/FastAPI for the backend, Docker/docker-compose for packaging, and a relational database for persistence. These fill unspecified implementation details only and do not add product behavior.

12. Glossary

• Annual leave — one of the two leave types supported in the initial phase.
• Medical leave — one of the two leave types supported in the initial phase.
• Direct Manager — the fixed role that provides single-level approval or rejection of submitted leave requests and re-confirms cancellations after approval.
• Employee — the fixed role that creates and submits their own leave applications and tracks their status.
• HR Administrator — the fixed role that maintains leave rules, corrects leave data with auditable records, and handles escalated blocked cases.
• Draft — a process status for a leave request that has been created but not submitted.
• Pending Approval — a process status for a submitted leave request awaiting the Direct Manager's single-level decision.
• Approved — a process status for a leave request accepted by the Direct Manager.
• Rejected — a process status for a leave request declined by the Direct Manager.
• Cancelled — a process status for an approved leave request whose cancellation has been re-confirmed by the Direct Manager.
• Withdrawal — the action by which an Employee removes a Pending Approval request so it can be modified and resubmitted.
• Re-confirmation — the Direct Manager's required confirmation of a cancellation after approval.
• Escalation — the routing of a blocked submission (insufficient balance or missing data) to HR for handling.
• Full-day / half-day — the granularity in which leave is calculated against the Singapore work calendar.
• Singapore work calendar — the calendar basis, including public holidays and weekends, used to calculate leave in full or half-days.
• Workday — the external system that is the source of the daily leave balance sync.
• OIDC-based Single Sign-On (SSO) — the company's existing identity mechanism used to authenticate users and supply role information.
• Immutable audit log — the append-only record of approvals and changes, retained for two years.
• Role-based data access — the enforcement that each of the three fixed roles sees only the leave data its work requires.