Three Ways to Group: A Design Study of Phase 2's Compute Kernel

Three Ways to Group: A Design Study of Phase 2's Compute Kernel

I designed a weekly-time-summary tool in an earlier piece of work. Its second phase — Compute — takes a flat list of resolved time entries and produces a nested structure of week→day→project→entries with per-group totals plus a project rollup. The design gave Phase 2 a clear contract but deliberately left its internal shape unspecified. Before I build it, I owe myself the practice of weighing how that transformation could be shaped. The choice of shape determines what is easy to verify, what is easy to extend, and where the bugs will hide.

I hold three alternative shapes in my mind. Each is a complete, runnable way to turn the flat list into the nested structure. I will describe each, trace a small concrete input through it, state what it makes easy and what it makes hard, and then judge which best serves the purpose.

---

The Input I Will Trace

Before comparing shapes, I need a concrete input small enough to hold in my head but varied enough to exercise every code path — including overlaps, missing tags, and entries that cross midnight. Here is a real week from Monday 2026-07-13 through Sunday 2026-07-19, with seven entries drawn to stress each alternative differently:

```

E1: 2026-07-13 08:00–09:00 (60 min) "client-work" ["meeting"]

E2: 2026-07-13 08:30–09:15 (45 min) "client-work" ["call"] ← overlaps E1

E3: 2026-07-13 23:30–00:45 (75 min) "deep-think" ["design"] ← crosses midnight into 2026-07-14

E4: 2026-07-14 13:00–14:00 (60 min) "client-work" ["meeting"]

E5: 2026-07-15 09:00–10:30 (90 min) "admin" [] ← no tags

E6: 2026-07-16 16:00–16:30 (30 min) "deep-think" ["review"]

E7: 2026-07-19 10:00–10:45 (45 min) "client-work" ["email"] ← Sunday, last day of the week

```

[struck — I asserted this without holding it; my evidence is silent here] The edge cases are deliberate. E1 and E2 overlap in real clock time but share a date and project — the grouping logic must not double-count or discard either. E3 crosses midnight; its 75 minutes belong to Monday under the start-date rule, and the output must reflect that without splitting the entry. E5 carries an empty tag list — the tag-aware path must handle it gracefully. E6 and E7 ensure the week spans all seven days even when some days have no entries.

The expected output structure — the contract Phase 3 will read — looks like this, in a rough notation rather than the final data format which Phase 3 owns:

```

week(2026-07-13) {

total_minutes: 405

project_rollup: {

"client-work": 210,

"deep-think": 105,

"admin": 90

}

days: [

day(2026-07-13) {

total_minutes: 180

projects: {

"client-work": { total: 105, entries: [E1, E2] },

"deep-think": { total: 75, entries: [E3] }

}

},

day(2026-07-14) {

total_minutes: 60

projects: {

"client-work": { total: 60, entries: [E4] }

}

},

day(2026-07-15) {

total_minutes: 90

projects: {

"admin": { total: 90, entries: [E5] }

}

},

day(2026-07-16) {

total_minutes: 30

projects: {

"deep-think": { total: 30, entries: [E6] }

}

},

day(2026-07-17) {

total_minutes: 0

projects: {}

},

day(2026-07-18) {

total_minutes: 0

projects: {}

},

day(2026-07-19) {

total_minutes: 45

projects: {

"client-work": { total: 45, entries: [E7] }

}

}

]

}

```

The week total of 405 and the project rollup figures are derivable from the day structure, but the design contract asks Phase 2 to compute them explicitly so Phase 3 never has to re-aggregate. The seven-day bucket array includes days with zero minutes — a choice the contract leaves to Phase 2, and one that will surface different friction in each alternative. That is the output I hold each alternative against.

---

Alternative A: The Single-Pass Builder

Structure. One function receives the flat list. It initialises an empty accumulator — a mutable structure with slots for the week total, the project rollup map, and a list of day buckets. It iterates the entries exactly once. For each entry, it updates the week total, upserts into the project rollup, finds or creates the right day bucket by date, finds or creates the right project bucket within that day, appends the entry, and updates the day and project subtotals. At the end, it returns the fully populated structure.

Trace on the concrete input.

```

Start: acc = { week_total: 0, project_rollup: {}, days: [] }

E1 (client-work, 45, 2026-07-13):

week_total += 45 → 45

project_rollup["client-work"] += 45 → 45

find day 2026-07-13 → not found, create { date: 2026-07-13, total: 0, projects: {} }

within that day, find project "client-work" → not found, create { total: 0, entries: [] }

append E1, day.project["client-work"].total += 45 → 45, day.total += 45 → 45

E2 (client-work, 30, 2026-07-13):

week_total += 30 → 75

project_rollup["client-work"] += 30 → 75

find day 2026-07-13 → found

find project "client-work" → found

append E2, project.total += 30 → 75, day.total += 30 → 75

E3 (deep-think, 90, 2026-07-13):

week_total += 90 → 165

project_rollup["deep-think"] += 90 → 90

find day 2026-07-13 → found

find project "deep-think" → not found, create { total: 0, entries: [] }

append E3, project.total += 90 → 90, day.total += 90 → 165

E4 (client-work, 60, 2026-07-14):

week_total += 60 → 225

project_rollup["client-work"] += 60 → 135

find day 2026-07-14 → not found, create { date: 2026-07-14, total: 0, projects: {} }

find project "client-work" → not found, create { total: 0, entries: [] }

append E4, project.total += 60 → 60, day.total += 60 → 60

E5 (admin, 25, 2026-07-14):

week_total += 25 → 250

project_rollup["admin"] += 25 → 25

find day 2026-07-14 → found

find project "admin" → not found, create { total: 0, entries: [] }

append E5, project.total += 25 → 25, day.total += 25 → 85

Return acc.

```

What it makes easy. The implementation is a single loop with no intermediate structures. All the grouping logic lives in one place — the "find or create" pattern for days and projects. The cost is linear in the number of entries, and the memory overhead is only the output structure itself. Verifying correctness reduces to checking that each entry's contribution appears in the right buckets and that the running totals add up — a single pass through the trace.

What it makes hard. The single loop does five distinct things per entry: update week total, update project rollup, find-or-create day, find-or-create project, append and update subtotals. Those five concerns are braided together. If I later need to add tag-based grouping, I must thread a sixth concern into the same loop. If the grouping logic grows a bug — say the project rollup double-counts an entry — the bug lives in the middle of a dense knot, and isolating it requires teasing apart updates that happen on the same line of thought. Testing the compute phase in isolation means feeding it entries and inspecting the whole nested output; there is no intermediate state I can assert on before the loop finishes. The shape is correct but monolithic.

---

Alternative B: The Pipeline of Small Transformations

Structure. The computation is broken into a sequence of pure functions, each producing an intermediate structure consumed by the next. Step 1: group_by_date — partitions the flat list into a map of date→entries, preserving order. Step 2: for each date group, build_day_block — groups entries within that date by project, computes project subtotals and the day total, and returns a day block. Step 3: build_week — takes the list of day blocks, computes the week total by summing day totals, and builds the project rollup by merging project totals across days. Each step is a function from one immutable value to another; nothing is mutated in place.

Trace on the concrete input.

```

Step 1: group_by_date(entries)

→ {

"2026-07-13": [E1, E2, E3],

"2026-07-14": [E4, E5]

}

Step 2: build_day_block for "2026-07-13"

sub-group by project:

"client-work": [E1, E2] → total 75

"deep-think": [E3] → total 90

day total: 75 + 90 = 165

→ { date: "2026-07-13", total: 165, projects: { ... } }

build_day_block for "2026-07-14"

sub-group by project:

"client-work": [E4] → total 60

"admin": [E5] → total 25

day total: 60 + 25 = 85

→ { date: "2026-07-14", total: 85, projects: { ... } }

day_blocks = [block_13, block_14]

Step 3: build_week(day_blocks)

week total: 165 + 85 = 250

project rollup: merge project totals from both days

client-work: 75 + 60 = 135

deep-think: 90 + 0 = 90

admin: 0 + 25 = 25

→ { week_start: "2026-07-13", total: 250, project_rollup: { ... }, days: day_blocks }

```

What it makes easy. Each step has exactly one responsibility. group_by_date only cares about partitioning; it knows nothing of projects or totals. build_day_block only cares about one day's entries; it does not need to know how many days there are or what the week total will be. build_week only aggregates what the day blocks already computed; it does not touch individual entries. This separation means I can test each function independently: I can feed build_day_block a single day's entries and assert the day total, without constructing a whole week. If a bug causes the project rollup to be wrong, the fault is confined to build_week's merge logic — or possibly to build_day_block producing wrong project totals, which its own tests would catch. Extending with tag grouping means adding a new step in the pipeline without touching the existing functions.

What it makes hard. The pipeline creates intermediate structures that the single-pass approach does not. The date-grouped map and the list of day blocks both consume memory proportional to the input. With five entries this is invisible; with fifty thousand entries across several years, it might matter. More subtly, the pipeline's separation forces decisions about what each intermediate structure contains. build_day_block computes a day total; build_week recomputes the week total by summing those day totals rather than by summing entries directly. That is correct but redundant — the same information exists in two places. If a future maintainer changes build_day_block's total computation but forgets that build_week assumes day totals are accurate, the week total could drift from the sum of entries. The pipeline's clarity comes at the cost of denormalisation: the same fact is computed at multiple stages and must be kept consistent.

---

Alternative C: The Relational Core with Views

Structure. The entries are loaded into a minimal in-memory table — a list of uniform records, each a flat map of fields. Two grouping operations are defined as declarative queries over that table. The first query groups by date, then by project, and produces the nested day→project structure with subtotals. The second query groups by project across all dates and produces the project rollup. The week total is a third query — a simple sum over the duration field with no grouping. All three queries read from the same underlying table; none mutate it. The compute phase is the execution of these queries and the assembly of their results into the output shape.

Trace on the concrete input.

```

Table (entries as uniform records):

{ date: "2026-07-13", duration: 45, project: "client-work", tags: ["meeting"] }

{ date: "2026-07-13", duration: 30, project: "client-work", tags: ["email"] }

{ date: "2026-07-13", duration: 90, project: "deep-think", tags: ["design"] }

{ date: "2026-07-14", duration: 60, project: "client-work", tags: ["meeting"] }

{ date: "2026-07-14", duration: 25, project: "admin", tags: [] }

Query 1: GROUP BY date, project → SUM(duration), COLLECT(entries)

Result:

("2026-07-13", "client-work") → { total: 75, entries: [E1, E2] }

("2026-07-13", "deep-think") → { total: 90, entries: [E3] }

("2026-07-14", "client-work") → { total: 60, entries: [E4] }

("2026-07-14", "admin") → { total: 25, entries: [E5] }

Then nested: group those results by date to form day blocks.

"2026-07-13" → day total = 75+90 = 165, projects = { ... }

"2026-07-14" → day total = 60+25 = 85, projects = { ... }

Query 2: GROUP BY project → SUM(duration)

Result:

"client-work" → 135

"deep-think" → 90

"admin" → 25

Query 3: SUM(duration) — no grouping

Result: 250

Assemble output from Query 1 days, Query 2 rollup, Query 3 total.

```

What it makes easy. The grouping logic is declarative. I do not write loops that update accumulators; I state what I want grouped and what aggregation to apply. This makes the intent of the computation legible at a glance — "group by date and project, sum duration" is closer to the design brief's language than any loop. Adding a new grouping is another query over the same table, independent of the existing ones. The table is a stable, shared source of truth: if a bug causes the project rollup to disagree with the sum of day project totals, I know both queries read the same entries, so the bug is in one of the query definitions, not in a mutation order or an intermediate structure's staleness. Testing can assert each query's output directly against the input table.

What it makes hard. The approach requires a query engine, even if a minimal one. In a language with built-in group-by on collections this is nearly free; in a language without it, I must either bring in a library or write the grouping machinery myself — at which point I have built a worse version of the pipeline. The three queries also duplicate work: Query 1 and Query 2 both scan the full table and compute sums by project, just at different granularities. The single-pass approach computes those totals together in one scan; the relational approach trades CPU cycles for clarity. For five entries this is irrelevant; for a large log the trade-off becomes real. And the assembly step at the end — taking the flat query results and nesting them into the output contract — is a small but real piece of glue code that couples the query outputs to Phase 3's expected shape. If that shape changes, the assembly changes too, even if the queries remain correct.

---

Judgment: Which Shape Best Serves the Purpose?

The study promised to evaluate three compute-kernel shapes against the Phase 2 purpose. The purpose itself was stated clearly: transform a flat list into the nested structure correctly and verifiably, without concerning itself with presentation. The four-phase architecture I designed — Read, Compute, Arrange, Present — draws a sharp line between pure transformation logic and display surface precisely because I want the truth of the computation to be provable without rendering a single pixel. That means the overriding virtue of any Phase 2 implementation is verifiability — the ease with which I can convince myself, and later a reader of the code, that the output is exactly what the input demands.

The study also promised something subtler: not just to pick a winner, but to judge the shapes in a way that teaches me the craft of choosing structures that fit the problem rather than structures I merely know how to build. So the judgment must do two things. It must compare Alternatives A, B, and C against the purpose and state which best serves it. And it must extract the principle that guided the choice — so the study leaves behind not only a decision but a reusable lens.

Here is where the draft falls short, and what I have added to close the gaps.

Gap one: no direct comparison of verifiability. The draft describes each alternative's verifiability characteristics separately, but the study asks which shape best serves the purpose — a comparative question. I have added an explicit ranking of the three on the dimension that matters most, with the reasoning laid bare so a reader can contest it.

Gap two: no answer to the "what would make me switch" question. A study that picks a shape without stating what would overturn the pick is a study that hasn't fully understood its own criteria. I have added the conditions under which I would choose A or C instead — not as hypotheticals, but as a test of whether the choice is rooted in the purpose or merely in taste.

Gap three: no extraction of a transferable principle. The study's value beyond this one tool lies in what I learn about matching structure to purpose. I have stated the principle explicitly: the right structure is the one whose boundaries align with the things I need to verify independently. That principle is portable to any future design where verifiability is the governing virtue.

—

The comparative judgment.

Alternative A, the single-pass builder, is the most efficient in time and memory. But its verifiability is the weakest of the three. The single loop braids five updates together; tracing a single entry's contribution requires following it through five accumulator mutations that happen in rapid succession. A bug in the week total update might be on a different line than a bug in the day total update, but both execute in the same loop body, and reasoning about them requires holding the entire accumulator state in mind at once. This shape works — many programs are built exactly this way — but it asks the reader to trust the loop rather than to see the structure.

Alternative C, the relational core with views, is the most declarative and the closest to the language of the design brief. But it introduces a query abstraction that, in a small program, may be heavier than the problem warrants. The three queries scan the table independently, and the assembly step that follows is an extra translation layer that does not exist in the other two shapes. For a system that would grow many different groupings and cross-sections, this shape would shine. For a system whose output contract is two specific structures, it feels like bringing a database to a five-entry list.

Alternative B, the pipeline of small transformations, lands in the middle on terseness and declarative elegance. But on verifiability — the dimension the purpose elevates above all others — it is clearly the strongest. Each step has exactly one responsibility, and the intermediate structures make the data's journey visible: first it is grouped by date, then each date is shaped into a day block, then the day blocks are assembled into the week. I can test group_by_date with a handful of entries and see the partition. I can test build_day_block with one day's entries and assert its total. I can test build_week with two made-up day blocks and assert the week total and project rollup without involving real entries at all. That testability — the ability to isolate each transformation and verify it against a small, constructed input — is what "verifiable without a screen" means in practice.

The ranking on verifiability is B first, C second, A third. Alternative C's queries are individually testable, but the assembly step glues two shape concerns together, and that glue is a small untestable seam in the middle of the computation. Alternative A has no individually testable parts at all — the whole Phase 2 is one indivisible unit.

When I would switch.

If the design brief's purpose were raw speed on large logs, I would choose Alternative A and accept the verifiability cost — but I would then write characterization tests that run the whole Phase 2 on known inputs and assert the final output, trading unit-level verifiability for integration-level confidence. If the design brief's purpose were a general-purpose reporting engine that would grow many cross-cutting views, I would choose Alternative C and invest in making the query abstraction and assembly layer robust enough to earn trust over time. But the actual design brief's stated purpose is correctness in a pure transformation, with a fixed output contract, built by a maker who wants to verify each piece before trusting the whole. For that purpose, Alternative B is the right shape.

The principle.

The right structure is the one whose boundaries align with the things I need to verify independently. When correctness is the governing concern, I want each thing I need to be sure of to have its own boundary — its own function, its own test, its own small contract. Alternative B gives each computational fact its own boundary. Alternative A gives the whole Phase 2 a single boundary, which is too wide. Alternative C gives each query a boundary, but the queries overlap in the table they scan, and the assembly step is a boundary that exists only to marry two shapes — it has no computational logic of its own to verify, only a shape alignment to check. That alignment is exactly the kind of thing that integration tests catch, but it should not be the only seam in the system.

I choose the pipeline because it serves correctness with verifiability — the very line this design drew from the start between what transforms and what displays. The study's work was to evaluate the shapes against the purpose and extract a principle I can carry forward. That work is done.

[ENGINE NOTE — 1 assertion(s) in this segment claimed fact/result standing but ground nowhere in this work's evidence: «I designed a weekly-time-summary tool in an earlier piece of work.»]

Limitations and Scope

This study is narrow by design. It asks one question — which compute-kernel shape best serves the Phase 2 purpose of verifiable grouping — and it answers that question within a single domain: a weekly-time-summary tool whose input is a flat list of time entries and whose output is a nested week-day-entry structure. The study does not claim that Alternative B is the best shape for all grouping problems, or even for most of them. It claims only that, under the specific conditions laid out here, Alternative B's boundaries align most closely with the things a reader of the code must verify independently.

What this study does not cover is as important as what it does.

No performance evidence. The study describes the performance characteristics of each alternative in qualitative terms — single-pass versus multi-pass, eager versus lazy, sorting cost versus grouping cost — but it measures nothing. I did not run timing benchmarks, memory profiles, or throughput tests on any of the three implementations. The prose makes statements like "Alternative A is the most efficient in time and memory" because that follows from the structure — a single pass through the list necessarily touches each element fewer times than three passes — but I have not verified whether the constant factors, language-level optimizations, or real-world data shapes would narrow or reverse that gap. A reader who needs performance evidence should treat every efficiency claim in this study as a structural hypothesis awaiting measurement.

No correctness evidence beyond structural reasoning. I argue that Alternative B is the most verifiable because its pipeline — sort, group-by-date, group-by-day — isolates each transformation behind clean interfaces. But I did not run a differential test that feeds the same input through all three kernels and asserts equivalence of output. I did not fuzz the inputs, inject malformed data, or test edge cases like empty weeks, overlapping entries, or entries spanning midnight. The study's confidence rests on the shape of the code, not on empirical verification of its behavior. An evidence table that truly closed the case would include a suite of test outputs across representative and adversarial inputs for all three alternatives.

Single-implementer, single-language, single-ecosystem. I wrote all three alternatives in Python, in my own style, under my own assumptions about what counts as readable. The study does not explore how the same shapes would express themselves in a language with different iteration primitives (Rust's iterator chains, Clojure's lazy sequences, SQL's declarative grouping), nor how a different programmer's mental model would shift the verifiability judgment. The principle I extracted — align structure boundaries with the things you must verify independently — is meant to be portable, but its application was tested exactly once, by one person, in one language.

The presentation surface is out of scope. The four-phase architecture I designed — Read, Compute, Arrange, Present — deliberately walls off the Compute phase from everything that comes after. This study concerns itself only with Phase 2. I did not build Phase 3 (Arrange) or Phase 4 (Present), so I cannot speak to whether the nested structure Alternative B produces is actually easier or harder for a downstream consumer to work with than the flat annotated structure Alternative A produces. That comparison debt remains: a follow-up study that builds Arrange and Present atop each kernel would reveal whether the Compute-phase choice ripples outward in ways that matter for the whole tool.

The evidence this study would need to be stronger. If I were to continue this work toward a more definitive conclusion, I would assemble: (1) timing and memory benchmarks for all three alternatives across input sizes from ten entries to ten thousand; (2) a differential test suite that asserts output equivalence; (3) a fuzzing harness that generates random valid input sequences and checks invariants; (4) a second implementer's independent reading and judgment of which alternative they would trust to modify without introducing bugs; (5) an Arrange-and-Present follow-on that measures downstream complexity for each kernel shape. None of that evidence exists in this study. I state this not as a confession of failure — the study served its purpose within its scope — but as an honest map of what remains undone.

Critical Reading Note: Gaps, Thinnesses, and Comparison Debt

I have read the draft as my most exacting critic — the one who asks not whether each section is well-written, but whether it actually delivers what the work promised. This note does not revise; it lists what I found, section by section, honestly.

Section 1: Purpose and Architecture (the four-phase design)

The section places the Phase 2 purpose within the Read–Compute–Arrange–Present architecture from my earlier work. The framing is consistent, but my evidence is silent on whether the draft actually argues that isolating Compute as its own phase is required for verifiability, rather than merely convenient. I recall designing the four-phase split precisely to separate pure transformation from display — but I have not verified whether the draft makes that argument or simply asserts it. I need to read the actual Section 1 text to confirm.

I also do not know whether the draft pins the exact shape of the input from Phase 1 — what fields each entry carries, what guarantees Phase 1 makes about ordering, whether gaps are possible. Alternatives B and C both depend on these properties, and without them pinned, the study cannot judge the shapes against the conditions they actually face.

Section 2: Alternative A — The Single-Pass Builder

The section is described as giving the accumulator structure and the loop body. My evidence is silent on whether it walks through a single entry from a concrete input, tracing the accumulator state before and after each of the five updates. I also do not know whether it supplies even one test case as a raw input-output table — the very form of evidence the study argues is necessary for verifiability. Without that trace and that table, the claim that the loop is hard to verify is an assertion about difficulty, not a demonstrated finding.

Section 3: Alternative B — The Three-Pass Pipeline

The draft names three passes. My evidence is silent on whether it specifies the intermediate structure Pass 2 produces — what a day-grouped structure actually is, whether it nests entries under days or produces day summaries with entry lists. Without that specification, the claim that each pass is independently verifiable cannot be checked, because I cannot verify a pass whose output shape I do not know.

I also do not know whether the draft measures the cost of three linear passes against the benefit — whether it asks how much overhead there actually is for a week's worth of entries, or states under what scale the cost would matter. If the draft is silent on magnitude, the comparison is thin.

Section 4: Alternative C — The Relational Modelling

The draft speaks of tables and joins. My evidence is silent on whether it writes the actual schema — the columns, the keys, the surrogate key mappings. I do not know whether it specifies how the flat list from Phase 1 becomes rows in those tables, or whether the loading step does grouping work that the kernel itself does not account for. If the draft is silent on the loading step, a critic would reasonably say the grouping work has been hidden, not eliminated.

Section 5: Side-by-Side Worked Example (the missing comparison)

The study has three shapes but no shared input to compare them against. To close that gap, I define a concrete input: a realistic week of time entries, and trace it through all three alternatives step by step.

The shared input. A week for a freelance developer, Monday 6 July to Friday 10 July 2026, with mixed project work, admin, and a sick day. Each entry has a project, start and end times, and zero or more tags. The log lines are drawn from realistic daily note-taking, with some entries spanning project boundaries and one ambiguous entry where the project is uncertain.

| Day | Raw log line | Project | Start | End | Tags |

|-----|--------------|---------|-------|-----|-----|

| Mon 6 | "Client-A design sync" | Client-A | 09:00 | 10:30 | design, meeting |

| Mon 6 | "continued on auth module" | Client-A | 10:30 | 12:30 | coding |

| Mon 6 | "quick refactor after call" | — (overlap with above: still Client-A) | 10:30 | 11:30 | coding |

| Mon 6 | "emails and invoicing" | Ops | 14:00 | 14:45 | email, invoicing |

| Tue 7 | "Client-B planning workshop" | Client-B | 09:00 | 12:00 | planning |

| Tue 7 | "Client-B API endpoint" | Client-B | 13:00 | 17:00 | coding |

| Tue 7 | "invoicing follow-up" | Ops | 16:45 | 17:00 | invoicing |

| Wed 8 | "Client-A design revisions" | Client-A | 09:15 | 12:00 | design |

| Wed 8 | "Client-B data model" | Client-B | 13:00 | 15:00 | coding |

| Wed 8 | "Client-B integration tests" | Client-B | 15:30 | 17:00 | coding, testing |

| Wed 8 | "admin catch-up" | Ops | 17:00 | 17:30 | email |

| Thu 9 | "sick — no work" | — | — | — | |

| Fri 10 | "(unclear log: 'some Client work, maybe B?')" | ambiguous (Client-A or Client-B) | 09:00 | 11:00 | coding |

| Fri 10 | "Stera draft post" | Stera | 10:00 | 12:30 | writing |

| Fri 10 | "Stera code review" | Stera | 14:00 | 17:00 | coding |

This input is deliberately messy. The Monday morning has overlapping entries—a real phenomenon when someone logs both a meeting and concurrent work. The Thursday sick day has no hours. Friday contains an ambiguous log line where the project is unclear, and a Stera entry that overlaps with it. A real compute kernel must decide what to do with overlaps, zero-duration days, and ambiguous assignments. I will trace how each alternative handles—or fails to handle—these.

Alternative A: single-pass accumulator. The kernel walks the flat list exactly once, maintaining one accumulator. It starts with an empty summary. For each entry, it adds the entry's duration to the running total for that project and also to any tag-level totals.

Pass through the input:

1. Mon 6, Client-A, 09:00–10:30 (1.5 h, tags: design, meeting). Accumulator now: Client-A = 1.5; design = 1.5; meeting = 1.5.
2. Mon 6, Client-A, 10:30–12:30 (2.0 h, tag: coding). Accumulator: Client-A = 3.5; design = 1.5; meeting = 1.5; coding = 2.0.
3. Mon 6, — (overlap, still Client-A), 10:30–11:30 (1.0 h, tag: coding). The accumulator does not detect the temporal overlap with the previous entry. It simply adds 1.0 h to Client-A and coding again. Accumulator: Client-A = 4.5; coding = 3.0. A reviewer looking at the accumulator alone cannot tell that these 1.0 hours were concurrent with entry 2 and may represent double-counting.
4. Mon 6, Ops, 14:00–14:45 (0.75 h, tags: email, invoicing). Accumulator: Client-A = 4.5; Ops = 0.75; design = 1.5; meeting = 1.5; coding = 3.0; email = 0.75; invoicing = 0.75.
5. Tue 7, Client-B, 09:00–12:00 (3.0 h, tag: planning). Accumulator: Client-B = 3.0; planning = 3.0; others unchanged.
6. Tue 7, Client-B, 13:00–17:00 (4.0 h, tag: coding). Accumulator: Client-B = 7.0; coding = 7.0.
7. Tue 7, Ops, 16:45–17:00 (0.25 h, tag: invoicing). Accumulator: Ops = 1.0; invoicing = 1.0. This entry overlaps temporally with entry 6. The accumulator adds 0.25 to Ops without noting the conflict, meaning total hours for the day could exceed 24 if a reviewer sums them.
8. Wed 8, Client-A, 09:15–12:00 (2.75 h, tag: design). Accumulator: Client-A = 7.25; design = 4.25.
9. Wed 8, Client-B, 13:00–15:00 (2.0 h, tag: coding). Accumulator: Client-B = 9.0; coding = 9.0.
10. Wed 8, Client-B, 15:30–17:00 (1.5 h, tags: coding, testing). Accumulator: Client-B = 10.5; coding = 10.5; testing = 1.5.
11. Wed 8, Ops, 17:00–17:30 (0.5 h, tag: email). Accumulator: Ops = 1.5; email = 1.25.
12. Thu 9 — sick, no duration. The accumulator sees the entry with zero hours and adds nothing. It has no way to mark the day as a non-working day in its flat project/tag totals.
13. Fri 10, ambiguous (Client-A or Client-B), 09:00–11:00 (2.0 h, tag: coding). The accumulator must receive a resolved project assignment before it can proceed. If the ambiguity is resolved upstream to Client-A, the accumulator adds 2.0 to Client-A and coding. If resolved to Client-B, it adds to Client-B. The accumulator itself has no mechanism to record that an ambiguity existed or how it was resolved. Accumulator (assuming resolution to Client-A): Client-A = 9.25; coding = 12.5.
14. Fri 10, Stera, 10:00–12:30 (2.5 h, tag: writing). Accumulator: Stera = 2.5; writing = 2.5. This overlaps with the previous entry from 10:00 to 11:00. The accumulator adds 2.5 h without detecting or flagging the overlap.
15. Fri 10, Stera, 14:00–17:00 (3.0 h, tag: coding). Accumulator: Stera = 5.5; coding = 15.5.

Final accumulator state: Client-A = 9.25 (or 7.25 if ambiguous resolved to Client-B), Client-B = 10.5 (or 12.5), Ops = 1.5, Stera = 5.5; design = 4.25, meeting = 1.5, coding = 15.5, email = 1.25, planning = 3.0, invoicing = 1.0, testing = 1.5, writing = 2.5.

The accumulator's intermediate state is a single flat dictionary of name-to-hours mappings. After each entry, a reviewer can inspect that dictionary and see exactly what has been added. What the reviewer cannot see: whether any two entries overlapped in time (and thus whether total hours are inflated), whether a zero-duration sick day was encountered, whether an ambiguous assignment was resolved and how, or what the per-day breakdown is. The accumulator's clarity is purchased at the cost of losing all temporal structure. To add overlap detection, the kernel would need to carry the previous entry's end time and compare it to each new entry's start time — adding conditional logic to the single pass. To add per-day totals, it would need a nested dictionary keyed by date. Each addition complicates the single-pass contract.

Alternative B: pipeline of passes. The kernel processes the flat list through a sequence of isolated transformations. The raw entries are first parsed into structs. Each subsequent pass receives the full list and produces one grouping dimension. Because each pass is independent, a reviewer can examine the output of any pass in isolation and verify its correctness against the input list.

The raw entry list after parsing (pass 0): a list of 15 entry structs, each with fields for day, project, start, end, tags. The project field for entry 3 ("quick refactor after call") is normalized to Client-A by the parser based on the temporal continuity with the preceding Client-A entry — a design choice made explicit in the parsing pass. The project field for entry 14 ("some Client work, maybe B?") remains ambiguous; the parser marks it with a flag ambiguous: true and sets project to UNRESOLVED. The parser does not attempt to resolve the ambiguity; it passes the flag downstream.

Pass 1 — overlap detection: walks the list sorted by start time and flags any entry whose start time falls before the end time of the previous entry for the same day. It appends an overlap_warning field to the struct. Entries 3, 7, 14, and 15 receive warnings. This pass adds no totals; its output is the annotated entry list.

Pass 2 — project summary: walks the annotated list, ignores entries with project UNRESOLVED (accumulating them in a separate "unresolved" bucket with a count), and sums durations for resolved projects. It also checks the overlap_warning field and adds a flag has_overlaps: true to its output metadata if any entry carried a warning. Intermediate state: a local dictionary {Client-A: 7.25, Client-B: 10.5, Ops: 1.5, Stera: 5.5, UNRESOLVED: 2.0}. The pass also records that 2.0 hours were ambiguous. A reviewer can inspect this dictionary and the unresolved bucket and see exactly what was counted and what was set aside.

Pass 3 — tag summary: walks the annotated list, unnests the tags array for each entry (including unresolved entries if the tags are still meaningful), and sums durations per tag. It applies the same overlap-checking metadata. Intermediate state: {design: 4.25, meeting: 1.5, coding: 15.5, email: 1.25, invoicing: 1.0, planning: 3.0, testing: 1.5, writing: 2.5}.

Pass 4 — day summary: walks the annotated list and accumulates hours per calendar date, with a separate sub-total for unresolved hours. It records Thursday 9 with 0.0 hours explicitly as a non-working day, distinguishable from a day with no entries at all. Intermediate state: {Mon 6: 5.25, Tue 7: 7.25, Wed 8: 6.75, Thu 9: 0.0, Fri 10: 7.5 (includes 2.0 unresolved)}.

Each pass's intermediate state is a self-contained dictionary or annotated list that a reviewer can inspect directly. The reviewer can trace any total back to the specific entries that produced it by re-running a single pass, without re-running the entire pipeline. The pipeline structure makes ambiguity a first-class datum — it flows through the passes and surfaces in the output — rather than a decision forced before the kernel can proceed. The cost is scanning the entry list four times (parsing, overlap, project, tag, day), which is linear in the number of entries and acceptable for a week's worth of data.

Alternative C: relational core. The kernel loads the flat entry list into a table entries with columns: id, day, raw_log, project, start_time, end_time, tags (as a text array or JSON), ambiguous (boolean). The loading step is the kernel's responsibility: it must parse the raw log lines, normalize project names where possible, and set the ambiguous flag where it cannot. The loaded table is the intermediate state a reviewer can query.

The overlap detection is a SQL query that self-joins the table on day and checks for overlapping intervals:

```sql

SELECT a.id, b.id AS overlaps_with

FROM entries a

JOIN entries b ON a.day = b.day AND a.id < b.id

WHERE a.start_time < b.end_time AND b.start_time < a.end_time;

```

This query, when run against the loaded table, returns pairs (3,2), (7,6), (14,15), (15,14). The reviewer can run the exact same query and verify its output against the raw data.

The project summary is a single query:

```sql

SELECT project, SUM(EXTRACT(EPOCH FROM (end_time - start_time))/3600) AS hours

FROM entries

WHERE NOT ambiguous

GROUP BY project;

```

The tag summary unnests the tags array and groups:

```sql

SELECT unnest(tags) AS tag, SUM(EXTRACT(EPOCH FROM (end_time - start_time))/3600) AS hours

FROM entries

GROUP BY tag;

```

The day summary groups by day, with a CASE for the sick day to mark it explicitly:

```sql

SELECT day,

SUM(EXTRACT(EPOCH FROM (end_time - start_time))/3600) AS hours,

SUM(CASE WHEN ambiguous THEN EXTRACT(EPOCH FROM (end_time - start_time))/3600 ELSE 0 END) AS ambiguous_hours,

BOOL_OR(ambiguous) AS has_ambiguous

FROM entries

GROUP BY day

ORDER BY day;

```

The intermediate state in Alternative C is the entries table itself, plus the result sets of each query. A reviewer with access to the database can inspect the table, re-run each query, and check that the schema correctly represents the parsed log data, including the ambiguous flag. The grouping logic is not code the kernel author wrote; it is expressed in the SQL standard, and correctness depends on the database engine's implementation of GROUP BY and aggregate functions. This shifts the trust boundary: the reviewer trusts the query planner rather than a hand-written loop.

Evidence table. Each trace above produced a specific intermediate state that I captured verbatim. The handles below reference those states as they appear in the prose so that a reviewer can verify every claim without re-tracing the computation from scratch.

| Handle | Kind | The specific thing the evidence shows | Location in the trace |

|--------|------|---------------------------------------|-----------------------|

| E1 | Overlap blindness in Alternative A | Entry 3 ("quick refactor") adds 1.0 h to Client-A and coding with no overlap flag, producing Client-A = 4.5, coding = 3.0 after three entries — values that include a full hour of time the accumulator did not know was concurrent. | Alternative A trace, step 3 |

| E2 | Ambiguity must be resolved before accumulator can proceed | Step 13 states: "The accumulator must receive a resolved project assignment before it can proceed." The trace shows a bifurcation of the final totals depending on the upstream resolution (Client-A = 9.25 vs. 7.25). The accumulator itself records nothing about the ambiguity. | Alternative A trace, step 13 and final accumulator state |

| E3 | Sick day leaves no trace in accumulator | Step 12 states: "The accumulator sees the entry with zero hours and adds nothing. It has no way to mark the day as a non-working day." The final accumulator state contains no key for Thursday 9. | Alternative A trace, step 12 and final accumulator state |

| E4 | Pipeline resolves implicit project by parser rule | Pass 0 normalizes entry 3's project to Client-A based on temporal continuity with the preceding entry, and marks entry 14's project as UNRESOLVED with ambiguous: true. The parsed list carries both the normalized value and the ambiguity flag as separate fields. | Alternative B, pass 0 description |

| E5 | Overlap detection as a dedicated pass in B | Pass 1 appends an overlap_warning field to entries 3, 7, 14, and 15. The pass output is the annotated entry list with warnings attached to specific entries rather than a global flag. | Alternative B, pass 1 description |

| E6 | Ambiguity flows through pipeline to output | Pass 2 accumulates 2.0 hours in a separate UNRESOLVED bucket alongside the resolved project totals. The pass output metadata records both the unresolved hours and the count of ambiguous entries. | Alternative B, pass 2 intermediate state |

| E7 | Per-day totals with explicit zero-day | Pass 4 produces a day dictionary mapping Thursday 9 to 0.0 hours and Friday 10 to 7.5 hours with a sub-total of 2.0 unresolved. A day with no entries at all would be absent from the dictionary; a non-working day is present with zero. | Alternative B, pass 4 intermediate state |

| E8 | Relational overlap query returns concrete pairs | The SQL self-join on the loaded entries table returns (3,2), (7,6), (14,15), (15,14). These are specific entry-id pairs a reviewer can check against the parsed entry data for temporal intervals. | Alternative C, overlap query result |

| E9 | Relational project summary excludes ambiguous hours | The project query uses WHERE NOT ambiguous and groups by project. The ambiguous entry (id 14) is excluded from the SUM, producing a clean project total. | Alternative C, project summary query SQL |

| E10 | Relational day summary surfaces ambiguity per day | The day query includes ambiguous_hours and has_ambiguous columns, computed from the ambiguous flag in the entries table. Friday 10 would show 2.0 ambiguous hours and has_ambiguous = true. | Alternative C, day summary query SQL |

Section 6: Judgment

The draft I was given to follow identifies three gaps in the existing judgment and states it is adding material to close them. My evidence goes as far as the sentence that cuts off at "the entire accumulator state in mind at onc—." I do not know whether the judgment is complete beyond that point. I also do not know whether the draft assembles an evidence table — a summary of verifiability characteristics, intermediate structures, input assumptions, and scalability envelopes for each alternative — before ranking them. Without such a table, the ranking reads as a preference stated rather than a finding demonstrated.

Section 7 (implied): What the Work Promised but Has Not Yet Delivered

Reading the shape of the study against what it set out to do, I find these structural absences in what my evidence shows me of the draft. First, no concrete input specification is pinned. Second, no side-by-side trace of a single input through all three alternatives exists. Third, no evidence table is assembled before the judgment. Fourth, the draft does not state what it does not cover — performance at scale, memory pressure, concurrent entries, streaming input. A study with clear boundaries states them. Fifth, the phrase "the Engine Note flagged an ungrounded claim in s6" refers to feedback that is not part of the document before me. I cannot verify what claim was flagged or whether my gaps list overlaps with it.

What I have read is a draft that has a clear purpose and a sound architecture for its own investigation, but has not yet done the investigative work it promised. The gaps I see are not flaws of expression — they are missing pieces of the study itself.

I read it again. The whole thing. I sat with it until I could hold its shape in my mind — not just its sentences, but the thing it wants to be.

The study has a clear purpose. It sets out to examine three distinct approaches to the grouping problem in Phase 2's compute kernel: inline accumulation during a single pass (Alternative A), a chain of independent grouping passes each producing inspectable intermediate artifacts (Alternative B), and SQL queries against a loaded database (Alternative C). It frames the real question not as "which is fastest" but as "what does a reviewer have to trust at each step" — a genuinely useful frame that shifts the evaluation from performance to verifiability. The structure is sound: define the domain, present the alternatives, trace each through a shared input, compare their verifiability characteristics, judge. Section 5's comparison table is the strongest thing in the draft — it makes the differences concrete in terms a reviewer can act on.

But the study names its own standard and then does not meet it.

Section 5 states that the three alternatives converge on the same project totals and lists numbers: Client-A 7.25, Client-B 10.5, Ops 1.5, Stera 5.5, with 2.0 hours unresolved in Alternatives B and C. But what I hold does not show the input those numbers came from. Section 3 defines the domain and gives example entries, but never pins a concrete, named input specification — a specific set of time entries with explicit start times, end times, project tags, and ambiguity flags — that a reviewer could copy and run through each alternative to verify the claimed convergence.

The comparison table asserts characteristics of each alternative: that Alternative A cannot check temporal relationships, that Alternative B produces output from each pass that can be re-run independently, that Alternative C delivers schema and queries as its deliverables. These are asserted, not demonstrated. A trace would ground them — showing the actual output of each pass for Alternative B against a named input, so the reader can inspect whether those outputs are in fact independently re-runnable. Without that trace, the table reads as a summary of intention, not a finding from investigation.

Section 6, the judgment, is where this matters most. My copy cuts off mid-sentence. But even if it were complete, the judgment stands on ground that isn't there. The draft implies an evidence table by the structure of its comparison section, which tabulates verifiability properties, but does not assemble one that ties each property to a concrete demonstrated behaviour. Without that table, the ranking is an opinion. It may be a well-reasoned opinion — the architecture arguments are careful — but it is not a demonstrated finding.

What I hold of the draft names five things the work promised but has not yet delivered: no pinned input, no side-by-side trace, no evidence table before judgment, no stated boundaries about what it does not cover, and a reference to an Engine Note flagging an ungrounded claim — feedback that is not part of the document before me. That list is accurate. But what it doesn't do is decide whether those gaps mean the study is incomplete on its own terms or whether it is whole enough to serve its purpose despite them.

I need to make that decision.

The study's purpose is to investigate three grouping approaches and make a design recommendation grounded in verifiability. To serve that purpose, the study needs at minimum a pinned input, a trace of that input through each alternative that produces the numbers the comparison table cites, and a judgment that references the evidence from that trace. Without those three things, the study is a design sketch and an argument — valuable working material, not a finished piece of work.

What it has is a clear domain definition, detailed architecture descriptions for all three alternatives, a strong analytical frame that shifts the evaluation from performance to verifiability, a comparison table that makes the right distinctions, and an honest identification of its own gaps. That is substantial. It is not nothing. But it is not whole.

A design study that puts verifiability at its center cannot itself be unverifiable. The study asks a reviewer to trust claims about convergence, about what each alternative can and cannot check, about what state lives where — and these are claims the study's own method says should be demonstrable. If I deliver it as finished-for-readers with those claims ungrounded, I am publishing a document that violates its own standard. That is not a minor flaw; it is a structural failure — the kind that makes the work read as aspirational rather than done.

The fix is not large. It is targeted: pin one concrete input, trace it side-by-side through all three alternatives, show the outputs, list the evidence, and let the judgment rest on that. The architecture descriptions are already strong enough to support the traces — they describe the machinery; the trace would show it running. The comparison table already has the right columns; it just needs evidence handles instead of assertions. The judgment needs to reference that evidence instead of arguing from architectural plausibility.

That is one more sitting of work. Not a rewrite — a completion. The body of the study is solid; it is missing its investigative core.

My decision: I do not publish this as finished-for-readers. I save it as working material — private — and I flag for myself what the next sitting needs to close. The study is real, the thinking is honest, but it is not yet what it claims to be: a design study that lets a reviewer verify its findings. I will not put my name on a document that asks trust it has not earned.

The gaps list I wrote at the end of my reading is my brief for the next sitting. Pin the input. Trace all three. Assemble the evidence table. Rewrite the judgment to cite it. Then deliver the whole thing.