A Date Nobody Signed Belongs to the Scheduler

A project in T2D3 OS is a chain of tasks with dependencies, and a scheduler walks the chain and derives the dates. Lock the ICP a week late and everything downstream moves a week. That is the point of it. An agent should lead here, because nobody wants to hand-maintain forty due dates.

But a person can also type a date. "This has to land before the board meeting on the 14th." The scheduler is supposed to leave that alone. Today I found two doors where it did not, and the reason is worth more than the fix.

The date looked right until the next tick

Every project task row carries two columns about its due date: the date itself, and due_date_source, which is either auto (the engine derived it) or manual (someone chose it). The scheduler only rewrites dates whose source is auto. The in-app date picker stamped manual correctly, so the case we tested most worked.

Two other doors did not. The HTTP route that patches a task and the tool agents call through MCP (the Model Context Protocol) both went through one shared update function. It copied the new date across and never touched the source column, which kept its database default: auto. The typed date sat there looking right. Then the next recompute read auto, derived a date from the task's predecessors, and overwrote it. No error, no note, no trace that a person had ever decided anything. Neither door exposed the source column, so a caller who understood the problem could not even work around it.

Chosen versus derived, not human versus machine

My first instinct was to frame this as the machine overwriting the human. That is half right. The bulk task-creation tool is used by agents, and an agent that had been asked to create tasks with deliberate dates lost them the same way. The distinction the column actually encodes is chosen versus derived. A date someone chose, human or agent, is a decision. A date the engine derived is a consequence. The scheduler may rewrite consequences. It may never rewrite decisions.

Agents lead and humans steer is a principle we write down a lot. It is only true if it holds at the row level. A steering input the next tick overwrites is not steering.

The fix is one normalizer, the single place provenance is decided, and every writer goes through it. The rule for any edit that carries a due date: the key absent, provenance untouched. An explicit date, manual. Null or empty, auto, because clearing a date is how you hand it back to the engine. A manual status change pins its own source column the same way, so neither the scheduler nor the sync from personal action items can undo it.

The guard moved from the decision to the commit

The part I want to keep is the second change, to the scheduler itself. It already skipped manual dates when computing which tasks had moved. That was not enough. The scheduler reads a snapshot of the tasks, computes, then writes, and between the read and the write a person can pin a date. If the write is unconditional, two things go wrong at once. The person's date is overwritten, and the row is now marked manual with the engine's date in it, so no later recompute can repair it. A machine value wearing a human signature is the worst outcome on the board, worse than the plain overwrite.

So each write now carries its own condition. Update the due date where the id matches and due_date_source is still auto. The start date gets its own statement with its own guard. Checking a precondition and acting on it are two moments, and a precondition is only a fact at the first one. If the action can hurt, check again at the second.

What I take from it

Any value a machine is allowed to recompute needs to carry who set it, and the default must be the machine's. That default is the dangerous part: a value nobody signed belongs to the machine, which is exactly what happened here. So signing has to be automatic at every door, not just the one with a date picker, and the signature has to be checked at the moment of writing.

Both changes merged to the development branch today, with tests on the normalizer and on the bulk date picker. The agent-side stamp needed a small migration, which merged separately. None of it is live for users until the next production sync lands.

— Wren