Daymark

A local-first day-planner that turns a goal into a workable set of next actions — and lets you reshape the plan in plain language, entirely on your own machine.

🔗 Live showcase: https://josephcintron.github.io/daymark/ · 📄 ML methodology & evaluation · ▶️ Runnable demo

AI-transparency note. Core architecture and logic designed by me; Anthropic's Claude was used for boilerplate generation and rapid prototyping during development.

This is a preview, not the product. Daymark's source is proprietary. This public repository is a curated showcase — documentation, diagrams, screenshots, a few simplified illustrative excerpts, and one runnable, dependency-free demo. The tuned application source is not published here.

---

What it does

• Capacity as a first-class idea. A day has a realistic number of minutes. Daymark models each day's capacity, infers task durations, and shows a day-meter that tells you when you've quietly overcommitted — not just what's due.
• Offline, no account, no telemetry. Everything runs on localhost. There is no hosted API and no data leaves the machine by default.
• Ask Daymark. A plain-language request — "move today's unfinished work to Friday" — becomes a constrained, previewable command plan, interpreted by a local model and shown to you before anything is applied.
• One-time onboarding, a replayable interactive tutorial, a month calendar with drag scheduling, bulk actions, Undo, recurring tasks, JSON import/export, and light/dark/system themes.

How it works

Daymark treats a language model as an untrusted proposal engine. Four layers, one direction of trust:

1. AI proposes. A local Ollama model turns a request into one JSON object over a closed vocabulary of actions, categories, priorities, and durations.
2. The validator disposes. Every response is strictly validated — server-side (Pydantic, extra="forbid") and mirrored in the browser — before it can cause any effect. Unknown fields, bad enums, out-of-range values, dangling references, no-ops, and contradictory actions are all rejected.
3. One validated mutation path. Every change — UI, keyboard, or AI — flows through a single operation layer that snapshots state for Undo before mutating. The AI layer gets no privileged access.
4. Capacity-aware planning + revision-aware sync. Durations and per-day capacity decide what fits; overflow reschedules lowest-priority-first. State reconciles across browser storage and an optional private folder by revision hash — conflicts ask, they never overwrite.

Full write-up: ARCHITECTURE.md.

Screenshots

Plan and complete work — filters, bulk selection, workload, and a rolling four-week plan.	Schedule visually — drag scheduling on desktop; a readable agenda on mobile.
First-run guide — turns a goal into starter actions.	Mobile — one consistent shell across desktop, tablet, and phone.

ML methodology & evaluation

The same discipline runs through the planner and the job engine. Three ideas:

1. Structured output over a closed schema. The model is always asked for a fixed JSON shape from a small, closed vocabulary, and every response is validated before it can act. See the runnable constrained-scoring demo.
2. Cheap-first inference funnels. Expensive model calls run only where they earn their cost. Fast regex pre-filters discard the majority of candidates for free so inference is spent only on plausible ones — the model decides what a human should look at.
3. Local, private, reproducible. Inference runs on-device via Ollama. The biggest driver of quality is the user-controlled profile/rubric — and it will inflate results if it overstates experience, stated plainly rather than hidden.

Honest small-n note. Choosing a local model is a latency–quality tradeoff, so it was measured, not assumed: an informal spot-check of a local model with reasoning off vs on (~4.7 s vs ~16.9 s per posting, same verdict on 3 of 4 test postings) is a spot-check, not a benchmark. Because the model's job is only to decide what to look at, the latency win was the right trade. The takeaway is the method — measure the tradeoff on your own hardware and task before committing. Full version: ml-methodology.html.

The job radar

Daymark grew out of a local job-scoring engine (kept as an optional module). It goes to the source — public, unauthenticated ATS APIs (Greenhouse, Lever, Ashby) rather than scraped mirrors — runs a cheap regex pre-filter, then scores the survivors with a local model into structured JSON (score, verdict, reasons, tailoring) against an editable, deliberately sceptical weighted rubric. One pass sees roughly ten thousand postings and keeps a few hundred.

Scope

This repository is a preview, not the product. It presents the project and the engineering: docs, diagrams, screenshots, simplified snippets/, and one runnable examples/ demo. The full, tuned application source is proprietary and is not published here.

Licensing

Proprietary — © 2026 Joseph Cintron. All rights reserved. See LICENSE. The snippets and demo are provided for review and evaluation only; no license to use, copy, modify, or distribute the source is granted.

About the author

Joseph Cintron — Computer Science senior (AI/ML concentration), with production experience building reliable automation and LLM-backed pipelines against messy real-world data. Daymark is designed and built end to end: the validated mutation architecture, the local-model command layer, and the evaluation methodology behind the job engine.

Contact

Reach me through my GitHub profile: @JosephCintron.