Time-Utility Function¶
A function that assigns an application-specific utility to completing an action at each possible time, generalizing deadlines so schedulers can optimize accrued value rather than timeliness alone.
Core Idea¶
A time/utility function replaces the binary on-time/late view with a value curve. It asks not only whether an action finishes by a deadline, but how much application utility its completion produces at each time.
The model becomes operational through utility-accrual scheduling: predicted completions are placed on their curves, utilities are aggregated, and the schedule is chosen under execution, resource, dependency, and assurance constraints.
Scope of Application¶
- Real-time computing. Represents hard, firm, soft, and graded timing value.
- Utility-accrual scheduling. Chooses work to maximize application benefit.
- Autonomous systems. Trades timeliness among sensing, planning, and actuation tasks.
- Quality-of-service control. Balances value, predictability, energy, and overload behavior.
Clarity¶
State the action, time origin, completion-time argument, utility meaning and scale, curve shape and discontinuities, critical times, post-critical behavior, execution-time estimate or distribution, release and dependencies, resources, aggregation rule, negative utility, overload and abort policy, uncertainty, optimality criterion, and assurances required. Inclusion test: Require an explicit mapping from an action's completion time to application-defined utility, with scheduling interpretations distinguishing per-action value from aggregate utility accrual. Exclusion test: Exclude a deadline stated without a value curve, economic discounting of consumption merely because time passes, processor utilization, execution-time estimates, response-time distributions, and static task priority without temporal utility semantics. Nearest boundary: A deadline says when a requirement changes; a TUF says how completion value varies across time and can represent a deadline as one particular curve. Exit condition: Recommendations change with curve shape and scale, release and execution uncertainty, dependencies, resource model, aggregation rule, overload policy, risk criterion, and whether utility after the critical time is zero, negative, or still positive. Common misclassifications: It is not merely a deadline timestamp. It is not static task priority unless priority is time-indexed. It is not necessarily monotone or zero after a critical time. It does not determine a schedule without execution and resource models. Nearest named distinctions: Deadline: Provides a temporal bound but not a general value curve. Discount function: Values delayed payoffs in intertemporal choice rather than task completion under a scheduler. Static priority: Orders tasks without necessarily changing with completion time. Response-time distribution: Describes when work completes, not the utility of that completion.
Manages Complexity¶
Completion value interacts with uncertain durations, shared resources, dependencies, preemption, overload, and noncomparable stakeholder utilities. Optimizing a sum can hide tail risk or starvation.
Abstract Reasoning¶
- Elicit the action-specific consequence of completion at different times.
- Choose an explicit time origin, scale, and curve consistent with those consequences.
- Model execution, releases, dependencies, resources, and uncertainty.
- Evaluate candidate schedules by realized utilities plus declared constraints and secondary objectives.
- Validate that the selected schedule preserves required guarantees rather than merely increasing the aggregate score.
Knowledge Transfer¶
Time-indexed value transfers to logistics, robotics, communications, and service operations when completion consequences can be elicited. Economic discount functions should not be imported unchanged: their intertemporal preference semantics differ from task-completion utility and scheduling feasibility.
Relationships to Other Abstractions¶
Current abstraction Time-Utility Function Domain-specific
Parents (1) — more general patterns this builds on
-
Time-Utility Function presupposes Utility Prime
Time-Utility Function presupposes Utility: the parent's defining role is necessary to the child's frozen mechanism or criterion.
Hierarchy path (1) — routes to 1 parentless root
- Time-Utility Function → Utility → Evaluation → Comparison → Self Checking
Neighborhood in Abstraction Space¶
Time-Utility Function sits in a moderately populated region (47th percentile for distinctiveness): it has near-neighbors but no dense thicket of look-alikes.
Family — Decision & System Modeling Frameworks (30 abstractions)
Nearest neighbors
- SATPlan — 0.87
- Time-sharing — 0.87
- Urgent Computing — 0.87
- Strategy dynamics — 0.86
- Virtual Design and Construction — 0.86
Computed from structural-signature embeddings · 2026-10-08