$ Pulse · Design Notes

The seeded technicians are deliberately patterned, not randomized: at least one consistently-strong performer, at least one with a specific recurring weakness, and the rest showing gradual improvement across their job history. Random data would produce a flat or noisy trend chart that proves nothing about whether the coaching mechanic actually surfaces something meaningful — a patterned dataset is what makes it possible to check, just by looking at a tech’s trend chart, that the improvement or weakness the seed data intended to show up actually does.

Coaching-tip generation is isolated behind a single generateCoachingTip(techStats) function boundary, rather than the canned-tip logic being spread across the request handler. That isolation is what makes swapping in a real Azure OpenAI call later a contained, one-file change — the request handler, the rate limiting, and the Cosmos DB write to coachingHistorystay exactly as they are; only what happens inside that one function changes. Design decisions get made once, up front, specifically so the mock isn’t a dead end.