PEOS

IThe problem

Most productivity tools collect tasks. They do not reason about whether a plan is feasible, which commitments matter most, how missed work gets recovered, or whether a claimed completion deserves to be believed. They store intentions and then leave the hard part — deciding what actually gets done, this week, by you, with the time you actually have — to the person already holding everything else.

PEOS starts from a different premise: execution is a connected system, not a list of independent features. Priorities, deadlines, finite capacity, interruptions and evidence all have to agree with one another, because a plan that ignores any one of them is not a plan.

That is the framing. PEOS turns it into an execution system with explicit rules, boundaries and verification—not another list of intentions.

IIWhat it does

• Capture — Turns a rough intention into a structured task, asking for clarification only when the ambiguity would change the outcome.
• Prioritisation — Evaluates consequence, urgency, value, dependencies and opportunity cost against policy-defined factors, rather than a fixed list.
• Scheduling — Allocates work inside actual time and capacity constraints, and reasons about the latest safe start for a deadline-sensitive task.
• Intervention — Escalates when execution drifts, within explicitly configured authority boundaries.
• Verification — Associates a completion claim with evidence and transparent confidence, instead of treating every self-reported success as equally reliable.
• Recovery — Replans after disruption rather than indefinitely stacking unfinished work onto future days.
• Explainability — Shows why work was prioritised, scheduled, deferred or escalated.

IIIHow it is built

The system is a Next.js and TypeScript application inside a multi-package monorepo, with PostgreSQL for persistence and background execution for the work that has to keep running between sessions. The architecture separates scheduling, verification, interventions and recovery into defined packages, rather than growing one service that accumulates every responsibility at once.

The governing principle is a hard boundary between proposal and decision. AI may propose. Deterministic engines decide. A model can draft a plan, reorder a queue or suggest a recovery sequence, but the engines that decide priority, capacity and completion are deterministic and testable. Evidence is a third, separate concern again: what may be claimed is settled by the evidence attached to a claim, never by the confidence of the text asserting it.

Every consequential decision is expected to be inspectable. Priority, schedule, deferral and escalation each carry the reasoning that produced them, so a plan can be argued with rather than merely obeyed.

IVThe evidence

The repository carries extensive product specifications, a multi-package implementation and automated acceptance tests, including a real-browser journey that exercises the product the way a person meets it rather than as a set of units.

A baseline dated 1 October 2026 recorded 926 selected tests passing, alongside two database smoke checks. That is a real figure with a real date, and it is scoped: it describes that selection of tests on that date. It is not a standing claim about the current revision of the repository.

PEOS is a built, founder-led application with substantial architecture, specification, implementation and acceptance-verification work behind it. Manual acceptance testing is pending.

VMy role

I set the product vision, decomposed the system, chose the architecture and its operating invariants, and wrote the implementation specifications. Implementation was then carried out through coding agents against those specifications, and I coordinated that work — the aim being a system built to a stated architecture, rather than one assembled opportunistically.

Verification was mine as well. I defined the adversarial review process and the acceptance-verification strategy: what had to be demonstrated, in a real browser, before a capability could be called working. The code is largely model-generated from specifications I wrote and reviewed; the architecture, the boundaries and the standard of proof are decisions I made.