telemetrylog-work

name	telemetry/log-work
description	Generates a U.Work record for an action (Pattern A.15.1).
license	Apache-2.0
metadata	{"fpf_id":"A.15.1","fpf_title":"U.Work: The Record of Occurrence","family":"telemetry"}
allowed-tools	["write_to_file","run_command"]

A.15.1 - U.Work

Implementation note (local tooling): When POSTHOG_API_KEY and POSTHOG_DISTINCT_ID are set, the reference implementation emits a PostHog event named u_work_logged with spec/context metadata. Set POSTHOG_INCLUDE_ACTION=1 to include the action text and role. Implementation note (local tooling): When agent_session, agent_model, or agent_type inputs are provided, the reference implementation adds an agent_metadata block to the U.Work record.

A.15.1:1 - Problem Frame

After we have agreed who is assigned (via Role assignment), what they can do (via Capability), and how in principle it should be done (via Method/MethodDescription), we still need a precise concept for what actually happened in real time and space.

That concept is U.Work: the dated run‑time occurrence of enacting a MethodDescription by a specific performer under a Role assignment, with concrete parameter bindings, resource consumption, and outcomes, anchored to a domain referent that actually changes (asset/product/dataset) — not merely the manipulation of records about that referent. Managers care about Work because it is the only place where cost, time, defects, and evidence are real. Architects care because Work ties plans and specs to accountable execution.

A.15.1:2 - Problem (what breaks without a clean notion of Work)

1. Plan/run confusion. Schedules and diagrams get mistaken for “the process,” so audits and KPIs become fiction.
2. Spec/run conflation. A method description (code/SOP) is reported as if it were an execution; conversely, logs are treated as recipes.
3. Who/when leakage. People and calendars are baked into specs; reuse and staffing agility collapse.
4. Resource dishonesty. Energy/money/tool wear are booked to methods or roles, not to actual runs; costing and sustainability metrics drift.
5. Mereology muddle. Teams hand‑wave over “sub‑runs,” retries, overlaps, or long‑running episodes; roll‑ups double‑count or miss work.

A.15.1:3 - Forces (what the definition must balance)

Force	Tension we resolve
Universality vs. domain detail	One Work notion for surgery, welding, ETL, proofs, lab cycles—while letting each keep its vocabulary.
Granularity vs. aggregation	Atomic runs vs. composite operations; we need roll‑up without double‑count.
Concurrency vs. order	Parallel/overlapped activities need clear part/overlap semantics.
Identity vs. retries	A failed attempt, a retry, and a resumed episode—what is “the same” work?
Time realism vs. simplicity	We need intervals and coverage but cannot bury users in temporal logic notation.

A.15.1:4 - Solution — define U.Work as the accountable, dated occurrence

A.15.1:4.1 - Definition

U.Work is a 4D occurrence holon: a dated run‑time enactment of a U.MethodDescription by a performer designated through a U.RoleAssignment, executed within a concrete U.System/SubSystem, inside a U.BoundedContext, that binds concrete parameters, consumes/produces resources, and leaves an auditable trace. Each U.Work is a morphism Δ on a declared state‑plane (StatePlaneRef), mapping ⟨pre‑state, inputs⟩ to ⟨post‑state, outputs⟩ for one or more affected referents.

Memory aid: Work = “how it went this time” (dated, resourced, accountable).

A.15.1:4.2 - Core anchors (conceptual descriptors; not a data schema)

When you describe a Work instance in a review, answer these prompts:

1. Window — start/end timestamps (and, where relevant, location/asset).
2. Spec — isExecutionOf → U.MethodDescription (the description actually followed; edition pinned if applicable).
3. Performer — performedBy → U.RoleAssignment (which holder#role:context acted).
4. Parameters — concrete values bound for this run (from the MethodDescription parameter declarations).
5. Inputs/Outputs — material/information artifacts read/written, products/services delivered.
6. Resources — energy, materials, machine time, money (the only place we book them).
7. Outcome — success/failure classes, quality measures, acceptance verdicts (map‑then‑compare per ComparatorSet under CG‑Spec; pin editions).
8. Links — predecessor/successor/overlap relations to other Work, and step/run nesting (if part of a bigger operation).
9. Context — the bounded context(s) under which this run is judged (normally inherited from the MethodDescription and RoleAssigning; see A.15 for cross‑checks).
10. Effect (Δ) — affected → {referent(s)} + pre‑state anchor and post‑state anchor (or a declared Δ‑predicate evaluated on evidence) on the declared state‑plane (StatePlaneRef).
11. System — executedWithin → U.System (the operational system/sub‑system accountable for the occurrence; mandatory).
12. Evidence & Telemetry (optional) — if the run feeds G.11 refresh or QD/OEE archives, cite PathId/PathSliceId and the active policy‑id used for illumination; do not elevate telemetry into dominance without CAL policy.

A.15.1:4.3 - Clear distinctions (the four‑slot grammar in action)

You are pointing at…	The right FPF concept	Litmus
The recipe/code/diagram	MethodDescription	Is it knowledge on a carrier?
The semantic “way of doing”	Method	Same Standard across notations?
The assignment (“who is being what”)	Role → RoleAssigning	Can be reassigned without changing the system?
The ability (“can do within bounds”)	Capability	Would remain even if not assigned?
The dated occurrence with logs, resources	Work	Did it happen at (t₀, t₁), consume resources, produce outcomes?
The state change caused this time	Work.Δ	Did the referent move from pre→post on the declared state‑plane?

A.15.1:4.4 - Publication (MVPK guard‑rails for U.Work) — normative

Publication of U.Work across MVPK faces must be a typed projection that does not mutate intensional semantics (A.7; E.17). Concretely:

1. No new claims. Faces (PlainView / TechCard / InteropCard / AssuranceLane) SHALL NOT introduce properties beyond the U.Work intensional arrow; they project presence‑pins only (time window, performer, spec, parameter‑binding occurrence, resource ledger presence, acceptance verdict presence). Numeric/comparable content appears only with pins (see 4.4‑4.5 below); “signature” is banned on faces.
2. No Γ‑leakage. Faces MUST NOT smuggle Γ semantics (union/hull/overlap policy, budget algebra) into prose; whenever aggregation is shown, the face cites the Γ‑operator and policy‑id used. Compute totals outside the face per B.1; faces carry references, not implied Γ rules.
3. No I/O re‑listing. Per MVPK, faces do not duplicate intensional I/O lists. They show presence‑pins and anchors to carriers/lanes/editions only (E.17 §5.4).
4. Lawful orders (sets). Where a U.Work face presents any comparison or ranking across runs (e.g., acceptance classes, parity/benchmark inserts), the face must: (i) compare after mapping via a declared ComparatorSet; (ii) return sets (Pareto/Archive) when order is partial; (iii) forbid hidden scalarization/ordinal means (cf. G.9).
5. Comparator/Transport edition pins. Any numeric/comparable statement on a U.Work face MUST pin the CG‑Spec/ComparatorSet edition(s) and, where scale/plane conversion occurs, the UNM.TransportRegistry edition (Φ/Φ^plane policy‑ids). Cross‑context/plane crossings route penalties to R‑lane only (Bridge id + Φ) (cf. E.17; G.9).
6. Cross‑stance citations. Any citation whose stance differs from the citing U.Work face (different DesignRunTag, ReferencePlane, or CtxState.locus) MUST carry BridgeCard + UTS row (with locus/plane notes and CL routing).
7. No surrogate‑run creation. Faces MUST NOT synthesize “virtual runs” from reconstructed records alone; a face may reference only U.Work instances that meet Δ‑anchoring in §4.2/§8.

A.15.1:4.5 - Crossing visibility & stance tags (work publication discipline) — normative

• Stance. U.Work is a run-time occurrence (DesignRunTag = run). Any face that cites design-time artefacts (e.g., ComparatorSet, CG-Spec editions, TransportRegistryΦ) is making a cross-stance/cross-Context reference and therefore MUST publish a BridgeCard + UTS row and record Φ(CL)/Φ^plane policy-ids; penalties reduce R_eff only.
• Binding discipline. Launch values bind only here (occurrence). Plan-time proposals remain proposals; do not back-fill plan faces with run-time bindings. Pre/post state anchors bind here (pre at start; post at completion or at declared checkpoints).

A.15.1:5 - Work mereology (how runs form holarchies)

We adopt a 4D extensional stance for occurrences: a Work is identified primarily by its spatiotemporal extent and its execution anchors (spec used, performer, parameterization). This avoids double‑counting and keeps aggregation sound. FPF adapts insights from BORO/constructive ontologies to Work while staying practical.

A.15.1:5.1 - Parts and wholes of Work (design‑neutral, run‑time facts)

• Temporal‑part (TemporalPartOf_work). A proper time‑slice of a Work (e.g., the first 10 minutes of a 2‑hour run). Useful for monitoring and SLAs.
• Episode‑part (EpisodeOf_work). A resumption fragment after an interruption (same run identity if policy deems it one episode; see 5.5).
• Operational‑part (OperationalPartOf_work). A sub‑run that enacts a factor of the Method/Spec (e.g., “incision” run within “appendectomy” run), possibly overlapping with others in time.
• Parallel‑part (ConcurrentPartOf_work). Two sub‑runs that overlap in their windows, coordinated by the same higher‑level run.

Didactic rule: Method composition ≠ proof of Work decomposition. Sub‑runs often map to method factors, but retries, batching, pipelining, and failures make the mapping non‑isomorphic.

A.15.1:5.2 - Key relations among Work

• precedes/happensBefore — strict partial order on Work windows.
• overlaps — intervals intersect but neither contains the other.
• contains/within — one Work’s window contains another’s.
• causedBy/causes — pragmatic causal links (e.g., a rework caused by a failed inspection run).
• retryOf — a new Work instance re‑attempting the same MethodDescription with revised parameters.
• resumptionOf — a Work episode that continues an interrupted run (policy decides identity; see 5.5).

These relations are run‑time facts, not design assumptions.

A.15.1:5.3 - Operators for roll‑ups (Γ_time and Γ_work)

• Temporal coverage — Γ_time(S) For a set S of Work parts, returns a coverage interval set (union of intervals) or, when required, the convex hull [min t₀, max t₁]. Use union for utilization; use hull for lead time. Properties: idempotent, commutative, monotone under set inclusion.

• Resource aggregation — Γ_work(S) For a set S of Work parts, returns the aggregated resource ledger (materials, energy, time, money) with de‑duplication rules for shared/overlapped parts (context‑declared). Properties: additive on disjoint parts; requires overlap policy otherwise (e.g., attribute costs to the parent once, not to each child).

Manager’s tip: Pick the coverage operator that matches your KPI: union for machine utilization; hull for calendar elapsed; never mix silently.

A.15.1:5.4 - Identity of a Work (extensional criterion, pragmatically framed)

Two Work records refer to the same Work iff, in the relevant context:

• their time–space extent is the same (within declared tolerance),
• they link to the same MethodDescription,
• they have the same performer (U.RoleAssignment), and
• they bind the same parameters (or declared‑equivalent values).

If any of these differ (or the context declares equivalence absent), they are distinct Work instances (e.g., a retry).

A.15.1:5.5 - Interruptions, retries, resumptions (episode policy)

• Retry: new Work with its own window and parameters; link via retryOf.
• Resumption: same Work identity split into episodes if the context’s episode policy declares so (e.g., “power loss under 5 minutes keeps identity”).
• Rework: new Work caused by a failure in earlier Work; link via causedBy.

Why it matters: plans, costs, and quality stats depend on whether you treat a disruption as one episode or a new run. Declare the policy in the bounded context.

A.15.1:5.6 - Compositionality of effects (Δ)

For any Work with parts, the effect of the whole must be the rules‑declared composition of the effects of its parts plus any declared overheads/residuals. Composition must align with the overlap rules used by Γ_work (e.g., no double‑count of shared fixed costs, and consistent attribution of variable deltas).

A.15.1:6 - Archetypal grounding (parallel domains)

A.15.1:6.1 - Surgical case (overlap and episodes)

• Top run: Appendectomy_Case#2025‑08‑10T09:05–11:42.
• Spec: Appendectomy_v5 (MethodDescription).
• Performer: OR_Team_A#SurgicalTeamRole:Hospital_2025 (RoleAssigning).
• Operational parts: Incision (09:15–09:22), Exploration (overlaps with monitoring), Closure (11:10–11:35).
• Episode: brief power dip 10:02–10:07 → resumptionOf same run (per hospital policy).
• Γ_time: union for OR utilization; hull for patient lead time.
• Γ_work: totals consumables and staff time once (no double‑count for overlapping sub‑runs).

A.15.1:6.2 - ETL pipeline (parallelism and retries)

• Top run: ETL_Nightly_2025‑08‑11T01:00–01:47.
• Spec: ETL_v12.bpmn.
• Performer: ETL_Runtime#TransformerRole:DataOps_2025.
• Parallel parts: Extract_A ‖ Extract_B; Transform starts when either completes (overlap).
• Retry: Load failed at 01:36; retried with batch size ↓ — new Work linked via retryOf.
• Γ_time: hull for SLA, union for cluster utilization.
• Γ_work: sum compute minutes; attribute storage I/O once at the parent.

A.15.1:6.3 - Thermodynamic cycle (work as a path)

• Run: Carnot_Cycle_Run#2025‑08‑09T13:00–13:06.
• Spec: Carnot_Cycle_Spec (MethodDescription with Dynamics model).
• Performer: LabRig_7#TransformerRole:ThermoLab.
• Work identity: the path in state‑space traced during the interval; outputs: heat/work tallies.
• Γ_time: straightforward interval; Γ_work: integrates energy exchange; no “steps” required.

A.15.1:7 - Bias‑Annotation (as in E‑cluster)

• Lenses tested: Prag, Arch, Did, Epist.
• Scope declaration: Universal; temporal semantics and episode policy are context‑local via U.BoundedContext.
• Rationale: Gives FPF a clean, actionable notion of occurrence compatible with U.RoleAssignment / Role Enactment (A.2.1; A.15) and with 4D extensional thinking, so that costing, quality, and audit rest on runs, not on plans or recipes.

A.15.1:8 - Conformance Checklist (normative)

CC‑A15.1‑1 (Strict distinction). U.Work is a dated run‑time occurrence. It is not a U.Method (semantic way), not a U.MethodDescription (description), not a U.Role/RoleAssigning (assignment), and not a U.WorkPlan (plan/schedule).

CC‑A15.1‑2 (Required links). Every U.Work MUST reference: (a) isExecutionOf → U.MethodDescription (the spec followed; edition pinned), (b) performedBy → U.RoleAssignment (the assigned performer in context), and (c) executedWithin → U.System/SubSystem (the operational system accountable for the occurrence).

CC‑A15.1‑3 (Time window). Every U.Work MUST carry a closed interval [t_start, t_end] (or an explicitly marked open end for in‑flight work) and, where relevant, location/asset.

CC‑A15.1‑4 (Context anchoring & judgement). A U.Work MUST be judged inside a declared U.BoundedContext (the judgement context).

• By default, the judgement context is the context of the referenced MethodDescription.
• If performedBy references a RoleAssigning in a different context, there MUST exist an explicit Bridge (U.Alignment) or policy stating cross‑context acceptance. Otherwise, the Work is non‑conformant in that context.

CC‑A15.1‑4b (State‑plane anchoring). Each U.Work MUST declare a StatePlaneRef for its Δ‑judgement.

CC‑A15.1‑5 (RoleAssigning validity). The performedBy RoleAssigning’s timespan MUST cover the Work interval. If it does not, the Work is invalid or must be re‑judged in a context that allows retroactive assignments.

CC‑A15.1‑6 (Parameter binding). Parameters declared by the MethodDescription MUST have concrete values bound at Work creation/start and recorded with the Work. Defaults in the spec do not satisfy this requirement.

CC‑A15.1‑7 (Capability check). All capability thresholds stated by the Method/MethodDescription MUST be checked against the holder in performedBy at the time of execution (or at defined checkpoints). Violations must be flagged on the Work outcome.

CC‑A15.1‑8 (Acceptance criteria). Success/failure and quality grades MUST be determined by the acceptance criteria declared (or referenced) by the MethodDescription/CG‑Spec in the judgment context. The verdict is recorded on the Work.

CC‑A15.1‑9 (Resource honesty). All consumptions and costs (energy, materials, machine‑time, money, tool wear) SHALL be booked only to U.Work (not to Method, MethodDescription, Role, or Capability). Estimates may live in specs; actuals live in Work.

CC‑A15.1‑10 (Mereology declared). If a Work has parts, the chosen part relation(s) must be declared (temporal‑part, episode‑part, operational‑part, concurrent‑part). Ambiguous mixtures are forbidden.

CC‑A15.1‑11 (Γ_time selection). For any roll‑up, the judgement context MUST declare which temporal coverage operator applies: union (utilization) or convex hull (lead time). Silent mixing is prohibited.

CC‑A15.1‑12 (Γ_work aggregation). Aggregation of resource ledgers across Work parts MUST specify an overlap policy (e.g., “attribute shared machine‑time to parent only”) to prevent double‑counting.

CC‑A15.1‑13 (Identity & retries). A retry MUST be modeled as a new Work linked via retryOf. Interruptions that are treated as the same run must be modeled as episodes (resumptionOf) per a context‑declared episode policy.

CC‑A15.1‑14 (Concurrency & ordering). Overlaps and precedences among Work MUST use interval relations (overlaps, precedes, contains/within). Implicit “step order” claims are not admissible evidence.

CC‑A15.1‑15 (Cross‑context evidence). If a Work is to be accepted in multiple contexts (e.g., regulatory + operational), either: (a) re‑judge it in each context, or (b) provide Bridges that map acceptance criteria/units/roles; never assume cross‑context identity by name.

CC‑A15.1‑16 (Spec changes during run). If the MethodDescription version changes mid‑run, the Work MUST either: (a) split into episodes bound to respective specs, or (b) record an explicit spec override event in the judgement context. Silent substitution is forbidden.

CC‑A15.1‑17 (Distributed performers). If multiple RoleAssignings jointly perform the same top‑level Work (e.g., multi‑agent orchestration), the Work MUST either: (a) designate a lead RoleAssigning and list others as concurrent parts, or (b) be modeled as a parent Work with child Works per RoleAssigning.

CC‑A15.1‑18 (Logs ≠ Work by themselves). Logs/telemetry are evidence for a Work; they do not constitute a Work unless bound to (spec, performer, time window) and judged in a context.

CC‑A15.1‑19 (Affected referent). Each U.Work MUST name at least one affected referent (e.g., U.Asset, product/batch, dataset/document) via affected → {…}.

CC‑A15.1‑20 (State‑change witness). Each U.Work MUST carry either (a) explicit pre‑state/post‑state anchors on the declared state‑plane or (b) a Δ‑predicate that can be evaluated on evidence. Trivial “no‑op” runs MUST be flagged as such.

CC‑A15.1‑21 (World anchoring vs. record‑handling). A run whose only effect is copying/reformatting records does not qualify as U.Work unless the judgment context declares those records to be the product referent (e.g., data‑product manufacture).

CC‑A15.1‑22 (System anchoring). Each U.Work MUST declare executedWithin → U.System/SubSystem; if different from the asset of change, keep affected explicit.

CC‑A15.1‑23 (Compositionality of Δ). For composite Work, the parent effect MUST be the declared composition of child effects under the same overlap policy as Γ_work.

CC‑A15.1‑24 (No new claims on faces). MVPK faces for U.Work SHALL NOT add properties/claims beyond the intensional arrow; numeric/comparable content MUST include unit/scale/reference‑plane/EditionId pins; the term “signature” is banned on faces.

CC‑A15.1‑25 (No Γ‑leakage). Faces MUST reference Γ operators/policies by id when showing aggregates; they MUST NOT encode aggregation semantics in prose or imply defaults. Γ lives in Part B; faces carry pinned references only.

CC‑A15.1‑26 (No I/O re‑listing). Faces MUST NOT restate intensional I/O; publish presence‑pins and anchors only (per MVPK §5.4).

CC‑A15.1‑27 (Lawful orders; return sets). Any across‑run comparison presented on a U.Work face MUST use a declared ComparatorSet (map‑then‑compare), return sets when order is partial, and forbid hidden scalarization/ordinal means.

CC‑A15.1‑28 (Comparator/Transport pins). Any numeric/comparable acceptance or KPI on a U.Work face MUST pin ComparatorSet.edition, CG‑Spec.edition, and (where conversions occur) TransportRegistry.edition with Φ/Φ^plane policy‑ids; Bridge ids are mandatory for cross‑context/plane reuse; penalties → R only.

CC‑A15.1‑29 (Telemetry hooks, when applicable). If a Work instance feeds G.11 or QD/OEE portfolios, it SHALL cite PathId/PathSliceId and the active policy‑id in its evidence; illumination remains report‑only telemetry unless CAL explicitly promotes it.

A.15.1:9 - Temporal & Aggregation Semantics (normative operators & invariants)

A.15.1:9.1 - Temporal coverage Γ_time

• Input: a finite set S of Work instances or Work parts.

• Output: either (a) the union of their intervals, or (b) the convex hull [min t_start, max t_end]—as declared by context and KPI.

• Invariants:

  • Idempotent: Γ_time(S ∪ S) = Γ_time(S)
  • Commutative: order of elements irrelevant
  • Monotone: if S ⊆ T then coverage(S) ⊆ coverage(T) (for union) or hull(S) ⊆ hull(T) (for hull)

• Usage guidance:

  • Use union for utilization/availability (how much of the clock time the asset was actually busy).
  • Use hull for lead/cycle time (elapsed from first touch to last release).
  • Manager’s tip: Write the choice near the KPI; many disputes are just a hidden union‑vs‑hull mismatch.

A.15.1:9.2 - Resource aggregation Γ_work

• Input: a finite set S of Work instances or parts with resource ledgers.

• Output: an aggregated ledger (materials, energy, machine‑time, money, tool wear) with explicit overlap policy.

• Invariants:

  • Additivity on disjoint parts: if intervals/resources are disjoint by policy, totals add.
  • No double‑count: overlapping costs must follow the declared policy (e.g., count once at parent).
  • Traceability: each aggregated figure must be reconcilable to contributing Work IDs.

• Typical policies:

  • Parent‑attribution: shared fixed costs at parent; variable costs at children.
  • Pro‑rata by wall‑time: split overlaps by relative durations.
  • Driver‑based: allocate by a declared driver (e.g., CPU share, weight, priority).

A.15.1:10 - Cross‑context checks (MethodDescription ↔ RoleAssigning ↔ Work)

When a Work is recorded, perform these three quick checks:

1. Spec–Context Check. Does isExecutionOf refer to a MethodDescription defined in the judgement context (or bridged to it)?

   • If no, the Work is out‑of‑context; either change context or add a Bridge.

2. RoleAssigning–Context Check. Is performedBy’s RoleAssigning valid in the same context (or bridged)?

   • If no, the Work is unassigned for that context; remedy via a valid RoleAssigning or a policy exception.

3. Standard–Outcome Check. Do the Work’s inputs/outputs and metrics satisfy the acceptance criteria from the spec as interpreted in that context?

   • If no, the Work fails or is “conditionally accepted” per context policy.

Manager’s mnemonic: Context, assignment, Standard → CAC. Fail any → the Work is not acceptable here (perhaps acceptable elsewhere).

A.15.1:11 - Anti‑patterns (and the right move)

• “The log is the process.” Dumping telemetry without binding (spec, performer, context) → Not Work. Create a Work, link the log as evidence.
• Record‑only transforms. ETL/replication of records with no declared affected referent (product/dataset as product) → Not Work in this context; either declare the dataset as the product referent or move it to U.WorkPlan/operations‑support.
• Silent cross‑context acceptance. “Ops accepted it, so audit accepts it.” → Add a Bridge or re‑judge in audit context.
• Spec drift in mid‑run. Swapping SOP v5→v6 without recording → Split into episodes or record override.
• Budget on the method. Charging costs to Method or Role → Book only to Work; keep estimates in specs.
• Part ambiguity. Mixing retries, episodes, and operational parts with no declared relation → Choose and declare the part relation.
• Union/hull confusion. Changing KPI coverage silently between reports → Declare Γ_time policy per KPI.
• Double‑count in overlaps. Summing child and parent resource ledgers → Declare and apply an overlap policy.

A.15.1:12 - Migration notes (quick wins)

1. Backfill links. For existing logs, create Work records and attach isExecutionOf and performedBy.
2. Name the context. Pick the judgement context explicitly; add Bridges if multiple contexts must accept.
3. Publish the episode policy. Decide when an interruption keeps identity vs forces a new run.
4. Choose Γ_time per KPI. Put “union” or “hull” in the KPI definition; stop arguing in meetings.
5. Set an overlap policy. Write one sentence on how shared costs are allocated; apply consistently.
6. Pull plans out. Move calendars to U.WorkPlan; let Work record actuals.
7. Parameter blocks. Make parameters explicit and bind them at start; your root‑cause analyses will get 10× easier.

A.15.1:13 - Consequences

Benefits	Trade‑offs / mitigations
Auditable reality. Costs, time, and quality attach to concrete runs; root‑cause analysis and accountability improve.	More records. You create Work instances; mitigate with templates and automation.
Sound roll‑ups. Γ_time/Γ_work turn roll‑ups from hand‑waving into declared policy; KPIs become comparable.	Policy discipline. You must choose union vs hull and an overlap policy; write it once.
Cross‑context clarity. CAC checks prevent silent model drift; bridges make acceptance explicit.	Bridge upkeep. Keep mappings short and focused; review at releases.
4D extensional coherence. Parts/overlaps/retries stop double‑counting and identity confusion.	Learning curve. Teach episode vs retry; include examples in onboarding.

A.15.1:14 - Relations

• Builds on: A.1 Holonic Foundation; A.1.1 U.BoundedContext; U.System; A.2 U.Role; A.2.1 U.RoleAssignment; A.2.2 U.Capability; A.3.1 U.Method; A.3.2 U.MethodDescription.
• Coordinates with: A.15 Role–Method–Work Alignment (the “four‑slot grammar”); B.1 Γ (aggregation) for resource/time operators; E‑cluster lexical rules (L‑PROC/L‑FUNC).
• Informs: Reporting/KPI patterns; Assurance/evidence patterns (Work as the anchor for audits); Scheduling patterns (U.WorkPlan ↔ U.Work deltas).

A.15.1:15 - Didactic quick cards

• What is Work? How it went this time → dated, resourced, accountable.
• Four‑slot grammar: Who? RoleAssigning. Can? Capability. How? Method/MethodDescription. Did? Work.
• CAC checks: Context (judgement), assignment (valid RoleAssigning), Standard (acceptance criteria).
• Roll‑ups: Γ_time = union (utilization) or hull (lead time); Γ_work with a declared overlap policy.
• Episodes vs retries: same run split vs new run; write the policy.
• Resource honesty: actuals booked only to Work; estimates live in specs.

A.15.1:End