Method, not magic
Daymark treats a language model as an untrusted proposal engine. The model suggests; deterministic code decides. Here is how that discipline is enforced — and how the tradeoffs were actually measured.
The same discipline runs through the task planner and the job-scoring engine.
Every model call asks for a fixed JSON shape drawn from a small, closed vocabulary — a bounded set of actions, categories, priorities, and numeric ranges. Nothing free-form reaches application state.
Each response is strictly validated before it can cause any effect:
unknown fields, out-of-range values, bad enums, and dangling task or day references are
all rejected. In the task planner the contract is enforced twice — a strict Pydantic
schema on the server (extra = "forbid") and a mirror validator in the browser
that also refuses no-ops and contradictory actions, then shows a preview before anything
is applied. See the runnable constrained-scoring demo.
Expensive inference runs only on plausible candidates. In the job engine, fast regex pre-filters discard obvious non-matches for free, and a cheap heuristic ranks the survivors so the scoring budget is spent on the most promising postings first. The model's job is to decide what a human should look at — not to read everything.
Inference runs on-device via Ollama; no data leaves the machine by default. The single biggest driver of output quality is the user-controlled profile/rubric — and it will inflate results if it overstates experience. That failure mode is stated plainly in the rubric rather than hidden, because an inflated score quietly wastes the scarcest resource: application time.
Fetch from the source, filter cheaply, score under a contract, validate, rank.
Choosing a local model is a latency–quality tradeoff, so it should be measured rather than assumed. The measurement here was an informal spot-check, and it is labelled as one — not a benchmark.
| Configuration | Latency / posting | Agreement on 4 test postings |
|---|---|---|
| Local model, reasoning off | ~4.7 s | 3 of 4 matched the reasoning-on verdict |
| Local model, reasoning on | ~16.9 s | reference |
Because the model's role is only to decide what to look at — a human still reads every shortlisted posting before applying — the ~3.5× latency win was the right trade for a one-verdict-in-four disagreement on a tiny sample. The point is not the numbers, which are too small to generalize. The point is the method: measure the tradeoff on your own hardware and your own task before committing to a model, and keep the human in the loop where the sample is too small to trust.