#U.WorkPlan: The Schedule of Intent

Pattern A.15.2 · Stable Part A - Kernel Architecture Cluster

Operations live on time. Even with perfect roles, abilities, and methods, nothing ships unless we decide when and by whom concrete runs should happen, under what constraints and budgets. Teams need a first‑class concept for plans and schedules that does not get confused with:

#Aliases

• U.WorkPlan

#Keywords

• plan
• schedule
• intent
• forecast.

#Relations

#Content

#Context (plain‑language motivation)

Operations live on time. Even with perfect roles, abilities, and methods, nothing ships unless we decide when and by whom concrete runs should happen, under what constraints and budgets. Teams need a first‑class concept for plans and schedules that does not get confused with:

• the semantic “way of doing” (that is U.Method),
• the written recipe (that is U.MethodDescription),
• the actual execution (that is U.Work), or
• the state laws (that is U.Dynamics).

U.WorkPlan is that missing anchor.

#Problem (what breaks without WorkPlan)

1. “Workflow = schedule” conflation. Flowcharts or code are used as calendars; resource clashes and SLA misses follow.
2. Plan/run blur. Gantt bars or Kanban tickets are reported as if the work already happened; audits and costing degrade.
3. Spec/time leakage. People and calendars creep into MethodDescriptions; reuse and staffing agility collapse.
4. No variance model. Without planned baselines, deviations in time, cost, and quality cannot be explained or improved.
5. Structure entanglement. BoM and org charts get baked into “process” views; plans become brittle and unmaintainable.

#Forces (what we must balance)

#Solution — the U.WorkPlan as the time‑bound intention to execute Work

#Definition

U.WorkPlan is an U.Episteme that declares intended U.Work occurrences over a horizon, with planned windows, dependencies, intended performers (as role kinds or proposed RoleAssignings), resource budgets/reservations, and acceptance targets—within a U.BoundedContext.

Strict distinction (memory aid): Method = how in principle. MethodDescription = how it is written. WorkPlan = when, by whom in intent, under which constraints. Work = how it went this time.

#Plan Items (what a WorkPlan is made of)

A U.WorkPlan contains Plan Items (think: scheduled tasks/ops), each of which typically states:

1. Target Method/Spec — the Method to be enacted and the MethodDescription intended for enactment.
2. Planned window — e.g., earliest start/latest finish, timebox, recurrence (cron‑like), blackout periods.
3. Role requirements — role kinds required (not people), optional proposed RoleAssigning(s) if pre‑assignment is allowed in the context.
4. Capability thresholds — minimal abilities required of the performer (checked at run time).
5. Resource budgets/reservations — planned energy/materials/machine slots/money; reservations on assets.
6. Dependencies — precedence/overlap permissions; gates/approvals.
7. Acceptance targets — quality windows/SLA targets to be judged when Work completes.
8. Location/asset constraints — where the run is expected to take place.
9. Links to Service promises (if any) — external commitments that this plan aims to satisfy.

Didactic guardrail: No logs or actuals belong in a WorkPlan; no step logic or solver internals either—that’s the Method/Spec.

#Clear distinctions (lexical sanity for “schedule/process/workflow”)

L‑SCHED (lexical rule). In this document, words like schedule, calendar, rota, Gantt, plan point to U.WorkPlan unless explicitly redefined by a bounded context glossary.

#Plan mereology (composition of plans ≠ composition of methods or runs)

Keep three separations crystal‑clear:

• Method composition (design‑time semantics) → produces new Methods.
• Work composition (run‑time occurrences) → produces parent/child runs with overlaps/episodes.
• Plan mereology (epistemic structure) → organizes Plan Items for coordination (phases, sprints, shifts), with precedence and resource reservations.

Common relations among Plan Items:

• Precedes_pl / DependsOn_pl — start/finish constraints and gates.
• MayOverlap_pl / MutuallyExclusive_pl — allowed overlaps vs exclusive windows.
• Refines_pl — a child plan item tightens windows/budgets of a parent.
• Alternative_pl — planned alternatives (e.g., backup rig, backup team).

Didactic rule: A Plan Item does not force an identical Work shape; mapping is via fulfilment and variance (see §6).

#How WorkPlan meets Work (fulfilment & variance)

When reality happens, each U.Work may:

• Fulfil a Plan Item — link plannedAs → PlanItem.
• Partially fulfil — multiple Work instances share one Plan Item (e.g., split run), or one Work fulfils several Plan Items (e.g., consolidated batch).
• Deviate — execute with method/spec substitution, different window, different performer (still valid or policy‑exception).
• Be unplanned — Work with no Plan Item (emergency, ad‑hoc); must be labeled as such.

Variance dimensions the plan expects to report on:

• Schedule variance (Δt): early/late vs planned window.
• Cost variance (Δc): actual resource spend vs budget.
• Scope variance: different Method/Spec than planned (with justification).
• Quality variance: acceptance verdict vs target.
• Assignment variance: intended vs actual RoleAssigning.

Manager’s view: A plan that cannot report variance is a calendar picture, not a management tool.

#What a good WorkPlan states (review checklist)

Use this as a human‑readable checklist (not a rigid schema):

1. Horizon & cadence (e.g., “W36 surgeries, daily ETL”).
2. Plan Items with: target Method/Spec, planned windows, dependencies.
3. Role requirements (kinds) and intended assignments (optional, context‑lawful).
4. Capability thresholds and safety envelopes.
5. Resource budgets and reservations on assets.
6. Acceptance targets (SLA/quality windows).
7. Bridges if plan spans multiple contexts (operations ↔ audit/regulatory).
8. Baseline/version and change notes (so variance is attributable).
9. Policy pointers (episode policy, overlap policy for Work roll‑ups if needed for KPIs).
10. Exceptions path (how ad‑hoc/emergency work is planned post‑factum).

#Archetypal grounding (parallel domains)

#Hospital OR day plan (shift rota + cases)

• WorkPlan: OR_DayPlan_2025‑08‑12.
• Plan Items: Case#1 Appendectomy, Case#2 Hernia, with windows, Context assignments, and surgeon role kinds; anesthetist intended RoleAssigning provided.
• Budgets: OR time blocks, consumables envelopes.
• Fulfilment: Each surgery Work links to its Plan Item; variances computed (over‑run time, substitutions).

#Fab maintenance weekend (asset reservations)

• WorkPlan: Fab_Maintenance_W36.
• Plan Items: Tool_42 chamber clean, Tool_13 calibration; MutuallyExclusive_pl with production slots.
• Reservations: nitrogen, DI water, metrology window.
• Fulfilment: Actual clean Work happens earlier; variance logged as early with cost underrun.

#Data‑center rollout (multi‑context plan)

• WorkPlan: DC_Rollout_Phase‑2.
• Bridges: Ops context ↔ Security Audit context (different acceptance targets).
• Plan Items: Deploy Service A, Pen‑test A; dependencies across contexts.
• Fulfilment: Deployment Work passes ops targets; audit Work passes later—variance reported per context.

#Bias‑Annotation (as in E‑cluster)

• Lenses tested: Did, Prag, Arch, Epist.
• Scope declaration: Universal; meanings of windows/budgets/permissions are context‑local via U.BoundedContext.
• Rationale: Elevates planning/scheduling to a first‑class episteme that coordinates Methods, RoleAssignings, and Work without conflation.

#A.15.2:End