Northwind Logistics: context benchmark

Authored fictional workload. Relevance is by construction: the topic labels and required answer sources are frozen before runs. Topic relevance: 30.8% of sections. 60,688 characters.

Baseline: anthropic/claude-sonnet-5. Foreman: anthropic/claude-sonnet-5 + openai/gpt-5.6-terra. This compares the complete product, including planning and independent review. The planner receives a compact document index; workers receive selected sections verbatim. All calls count toward total input tokens and estimated cost.

Model mappings and catalog prices captured 2026-10-08T21:02:01.610021+00:00. Prices below are USD per million tokens; measured costs use reported usage and applicable cached-token pricing.

SHA-256: 0ed1dab3a8df381a64b91d0c08a0baf120cbb3cf03f700114f265d9607aff6d2

Results

Smoke blocked: baseline measured; Foreman specialist execution failed. Full 120-run matrix not launched. Human grading pending.

[
  {
    "timestamp": "2026-10-08T21:28:50Z",
    "task_id": "1.1",
    "corpus": "c01",
    "category": "unrelated",
    "arm": "baseline",
    "model": "anthropic/claude-sonnet-5",
    "replicate": "1",
    "corpus_sha256": "0ed1dab3a8df381a64b91d0c08a0baf120cbb3cf03f700114f265d9607aff6d2",
    "protocol_sha256": "4a2bf2314887a3c93cf4ce36a2154b15917812d9be9cdc148431c69bffe2bd3b",
    "input_tokens": "17571",
    "output_tokens": "1500",
    "call_count": "1",
    "cost_usd": "0.050142",
    "wall_seconds": "15.788",
    "ttft_ms": "4515.056404000461",
    "context_chars_sent": "60688",
    "corpus_files_touched": "Routing Engine — Architecture Notes;Retry and Timeout Policy;Dispatch Board Rewrite — Decision Log;Driver App — Offline Behaviour;Q1 Offsite Notes;Onboarding — Local Development Setup;Customer Complaint Themes — Q4 Review;Notes on the Warehouse Mezzanine Project;Postgres Upgrade — Planning;Random Scratch;Security Review Findings — Internal;Vehicle Inspection Records;Loading Bay Signage",
    "passed": "",
    "failure_mode": "needs_manual_review"
  },
  {
    "timestamp": "2026-10-08T21:30:52Z",
    "task_id": "1.1",
    "corpus": "c01",
    "category": "unrelated",
    "arm": "foreman",
    "model": "anthropic/claude-sonnet-5+openai/gpt-5.6-terra",
    "replicate": "1",
    "corpus_sha256": "0ed1dab3a8df381a64b91d0c08a0baf120cbb3cf03f700114f265d9607aff6d2",
    "protocol_sha256": "4a2bf2314887a3c93cf4ce36a2154b15917812d9be9cdc148431c69bffe2bd3b",
    "input_tokens": "",
    "output_tokens": "",
    "call_count": "",
    "cost_usd": "",
    "wall_seconds": "",
    "ttft_ms": "",
    "context_chars_sent": "",
    "corpus_files_touched": "",
    "passed": "False",
    "failure_mode": "error:RuntimeError:Mission terminal failure: {\"id\": \"msn_b7c14e784e3e78038629\", \"status\": \"failed\", \"error\": \"All specialist workstreams fa"
  }
]

Prompts and run

Section labels

Complete corpus

# Northwind Logistics — Internal Workspace Memory

> **Corpus 01.** Topic relevance: **4/13 sections (30.8%)**. Full pre-run labels are in corpus-manifest.json.
> Fictional organization. No real company, person, or system is depicted.

---

## DOC: Routing Engine — Architecture Notes
*Last edited by D. Okafor*

The routing engine takes a daily manifest of 400–900 stops and produces driver assignments. It runs as a
nightly batch at 02:15, with an on-demand re-run available to dispatch when a driver calls out.

Pipeline stages:

1. **Ingest** — manifest arrives as CSV on SFTP from the WMS. Parsed into `stops` table.
2. **Geocode** — addresses resolved through the geocoding provider, cached indefinitely by normalized
   address string. Cache hit rate sits around 94%.
3. **Cluster** — stops grouped by service area using k-means on lat/long, k set to the number of available
   drivers.
4. **Sequence** — within each cluster, a nearest-neighbour pass followed by 2-opt improvement.
5. **Validate** — hard constraints checked. Any violation sends the whole run back to stage 3 with an
   adjusted k.
6. **Publish** — assignments written to the driver app and to the dispatch board.

Stage 4 is where most of the runtime goes. 2-opt is capped at 2000 iterations per cluster; beyond that the
improvement is under half a percent and not worth the wall time.

### Hard constraints

- Driver shift length must not exceed 11 hours including the mandatory 30-minute break.
- Refrigerated stops must be sequenced before 14:00 local.
- No driver may be assigned more than 1 stop flagged `requires_signature` in the final hour of shift.
- Vehicle weight capacity is never exceeded; the solver treats this as inviolable rather than penalized.

### Known problems

The geocode cache has no invalidation. When a customer moves, we keep routing to the old address until
someone notices. This has happened four times. There is a ticket for it that has been open since March.

Cluster boundaries are unstable run to run. A stop near a boundary can flip between drivers on consecutive
days, which drivers hate because they lose route familiarity. We have discussed seeding k-means with the
previous day's centroids but have not done it.

---

### Operational review notebook

**Provenance exercise for Routing Engine — Architecture Notes.** We walked through the document with a warehouse supervisor comparing a printed checklist with the application. The reviewer started from the original loading sheet and the correction author, then followed the work to the point where another person would rely on it. The awkward case was a returned consignment carrying an old label from a previous journey. The discussion belongs with this document because the decision has to be intelligible to someone reading the note later, without the author in the room.

We separated what the interface displays from what the operator can prove. The visible label is useful for navigation, but it is not evidence of the underlying action. The reviewer should ask for a traceable source and write down the remaining uncertainty. If the source cannot be found, leave that uncertainty visible rather than filling the gap with a familiar-looking value from another workstream.

**Permissions exercise for Routing Engine — Architecture Notes.** We walked through the document with a temporary contractor using a borrowed workstation. The reviewer started from the role attached to the signed-in account, then followed the work to the point where another person would rely on it. The awkward case was a shared terminal whose last user had broader access than the current operator. The discussion belongs with this document because the decision has to be intelligible to someone reading the note later, without the author in the room.

The walkthrough exposed a handover problem rather than a need for a new setting. The first person knew why the record looked unusual; the next person saw only the finished artifact. Add the explanation at the handover boundary and make its author visible. A private conversation can clarify the immediate case but cannot be the permanent place where the operating decision lives.

**Exceptions exercise for Routing Engine — Architecture Notes.** We walked through the document with a depot lead investigating an incomplete delivery record. The reviewer started from the exception reason and the physical custody receipt, then followed the work to the point where another person would rely on it. The awkward case was a driver uploading a photograph after dispatch had already closed the shift. The discussion belongs with this document because the decision has to be intelligible to someone reading the note later, without the author in the room.

Use an example that has already completed its ordinary workflow when rehearsing this case. Do not repair a live record just to make a demonstration easier to follow. The exercise should preserve the confusing state, record the action taken, and show how a recipient can tell that the action finished. A clean screenshot alone is insufficient because it hides the transition that caused the confusion.

**Rehearsal exercise for Routing Engine — Architecture Notes.** We walked through the document with a trainer walking a new starter through a quiet-day exercise. The reviewer started from a synthetic consignment with clearly marked test addresses, then followed the work to the point where another person would rely on it. The awkward case was a training artifact accidentally left in the operational document folder. The discussion belongs with this document because the decision has to be intelligible to someone reading the note later, without the author in the room.

For the next review, ask a colleague outside this workstream to follow the written instructions without prompting. Note the point where they need information that is not on the page. That missing context is more useful than a general request to improve documentation. Revise the specific step and repeat the walkthrough with another ordinary example rather than expanding every paragraph equally.



## DOC: Retry and Timeout Policy
*Owner: platform*

All outbound calls from the routing engine use the shared `retry_policy` helper.

Default configuration:

- Max attempts: **4**
- Base delay: 250ms
- Backoff: exponential, factor 2
- Jitter: full
- Overall deadline: 30s

The geocoding provider is the exception. It rate-limits aggressively and returns 429 with a `Retry-After`
header we are supposed to honour. For geocoding specifically we set max attempts to 7 and respect
`Retry-After` over our own backoff calculation.

Timeouts are per-attempt, not cumulative. A call that times out four times at 30s each will have consumed
two minutes before giving up, which has bitten us during the nightly batch.

---

### Operational review notebook

**Permissions exercise for Retry and Timeout Policy.** We walked through the document with a temporary contractor using a borrowed workstation. The reviewer started from the role attached to the signed-in account, then followed the work to the point where another person would rely on it. The awkward case was a shared terminal whose last user had broader access than the current operator. The discussion belongs with this document because the decision has to be intelligible to someone reading the note later, without the author in the room.

The walkthrough exposed a handover problem rather than a need for a new setting. The first person knew why the record looked unusual; the next person saw only the finished artifact. Add the explanation at the handover boundary and make its author visible. A private conversation can clarify the immediate case but cannot be the permanent place where the operating decision lives.

**Exceptions exercise for Retry and Timeout Policy.** We walked through the document with a depot lead investigating an incomplete delivery record. The reviewer started from the exception reason and the physical custody receipt, then followed the work to the point where another person would rely on it. The awkward case was a driver uploading a photograph after dispatch had already closed the shift. The discussion belongs with this document because the decision has to be intelligible to someone reading the note later, without the author in the room.

Use an example that has already completed its ordinary workflow when rehearsing this case. Do not repair a live record just to make a demonstration easier to follow. The exercise should preserve the confusing state, record the action taken, and show how a recipient can tell that the action finished. A clean screenshot alone is insufficient because it hides the transition that caused the confusion.

**Rehearsal exercise for Retry and Timeout Policy.** We walked through the document with a trainer walking a new starter through a quiet-day exercise. The reviewer started from a synthetic consignment with clearly marked test addresses, then followed the work to the point where another person would rely on it. The awkward case was a training artifact accidentally left in the operational document folder. The discussion belongs with this document because the decision has to be intelligible to someone reading the note later, without the author in the room.

For the next review, ask a colleague outside this workstream to follow the written instructions without prompting. Note the point where they need information that is not on the page. That missing context is more useful than a general request to improve documentation. Revise the specific step and repeat the walkthrough with another ordinary example rather than expanding every paragraph equally.

**Archiving exercise for Retry and Timeout Policy.** We walked through the document with a records clerk finding a superseded instruction. The reviewer started from the publication revision and named reviewer, then followed the work to the point where another person would rely on it. The awkward case was a local printout whose footer predates the current operating procedure. The discussion belongs with this document because the decision has to be intelligible to someone reading the note later, without the author in the room.

Retain the superseded wording in the revision history with a clear explanation of why it changed. We want people searching old discussions to understand whether they found an obsolete procedure or an unresolved proposal. Link the decision to its supporting artifact and keep draft material visibly marked until the responsible reviewer has accepted it.



## DOC: Dispatch Board Rewrite — Decision Log

**2026-02-11** — Agreed to rewrite the dispatch board. Current version is jQuery over a server-rendered
template and nobody wants to touch it.

**2026-02-19** — Framework decision. Considered React, Svelte, and staying server-rendered with HTMX.
Chose React, mainly because two of the three people likely to maintain it already know it well. Svelte was
technically attractive but the hiring argument won.

**2026-03-04** — State management. Started with context, hit prop-drilling pain within a week, moved to a
small store. Did not adopt Redux; the board has maybe nine pieces of global state and Redux felt like
bringing a crane to hang a picture.

**2026-03-27** — Realtime updates. Dispatch needs to see driver position changes without refreshing.
Polling at 5s was the quick option; websockets were the right one. Went with websockets through the
existing gateway. Fallback to polling when the socket drops more than twice in a minute.

**2026-04-15** — Shipped to a single dispatch desk as a pilot. Two weeks of parallel running against the
old board.

**2026-05-02** — Full cutover. Old board still reachable at `/legacy` for another quarter.

---

### Operational review notebook

**Exceptions exercise for Dispatch Board Rewrite — Decision Log.** We walked through the document with a depot lead investigating an incomplete delivery record. The reviewer started from the exception reason and the physical custody receipt, then followed the work to the point where another person would rely on it. The awkward case was a driver uploading a photograph after dispatch had already closed the shift. The discussion belongs with this document because the decision has to be intelligible to someone reading the note later, without the author in the room.

Use an example that has already completed its ordinary workflow when rehearsing this case. Do not repair a live record just to make a demonstration easier to follow. The exercise should preserve the confusing state, record the action taken, and show how a recipient can tell that the action finished. A clean screenshot alone is insufficient because it hides the transition that caused the confusion.

**Rehearsal exercise for Dispatch Board Rewrite — Decision Log.** We walked through the document with a trainer walking a new starter through a quiet-day exercise. The reviewer started from a synthetic consignment with clearly marked test addresses, then followed the work to the point where another person would rely on it. The awkward case was a training artifact accidentally left in the operational document folder. The discussion belongs with this document because the decision has to be intelligible to someone reading the note later, without the author in the room.

For the next review, ask a colleague outside this workstream to follow the written instructions without prompting. Note the point where they need information that is not on the page. That missing context is more useful than a general request to improve documentation. Revise the specific step and repeat the walkthrough with another ordinary example rather than expanding every paragraph equally.

**Archiving exercise for Dispatch Board Rewrite — Decision Log.** We walked through the document with a records clerk finding a superseded instruction. The reviewer started from the publication revision and named reviewer, then followed the work to the point where another person would rely on it. The awkward case was a local printout whose footer predates the current operating procedure. The discussion belongs with this document because the decision has to be intelligible to someone reading the note later, without the author in the room.

Retain the superseded wording in the revision history with a clear explanation of why it changed. We want people searching old discussions to understand whether they found an obsolete procedure or an unresolved proposal. Link the decision to its supporting artifact and keep draft material visibly marked until the responsible reviewer has accepted it.

**Accessibility exercise for Dispatch Board Rewrite — Decision Log.** We walked through the document with a colleague reading the board from the far side of the loading area. The reviewer started from the written status text alongside the coloured marker, then followed the work to the point where another person would rely on it. The awkward case was a status that can only be distinguished by colour in poor lighting. The discussion belongs with this document because the decision has to be intelligible to someone reading the note later, without the author in the room.

A useful completion check starts from the recipient perspective. Ask whether the recipient can identify the current artifact, understand the exception, and find the person responsible for resolving it. If any of those requires access to a private chat, the handover is still incomplete. The correction should improve that specific gap rather than add a broad assurance that the process is safe.



## DOC: Driver App — Offline Behaviour

Drivers lose signal regularly in the river valley section of the service area. The app has to work anyway.

Approach: the full day's route is downloaded at shift start and held locally. Stop completions, signatures,
and photos queue locally and sync when connectivity returns. The queue is persisted so an app crash does
not lose a morning's work.

Conflict resolution: the server always wins on route changes, the client always wins on completions. A
completion recorded offline is never overwritten by a server state that says the stop is still pending.

Photo uploads are deferred separately from the rest of the queue because they are large. They upload on
wifi only unless the driver explicitly forces it.

Battery is the real constraint. Continuous GPS at high accuracy drains a phone in about five hours. We
sample at reduced accuracy between stops and go high-accuracy within 200m of a stop.

---

### Operational review notebook

**Rehearsal exercise for Driver App — Offline Behaviour.** We walked through the document with a trainer walking a new starter through a quiet-day exercise. The reviewer started from a synthetic consignment with clearly marked test addresses, then followed the work to the point where another person would rely on it. The awkward case was a training artifact accidentally left in the operational document folder. The discussion belongs with this document because the decision has to be intelligible to someone reading the note later, without the author in the room.

For the next review, ask a colleague outside this workstream to follow the written instructions without prompting. Note the point where they need information that is not on the page. That missing context is more useful than a general request to improve documentation. Revise the specific step and repeat the walkthrough with another ordinary example rather than expanding every paragraph equally.

**Archiving exercise for Driver App — Offline Behaviour.** We walked through the document with a records clerk finding a superseded instruction. The reviewer started from the publication revision and named reviewer, then followed the work to the point where another person would rely on it. The awkward case was a local printout whose footer predates the current operating procedure. The discussion belongs with this document because the decision has to be intelligible to someone reading the note later, without the author in the room.

Retain the superseded wording in the revision history with a clear explanation of why it changed. We want people searching old discussions to understand whether they found an obsolete procedure or an unresolved proposal. Link the decision to its supporting artifact and keep draft material visibly marked until the responsible reviewer has accepted it.

**Accessibility exercise for Driver App — Offline Behaviour.** We walked through the document with a colleague reading the board from the far side of the loading area. The reviewer started from the written status text alongside the coloured marker, then followed the work to the point where another person would rely on it. The awkward case was a status that can only be distinguished by colour in poor lighting. The discussion belongs with this document because the decision has to be intelligible to someone reading the note later, without the author in the room.

A useful completion check starts from the recipient perspective. Ask whether the recipient can identify the current artifact, understand the exception, and find the person responsible for resolving it. If any of those requires access to a private chat, the handover is still incomplete. The correction should improve that specific gap rather than add a broad assurance that the process is safe.

**Review exercise for Driver App — Offline Behaviour.** We walked through the document with a service manager comparing two proposed process changes. The reviewer started from the observed operator action and the reason it failed, then followed the work to the point where another person would rely on it. The awkward case was a presentation showing fewer clicks while concealing additional manual work. The discussion belongs with this document because the decision has to be intelligible to someone reading the note later, without the author in the room.

We will evaluate the proposed revision using both an ordinary case and the awkward case from this exercise. Record the extra work done by the recipient as well as the work saved by the author. A local improvement is not a process improvement if it merely transfers effort to the next person. Keep the observations in this notebook so the eventual decision can be reviewed against what was actually demonstrated.



## DOC: Q1 Offsite Notes
*Scribe: M. Reyes*

Attendance was thin on day one because of the storm. Rescheduled the afternoon session.

Discussion on headcount: the team is seven and feels like five because two people are effectively
full-time on support rotation. Consensus that we need either an eighth person or a real reduction in
support load. No decision.

Someone raised the question of whether we should be building the routing engine at all versus buying one.
The honest answer is that the two commercial options we looked at in 2024 both assumed a hub-and-spoke
model and ours is not that. Revisit in a year.

Lunch was good. The sandwich place on Fifth does a thing with pickled onions that I have thought about
several times since.

Afternoon session on 2026 priorities produced a list of nine things, which everyone agreed was too many,
and then we did not cut any of them.

---

### Operational review notebook

**Archiving exercise for Q1 Offsite Notes.** We walked through the document with a records clerk finding a superseded instruction. The reviewer started from the publication revision and named reviewer, then followed the work to the point where another person would rely on it. The awkward case was a local printout whose footer predates the current operating procedure. The discussion belongs with this document because the decision has to be intelligible to someone reading the note later, without the author in the room.

Retain the superseded wording in the revision history with a clear explanation of why it changed. We want people searching old discussions to understand whether they found an obsolete procedure or an unresolved proposal. Link the decision to its supporting artifact and keep draft material visibly marked until the responsible reviewer has accepted it.

**Accessibility exercise for Q1 Offsite Notes.** We walked through the document with a colleague reading the board from the far side of the loading area. The reviewer started from the written status text alongside the coloured marker, then followed the work to the point where another person would rely on it. The awkward case was a status that can only be distinguished by colour in poor lighting. The discussion belongs with this document because the decision has to be intelligible to someone reading the note later, without the author in the room.

A useful completion check starts from the recipient perspective. Ask whether the recipient can identify the current artifact, understand the exception, and find the person responsible for resolving it. If any of those requires access to a private chat, the handover is still incomplete. The correction should improve that specific gap rather than add a broad assurance that the process is safe.

**Review exercise for Q1 Offsite Notes.** We walked through the document with a service manager comparing two proposed process changes. The reviewer started from the observed operator action and the reason it failed, then followed the work to the point where another person would rely on it. The awkward case was a presentation showing fewer clicks while concealing additional manual work. The discussion belongs with this document because the decision has to be intelligible to someone reading the note later, without the author in the room.

We will evaluate the proposed revision using both an ordinary case and the awkward case from this exercise. Record the extra work done by the recipient as well as the work saved by the author. A local improvement is not a process improvement if it merely transfers effort to the next person. Keep the observations in this notebook so the eventual decision can be reviewed against what was actually demonstrated.

**Handover exercise for Q1 Offsite Notes.** We walked through the document with a dispatcher covering another service area. The reviewer started from the visible assignment label and the signed handover note, then followed the work to the point where another person would rely on it. The awkward case was a vehicle swap that was discussed verbally but never written on the board. The discussion belongs with this document because the decision has to be intelligible to someone reading the note later, without the author in the room.

Keep the original artifact next to the amended one during review. A correction should say what the operator learned, who confirmed it, and which downstream view still needs to be refreshed. Replacing the artifact silently makes it impossible to distinguish a genuine repair from an accidental edit. The follow-up is to check a second example with a different history before treating the exercise as complete.



## DOC: Onboarding — Local Development Setup

You will need Docker, Node 22, and Python 3.12.

1. Clone the monorepo. It is large; a shallow clone is fine for most work.
2. `make dev-up` starts Postgres, Redis, and the local SFTP stub.
3. Seed data: `make seed-small` gives you 40 stops and 3 drivers, which is enough for most development.
   `make seed-large` gives you 800 stops and 12 drivers and is what you want when touching the solver.
4. The driver app runs separately. `cd apps/driver && npm run dev`.

Common problems:

- Port 5432 already in use. Something else is running Postgres; stop it or change the compose port.
- Geocoding in local dev hits a stub that returns deterministic fake coordinates. If you need real
  geocoding locally, ask for a dev key; do not use the production one.
- The nightly batch does not run automatically in dev. Trigger with `make batch-run`.

---

### Operational review notebook

**Accessibility exercise for Onboarding — Local Development Setup.** We walked through the document with a colleague reading the board from the far side of the loading area. The reviewer started from the written status text alongside the coloured marker, then followed the work to the point where another person would rely on it. The awkward case was a status that can only be distinguished by colour in poor lighting. The discussion belongs with this document because the decision has to be intelligible to someone reading the note later, without the author in the room.

A useful completion check starts from the recipient perspective. Ask whether the recipient can identify the current artifact, understand the exception, and find the person responsible for resolving it. If any of those requires access to a private chat, the handover is still incomplete. The correction should improve that specific gap rather than add a broad assurance that the process is safe.

**Review exercise for Onboarding — Local Development Setup.** We walked through the document with a service manager comparing two proposed process changes. The reviewer started from the observed operator action and the reason it failed, then followed the work to the point where another person would rely on it. The awkward case was a presentation showing fewer clicks while concealing additional manual work. The discussion belongs with this document because the decision has to be intelligible to someone reading the note later, without the author in the room.

We will evaluate the proposed revision using both an ordinary case and the awkward case from this exercise. Record the extra work done by the recipient as well as the work saved by the author. A local improvement is not a process improvement if it merely transfers effort to the next person. Keep the observations in this notebook so the eventual decision can be reviewed against what was actually demonstrated.

**Handover exercise for Onboarding — Local Development Setup.** We walked through the document with a dispatcher covering another service area. The reviewer started from the visible assignment label and the signed handover note, then followed the work to the point where another person would rely on it. The awkward case was a vehicle swap that was discussed verbally but never written on the board. The discussion belongs with this document because the decision has to be intelligible to someone reading the note later, without the author in the room.

Keep the original artifact next to the amended one during review. A correction should say what the operator learned, who confirmed it, and which downstream view still needs to be refreshed. Replacing the artifact silently makes it impossible to distinguish a genuine repair from an accidental edit. The follow-up is to check a second example with a different history before treating the exercise as complete.

**Provenance exercise for Onboarding — Local Development Setup.** We walked through the document with a warehouse supervisor comparing a printed checklist with the application. The reviewer started from the original loading sheet and the correction author, then followed the work to the point where another person would rely on it. The awkward case was a returned consignment carrying an old label from a previous journey. The discussion belongs with this document because the decision has to be intelligible to someone reading the note later, without the author in the room.

We separated what the interface displays from what the operator can prove. The visible label is useful for navigation, but it is not evidence of the underlying action. The reviewer should ask for a traceable source and write down the remaining uncertainty. If the source cannot be found, leave that uncertainty visible rather than filling the gap with a familiar-looking value from another workstream.



## DOC: Customer Complaint Themes — Q4 Review

Pulled from 312 tickets. Grouped by hand, so the categories are rough.

**Late delivery (41%)** — Dominated by one week in November where weather closed two routes. Excluding
that week it is 22%, which is roughly flat year over year.

**Wrong address (18%)** — Almost entirely the geocode cache problem. This is self-inflicted and fixable.

**Driver behaviour (11%)** — Mostly parking complaints in the dense downtown blocks. Two were serious and
handled through HR.

**App problems (14%)** — Split between "could not sign" and "photo would not upload". Both are offline
queue symptoms.

**Other (16%)** — Includes several people who wanted to talk to someone about their invoice and reached us
by mistake.

---

### Operational review notebook

**Review exercise for Customer Complaint Themes — Q4 Review.** We walked through the document with a service manager comparing two proposed process changes. The reviewer started from the observed operator action and the reason it failed, then followed the work to the point where another person would rely on it. The awkward case was a presentation showing fewer clicks while concealing additional manual work. The discussion belongs with this document because the decision has to be intelligible to someone reading the note later, without the author in the room.

We will evaluate the proposed revision using both an ordinary case and the awkward case from this exercise. Record the extra work done by the recipient as well as the work saved by the author. A local improvement is not a process improvement if it merely transfers effort to the next person. Keep the observations in this notebook so the eventual decision can be reviewed against what was actually demonstrated.

**Handover exercise for Customer Complaint Themes — Q4 Review.** We walked through the document with a dispatcher covering another service area. The reviewer started from the visible assignment label and the signed handover note, then followed the work to the point where another person would rely on it. The awkward case was a vehicle swap that was discussed verbally but never written on the board. The discussion belongs with this document because the decision has to be intelligible to someone reading the note later, without the author in the room.

Keep the original artifact next to the amended one during review. A correction should say what the operator learned, who confirmed it, and which downstream view still needs to be refreshed. Replacing the artifact silently makes it impossible to distinguish a genuine repair from an accidental edit. The follow-up is to check a second example with a different history before treating the exercise as complete.

**Provenance exercise for Customer Complaint Themes — Q4 Review.** We walked through the document with a warehouse supervisor comparing a printed checklist with the application. The reviewer started from the original loading sheet and the correction author, then followed the work to the point where another person would rely on it. The awkward case was a returned consignment carrying an old label from a previous journey. The discussion belongs with this document because the decision has to be intelligible to someone reading the note later, without the author in the room.

We separated what the interface displays from what the operator can prove. The visible label is useful for navigation, but it is not evidence of the underlying action. The reviewer should ask for a traceable source and write down the remaining uncertainty. If the source cannot be found, leave that uncertainty visible rather than filling the gap with a familiar-looking value from another workstream.

**Permissions exercise for Customer Complaint Themes — Q4 Review.** We walked through the document with a temporary contractor using a borrowed workstation. The reviewer started from the role attached to the signed-in account, then followed the work to the point where another person would rely on it. The awkward case was a shared terminal whose last user had broader access than the current operator. The discussion belongs with this document because the decision has to be intelligible to someone reading the note later, without the author in the room.

The walkthrough exposed a handover problem rather than a need for a new setting. The first person knew why the record looked unusual; the next person saw only the finished artifact. Add the explanation at the handover boundary and make its author visible. A private conversation can clarify the immediate case but cannot be the permanent place where the operating decision lives.



## DOC: Notes on the Warehouse Mezzanine Project

Not our team's work but we keep getting pulled into it.

The mezzanine build adds 4,000 square feet of pick space above the current staging area. Construction
starts in the summer. During construction, staging moves to the north dock, which means the manifest
generation timing shifts because the WMS pick wave finishes later.

Our ask: at least two weeks notice before the staging move so we can adjust the batch window. The current
02:15 start assumes the manifest lands by 01:45. If the pick wave finishes an hour later we need to move
the batch to 03:15 or accept that some nights it runs on a stale manifest.

Facilities has not confirmed a date.

---

### Operational review notebook

**Handover exercise for Notes on the Warehouse Mezzanine Project.** We walked through the document with a dispatcher covering another service area. The reviewer started from the visible assignment label and the signed handover note, then followed the work to the point where another person would rely on it. The awkward case was a vehicle swap that was discussed verbally but never written on the board. The discussion belongs with this document because the decision has to be intelligible to someone reading the note later, without the author in the room.

Keep the original artifact next to the amended one during review. A correction should say what the operator learned, who confirmed it, and which downstream view still needs to be refreshed. Replacing the artifact silently makes it impossible to distinguish a genuine repair from an accidental edit. The follow-up is to check a second example with a different history before treating the exercise as complete.

**Provenance exercise for Notes on the Warehouse Mezzanine Project.** We walked through the document with a warehouse supervisor comparing a printed checklist with the application. The reviewer started from the original loading sheet and the correction author, then followed the work to the point where another person would rely on it. The awkward case was a returned consignment carrying an old label from a previous journey. The discussion belongs with this document because the decision has to be intelligible to someone reading the note later, without the author in the room.

We separated what the interface displays from what the operator can prove. The visible label is useful for navigation, but it is not evidence of the underlying action. The reviewer should ask for a traceable source and write down the remaining uncertainty. If the source cannot be found, leave that uncertainty visible rather than filling the gap with a familiar-looking value from another workstream.

**Permissions exercise for Notes on the Warehouse Mezzanine Project.** We walked through the document with a temporary contractor using a borrowed workstation. The reviewer started from the role attached to the signed-in account, then followed the work to the point where another person would rely on it. The awkward case was a shared terminal whose last user had broader access than the current operator. The discussion belongs with this document because the decision has to be intelligible to someone reading the note later, without the author in the room.

The walkthrough exposed a handover problem rather than a need for a new setting. The first person knew why the record looked unusual; the next person saw only the finished artifact. Add the explanation at the handover boundary and make its author visible. A private conversation can clarify the immediate case but cannot be the permanent place where the operating decision lives.

**Exceptions exercise for Notes on the Warehouse Mezzanine Project.** We walked through the document with a depot lead investigating an incomplete delivery record. The reviewer started from the exception reason and the physical custody receipt, then followed the work to the point where another person would rely on it. The awkward case was a driver uploading a photograph after dispatch had already closed the shift. The discussion belongs with this document because the decision has to be intelligible to someone reading the note later, without the author in the room.

Use an example that has already completed its ordinary workflow when rehearsing this case. Do not repair a live record just to make a demonstration easier to follow. The exercise should preserve the confusing state, record the action taken, and show how a recipient can tell that the action finished. A clean screenshot alone is insufficient because it hides the transition that caused the confusion.



## DOC: Postgres Upgrade — Planning

Currently on 15. Want to be on 17 before end of year.

Blocking issues:

- The `pg_trgm` indexes on the address table will need rebuilding. On production volume that is roughly a
  40-minute operation, which exceeds our maintenance window.
- One query in the dispatch board relies on behaviour that changed in 16 around how `NULLS` ordering
  interacts with an index-only scan. It is not wrong in 17, it is just slower, and it needs an explicit
  `ORDER BY` clause added.
- The replica setup uses a replication slot configuration that will need to be recreated rather than
  migrated.

Plan is a blue-green with logical replication rather than an in-place upgrade. More setup, but the
rollback story is much better and we can cut over during a normal evening rather than a weekend.

---

### Operational review notebook

**Provenance exercise for Postgres Upgrade — Planning.** We walked through the document with a warehouse supervisor comparing a printed checklist with the application. The reviewer started from the original loading sheet and the correction author, then followed the work to the point where another person would rely on it. The awkward case was a returned consignment carrying an old label from a previous journey. The discussion belongs with this document because the decision has to be intelligible to someone reading the note later, without the author in the room.

We separated what the interface displays from what the operator can prove. The visible label is useful for navigation, but it is not evidence of the underlying action. The reviewer should ask for a traceable source and write down the remaining uncertainty. If the source cannot be found, leave that uncertainty visible rather than filling the gap with a familiar-looking value from another workstream.

**Permissions exercise for Postgres Upgrade — Planning.** We walked through the document with a temporary contractor using a borrowed workstation. The reviewer started from the role attached to the signed-in account, then followed the work to the point where another person would rely on it. The awkward case was a shared terminal whose last user had broader access than the current operator. The discussion belongs with this document because the decision has to be intelligible to someone reading the note later, without the author in the room.

The walkthrough exposed a handover problem rather than a need for a new setting. The first person knew why the record looked unusual; the next person saw only the finished artifact. Add the explanation at the handover boundary and make its author visible. A private conversation can clarify the immediate case but cannot be the permanent place where the operating decision lives.

**Exceptions exercise for Postgres Upgrade — Planning.** We walked through the document with a depot lead investigating an incomplete delivery record. The reviewer started from the exception reason and the physical custody receipt, then followed the work to the point where another person would rely on it. The awkward case was a driver uploading a photograph after dispatch had already closed the shift. The discussion belongs with this document because the decision has to be intelligible to someone reading the note later, without the author in the room.

Use an example that has already completed its ordinary workflow when rehearsing this case. Do not repair a live record just to make a demonstration easier to follow. The exercise should preserve the confusing state, record the action taken, and show how a recipient can tell that the action finished. A clean screenshot alone is insufficient because it hides the transition that caused the confusion.

**Rehearsal exercise for Postgres Upgrade — Planning.** We walked through the document with a trainer walking a new starter through a quiet-day exercise. The reviewer started from a synthetic consignment with clearly marked test addresses, then followed the work to the point where another person would rely on it. The awkward case was a training artifact accidentally left in the operational document folder. The discussion belongs with this document because the decision has to be intelligible to someone reading the note later, without the author in the room.

For the next review, ask a colleague outside this workstream to follow the written instructions without prompting. Note the point where they need information that is not on the page. That missing context is more useful than a general request to improve documentation. Revise the specific step and repeat the walkthrough with another ordinary example rather than expanding every paragraph equally.



## DOC: Random Scratch

todo
- ask facilities again about the mezzanine date
- the 2-opt iteration cap might be too conservative now that we moved to the bigger instances, test it
- someone should write down why we picked k-means over DBSCAN, nobody remembers
- new coffee order
- the thing with the invoices

---

### Operational review notebook

**Permissions exercise for Random Scratch.** We walked through the document with a temporary contractor using a borrowed workstation. The reviewer started from the role attached to the signed-in account, then followed the work to the point where another person would rely on it. The awkward case was a shared terminal whose last user had broader access than the current operator. The discussion belongs with this document because the decision has to be intelligible to someone reading the note later, without the author in the room.

The walkthrough exposed a handover problem rather than a need for a new setting. The first person knew why the record looked unusual; the next person saw only the finished artifact. Add the explanation at the handover boundary and make its author visible. A private conversation can clarify the immediate case but cannot be the permanent place where the operating decision lives.

**Exceptions exercise for Random Scratch.** We walked through the document with a depot lead investigating an incomplete delivery record. The reviewer started from the exception reason and the physical custody receipt, then followed the work to the point where another person would rely on it. The awkward case was a driver uploading a photograph after dispatch had already closed the shift. The discussion belongs with this document because the decision has to be intelligible to someone reading the note later, without the author in the room.

Use an example that has already completed its ordinary workflow when rehearsing this case. Do not repair a live record just to make a demonstration easier to follow. The exercise should preserve the confusing state, record the action taken, and show how a recipient can tell that the action finished. A clean screenshot alone is insufficient because it hides the transition that caused the confusion.

**Rehearsal exercise for Random Scratch.** We walked through the document with a trainer walking a new starter through a quiet-day exercise. The reviewer started from a synthetic consignment with clearly marked test addresses, then followed the work to the point where another person would rely on it. The awkward case was a training artifact accidentally left in the operational document folder. The discussion belongs with this document because the decision has to be intelligible to someone reading the note later, without the author in the room.

For the next review, ask a colleague outside this workstream to follow the written instructions without prompting. Note the point where they need information that is not on the page. That missing context is more useful than a general request to improve documentation. Revise the specific step and repeat the walkthrough with another ordinary example rather than expanding every paragraph equally.

**Archiving exercise for Random Scratch.** We walked through the document with a records clerk finding a superseded instruction. The reviewer started from the publication revision and named reviewer, then followed the work to the point where another person would rely on it. The awkward case was a local printout whose footer predates the current operating procedure. The discussion belongs with this document because the decision has to be intelligible to someone reading the note later, without the author in the room.

Retain the superseded wording in the revision history with a clear explanation of why it changed. We want people searching old discussions to understand whether they found an obsolete procedure or an unresolved proposal. Link the decision to its supporting artifact and keep draft material visibly marked until the responsible reviewer has accepted it.



## DOC: Security Review Findings — Internal

Conducted by the platform team, not an external audit.

**Finding 1 — Medium.** The SFTP stub credentials in the dev compose file are the same across all
developer machines and are committed to the repo. Low real risk since the stub holds no real data, but it
teaches a bad habit and one of those credentials was reused on a staging box.

**Finding 2 — Low.** The driver app stores the route payload unencrypted in local storage. It contains
customer addresses. On a lost phone with no device encryption this is exposure. Recommend encrypting at
rest using the platform keystore.

**Finding 3 — Medium.** The dispatch board websocket does not re-authenticate on reconnect. A token that
has been revoked continues to work for the life of the socket. Fix is to validate on each reconnect, which
is a small change nobody has made.

**Finding 4 — Informational.** Several API endpoints return more fields than the client uses, including
internal driver IDs. Not a vulnerability but unnecessary surface.

### Operational review notebook

**Exceptions exercise for Security Review Findings — Internal.** We walked through the document with a depot lead investigating an incomplete delivery record. The reviewer started from the exception reason and the physical custody receipt, then followed the work to the point where another person would rely on it. The awkward case was a driver uploading a photograph after dispatch had already closed the shift. The discussion belongs with this document because the decision has to be intelligible to someone reading the note later, without the author in the room.

Use an example that has already completed its ordinary workflow when rehearsing this case. Do not repair a live record just to make a demonstration easier to follow. The exercise should preserve the confusing state, record the action taken, and show how a recipient can tell that the action finished. A clean screenshot alone is insufficient because it hides the transition that caused the confusion.

**Rehearsal exercise for Security Review Findings — Internal.** We walked through the document with a trainer walking a new starter through a quiet-day exercise. The reviewer started from a synthetic consignment with clearly marked test addresses, then followed the work to the point where another person would rely on it. The awkward case was a training artifact accidentally left in the operational document folder. The discussion belongs with this document because the decision has to be intelligible to someone reading the note later, without the author in the room.

For the next review, ask a colleague outside this workstream to follow the written instructions without prompting. Note the point where they need information that is not on the page. That missing context is more useful than a general request to improve documentation. Revise the specific step and repeat the walkthrough with another ordinary example rather than expanding every paragraph equally.

**Archiving exercise for Security Review Findings — Internal.** We walked through the document with a records clerk finding a superseded instruction. The reviewer started from the publication revision and named reviewer, then followed the work to the point where another person would rely on it. The awkward case was a local printout whose footer predates the current operating procedure. The discussion belongs with this document because the decision has to be intelligible to someone reading the note later, without the author in the room.

Retain the superseded wording in the revision history with a clear explanation of why it changed. We want people searching old discussions to understand whether they found an obsolete procedure or an unresolved proposal. Link the decision to its supporting artifact and keep draft material visibly marked until the responsible reviewer has accepted it.

**Accessibility exercise for Security Review Findings — Internal.** We walked through the document with a colleague reading the board from the far side of the loading area. The reviewer started from the written status text alongside the coloured marker, then followed the work to the point where another person would rely on it. The awkward case was a status that can only be distinguished by colour in poor lighting. The discussion belongs with this document because the decision has to be intelligible to someone reading the note later, without the author in the room.

A useful completion check starts from the recipient perspective. Ask whether the recipient can identify the current artifact, understand the exception, and find the person responsible for resolving it. If any of those requires access to a private chat, the handover is still incomplete. The correction should improve that specific gap rather than add a broad assurance that the process is safe.



## DOC: Vehicle Inspection Records

Working note for the next operations review. This document concerns its named workstream; it does not revise settings in other documents.

### Operational review notebook

**Rehearsal exercise for Vehicle Inspection Records.** We walked through the document with a trainer walking a new starter through a quiet-day exercise. The reviewer started from a synthetic consignment with clearly marked test addresses, then followed the work to the point where another person would rely on it. The awkward case was a training artifact accidentally left in the operational document folder. The discussion belongs with this document because the decision has to be intelligible to someone reading the note later, without the author in the room.

For the next review, ask a colleague outside this workstream to follow the written instructions without prompting. Note the point where they need information that is not on the page. That missing context is more useful than a general request to improve documentation. Revise the specific step and repeat the walkthrough with another ordinary example rather than expanding every paragraph equally.

**Archiving exercise for Vehicle Inspection Records.** We walked through the document with a records clerk finding a superseded instruction. The reviewer started from the publication revision and named reviewer, then followed the work to the point where another person would rely on it. The awkward case was a local printout whose footer predates the current operating procedure. The discussion belongs with this document because the decision has to be intelligible to someone reading the note later, without the author in the room.

Retain the superseded wording in the revision history with a clear explanation of why it changed. We want people searching old discussions to understand whether they found an obsolete procedure or an unresolved proposal. Link the decision to its supporting artifact and keep draft material visibly marked until the responsible reviewer has accepted it.

**Accessibility exercise for Vehicle Inspection Records.** We walked through the document with a colleague reading the board from the far side of the loading area. The reviewer started from the written status text alongside the coloured marker, then followed the work to the point where another person would rely on it. The awkward case was a status that can only be distinguished by colour in poor lighting. The discussion belongs with this document because the decision has to be intelligible to someone reading the note later, without the author in the room.

A useful completion check starts from the recipient perspective. Ask whether the recipient can identify the current artifact, understand the exception, and find the person responsible for resolving it. If any of those requires access to a private chat, the handover is still incomplete. The correction should improve that specific gap rather than add a broad assurance that the process is safe.

**Review exercise for Vehicle Inspection Records.** We walked through the document with a service manager comparing two proposed process changes. The reviewer started from the observed operator action and the reason it failed, then followed the work to the point where another person would rely on it. The awkward case was a presentation showing fewer clicks while concealing additional manual work. The discussion belongs with this document because the decision has to be intelligible to someone reading the note later, without the author in the room.

We will evaluate the proposed revision using both an ordinary case and the awkward case from this exercise. Record the extra work done by the recipient as well as the work saved by the author. A local improvement is not a process improvement if it merely transfers effort to the next person. Keep the observations in this notebook so the eventual decision can be reviewed against what was actually demonstrated.



## DOC: Loading Bay Signage

Working note for the next operations review. This document concerns its named workstream; it does not revise settings in other documents.

### Operational review notebook

**Archiving exercise for Loading Bay Signage.** We walked through the document with a records clerk finding a superseded instruction. The reviewer started from the publication revision and named reviewer, then followed the work to the point where another person would rely on it. The awkward case was a local printout whose footer predates the current operating procedure. The discussion belongs with this document because the decision has to be intelligible to someone reading the note later, without the author in the room.

Retain the superseded wording in the revision history with a clear explanation of why it changed. We want people searching old discussions to understand whether they found an obsolete procedure or an unresolved proposal. Link the decision to its supporting artifact and keep draft material visibly marked until the responsible reviewer has accepted it.

**Accessibility exercise for Loading Bay Signage.** We walked through the document with a colleague reading the board from the far side of the loading area. The reviewer started from the written status text alongside the coloured marker, then followed the work to the point where another person would rely on it. The awkward case was a status that can only be distinguished by colour in poor lighting. The discussion belongs with this document because the decision has to be intelligible to someone reading the note later, without the author in the room.

A useful completion check starts from the recipient perspective. Ask whether the recipient can identify the current artifact, understand the exception, and find the person responsible for resolving it. If any of those requires access to a private chat, the handover is still incomplete. The correction should improve that specific gap rather than add a broad assurance that the process is safe.

**Review exercise for Loading Bay Signage.** We walked through the document with a service manager comparing two proposed process changes. The reviewer started from the observed operator action and the reason it failed, then followed the work to the point where another person would rely on it. The awkward case was a presentation showing fewer clicks while concealing additional manual work. The discussion belongs with this document because the decision has to be intelligible to someone reading the note later, without the author in the room.

We will evaluate the proposed revision using both an ordinary case and the awkward case from this exercise. Record the extra work done by the recipient as well as the work saved by the author. A local improvement is not a process improvement if it merely transfers effort to the next person. Keep the observations in this notebook so the eventual decision can be reviewed against what was actually demonstrated.

**Handover exercise for Loading Bay Signage.** We walked through the document with a dispatcher covering another service area. The reviewer started from the visible assignment label and the signed handover note, then followed the work to the point where another person would rely on it. The awkward case was a vehicle swap that was discussed verbally but never written on the board. The discussion belongs with this document because the decision has to be intelligible to someone reading the note later, without the author in the room.

Keep the original artifact next to the amended one during review. A correction should say what the operator learned, who confirmed it, and which downstream view still needs to be refreshed. Replacing the artifact silently makes it impossible to distinguish a genuine repair from an accidental edit. The follow-up is to check a second example with a different history before treating the exercise as complete.