Open any mainstream to-do app — Todoist, Things 3, Microsoft To Do, even a bare Notion page — and complete a task. What happens? The item moves to a "Done" list, or it vanishes entirely. Maybe there's a tiny timestamp. Maybe there's a strikethrough. That's the entire historical record: this thing existed, and then someone tapped a checkbox.

For knowledge workers who track groceries and dentist appointments, this is fine. For a construction superintendent managing 400 commissioning tasks across a $2 billion hospital build, it's a liability.

We built Oestler's to-do list because no existing task manager answers the questions that actually matter in high-stakes environments: Who changed this? When? Why? What did it say before they changed it? And can we prove it?

The Accountability Gap in Task Management

Consider a scenario that plays out on every major construction project. A commissioning engineer marks a fire damper inspection as complete. Three months later, during a defects liability audit, the building owner's team asks: "Who signed off on Level 7 fire dampers, and was the original scope the same as what was actually inspected?"

In a conventional task manager, you can answer the first question — if you're lucky. The second question is unanswerable. If the task text was edited between creation and completion, that edit is invisible. The original scope is gone. The chain of custody is broken.

This isn't a hypothetical. It's the reason construction firms still maintain parallel paper-based tracking systems alongside their digital tools. They don't trust the digital record to be complete.

A task manager that can't tell you what a task said before it was edited is a task manager that can't be trusted in a disputes process. In construction, that's most of them.

Every State Change Is an Event

In Oestler, a task isn't a row in a database. It's an event stream. Every mutation — creation, completion, disregard, restoration, edit, refinement, split, merge, move, revert — is recorded as an immutable history entry with five mandatory fields:

  • Who — the user's name, email, and profile photo at the time of the action
  • When — a server-authoritative timestamp (not the client's local clock)
  • What — the event type and all associated data (previous text, new text, comment, linked IDs)
  • Document Control status — whether the action was performed under controlled or uncontrolled conditions
  • Why — an optional comment field that's prompted on every completion, disregard, and restoration

Open any task's info panel and you see its entire life story, oldest event at the top, newest at the bottom. Not a log file buried in an admin console. A clean, visual timeline that anyone on the project can read.

Eleven Event Types, Each With Purpose

Most task tools recognise two states: open and closed. Oestler tracks eleven distinct event types, each carrying different data payloads and different implications for the audit trail:

Created — the task enters the system. The original text is locked into the history. Even if someone edits it thirty seconds later, the creation record preserves what was originally written.

Completed — the task is marked done. A comment prompt appears: "What was the outcome?" This isn't mandatory, but the prompt exists because construction completion often carries nuance — "Completed, pending final coat" is fundamentally different from "Completed."

Disregarded — the task is intentionally set aside. A comment prompt asks why. Disregard isn't deletion — it's a conscious decision to not do something, and that decision is recorded. In a dispute, being able to show that a scope item was deliberately disregarded (with rationale) is worth orders of magnitude more than a missing record.

Restored — a completed or disregarded task is returned to pending. The audit trail shows who restored it and why. This creates a visible record of changed minds and reassessments — information that's invisible in systems without bidirectional state flow.

Edited — the task text is changed. The history stores both the previous and new text. You can see exactly what changed and who changed it.

Refined — Janus AI suggested a rewrite of the task, and the user accepted it. The history records both the original and the AI-refined text. This is critical: AI modifications are never silent. Every AI touch leaves a fingerprint in the audit trail.

Split — a single task was broken into multiple child tasks. The history records the child task IDs and any comment explaining the split rationale.

Split-from — this task was created as the result of a split. The history links back to the parent task and preserves the parent's original text.

Merged — this task was consumed by a merge operation. The history records which task it was merged into.

Merged-from — this task was created as the result of a merge. The history lists every source task that was combined, preserving full lineage.

Moved — the task was transferred from one list to another. The history records the source list, the destination list, and who performed the move. When a commissioning task moves from "Electrical — Level 3" to "Defects — Electrical," that transition is recorded, not guessed at.

Reverted — the task was rolled back to an earlier point in its history. The audit trail records the revert target, the previous text and status, and the restored text and status. This means you can revert a revert — the system is non-destructive all the way down.

Revert: Time Travel Without Risk

Most task managers handle mistakes the same way: delete the wrong thing, create a new thing, hope nobody notices. Oestler takes a fundamentally different approach. Every historical state is a revert point.

Open a task's history, find the state you want to restore, and click Revert. The task's text and status are restored to that exact point. The revert itself is recorded as a new history event — so you have a complete record of the original state, every change in between, and the decision to roll back.

For the most recent state change (a completion or disregard), the UI offers an "Undo" shortcut. This is the same mechanism — a revert to the immediately preceding state — but surfaced as a one-click action for the common case of "I just marked the wrong thing as done."

What makes this architecturally different from a simple undo stack is that reverts are non-destructive and non-sequential. You can revert to any historical point, not just the previous one. The intermediate history isn't lost. And the revert target is recorded by reference — it points to the specific timestamp and state being restored, so the chain of reasoning is always auditable.

AI With Visible Fingerprints

Janus AI integrates into the task list at four points: refine, suggest, split, and merge. In every case, the AI's intervention is explicitly recorded in the task history.

When Janus refines a task — say, rewriting "check pumps" to "Verify fire pump P-07A isolation valve positions and confirm standby mode indicators per Section 21.3.2" — the history shows a "Refined" entry with the original and AI-generated text, attributed to the user who accepted the refinement. There is no scenario in which AI-modified text appears without a visible record.

When Janus suggests new tasks, each suggestion carries two history entries: a "Created" event attributed to Janus, and a "Janus Suggestion" event recording the suggested text. The distinction matters: the system is transparent about who originated the idea and what the original suggestion said, even if the user edits it afterward.

This design decision is deliberate. In regulated industries — and construction is heavily regulated — AI-generated content needs to be traceable. When an auditor asks "Was this scope item written by a human or generated by AI?", Oestler can answer definitively, with timestamps and attribution, for every task in the system.

In a world where AI is quietly rewriting task descriptions behind the scenes, Oestler takes the opposite position: every AI touch is visible, attributed, and auditable. No silent edits. No invisible rewrites. No ghost in the machine.

Shared Lists: Collaboration Without Ambiguity

Private to-do lists are essential for individual focus. But construction is fundamentally collaborative — a commissioning checklist doesn't belong to one person, and a defect resolution list has three parties touching every item.

Shared Lists in Oestler work identically to private lists. Every feature described above — the eleven event types, the full audit trail, the revert system, AI refinement — applies equally. The difference is access: you invite colleagues by email, and they see the same list in real time.

When multiple people operate on the same list, the audit trail becomes more valuable, not less. You can see that Alice created the task, Bob edited it, Janus refined it, and Carol completed it — each action timestamped, each transition recorded. This is the kind of accountability that construction contracts demand and that most digital tools can't provide.

Move a task between lists — from your private list to a shared commissioning checklist, or from one shared list to another — and the transfer is recorded as a "Moved" event on the task. The task doesn't lose its history. It carries its entire lineage with it.

Daily Summaries: AI-Generated Memory

At the end of each day, Oestler's AI reviews the tasks you completed and generates a concise natural-language summary. "Closed out Level 3 fire damper inspections, resolved the chiller isolation valve discrepancy from last week, and disregarded the temporary power audit after confirming it was transferred to the electrical contractor."

These summaries are stored per-list and per-day. They feed into Janus's persistent memory system, which means that weeks later, when you ask "What did I do on the 14th?", the AI has a factual, structured answer — not a hallucination, but a summary grounded in actual task completions.

Users control which lists contribute to AI memory. Your private task list might feed into memory by default, but a shared procurement checklist might not — that's your call, configurable in the Prompts settings.

Delete With Intent

List deletion in Oestler requires solving a randomly generated division problem. This isn't whimsy — it's a deliberate friction mechanism. Deleting a list destroys every task and its associated history permanently. A simple "Are you sure?" modal is insufficient for an action with that level of consequence.

The division challenge (e.g., "What is 144 ÷ 12?") forces a momentary cognitive pause. It's long enough to prevent accidental clicks and fat-finger deletions, short enough to not be genuinely annoying. The principle is borrowed from infrastructure engineering itself: high-consequence actions should require deliberate intent, not reflexive confirmation.

The Architecture Beneath

Every task is a Firestore document with a history array. Each entry in the array is a self-contained event object: type, user ID, user name, user email, user photo, timestamp, document control status, and an extensible payload of type-specific fields (comment, previousText, newText, splitIntoIds, sourceIds, fromListName, toListName, and so on).

This is an append-only structure. History entries are never modified or deleted — only appended. The revert mechanism works by reading a historical state and appending a new "reverted" event that records the transition. The original events remain intact.

The practical consequence is that an Oestler task history is a legally defensible record. Every state is independently verifiable. Every transition has attribution. The ordering is enforced by server timestamps. And the data structure is simple enough that it can be exported, queried, and presented in a disputes process without requiring specialised tooling to interpret.

Who This Is For

Oestler's to-do list isn't for everyone. If you need a quick grocery list or a Pomodoro timer, there are better tools. It's built for environments where:

  • Tasks represent real-world actions with contractual or regulatory implications
  • Multiple people touch the same scope items over weeks or months
  • The question "Who decided to change this, and when?" needs a definitive answer
  • AI-assisted task management is valuable but AI transparency is non-negotiable
  • Historical accuracy matters more than feature count

That description covers most of the construction industry, a fair amount of engineering, and any regulated environment where work packages are tracked as discrete items with audit requirements.

It's a to-do list. But it's a to-do list that remembers everything, attributes every change, and can prove it.