# Work Graph > A public source of truth for outcomes, dependencies, evidence, leases, and the human decisions that keep work moving - HTML version: https://robbiepalmer.me/projects/work-graph - Status: in_progress - Started: 2026-09-04 - Updated: 2026-09-18 - Source code: https://github.com/Robbie-Palmer/hq - Technologies: Cloudflare Access, Drizzle, Hono, Hyperdrive, OpenAPI, Spectral, oasdiff - Built on: Governance, Base, Backend API, Database, Infrastructure, Observability, TypeScript - Platform technologies: GitHub, Mise, TypeScript, Claude Code, Codex, CodeRabbit, Greptile, Agentic Code Review, GitHub Actions, Renovate, actionlint, zizmor, Trivy, OpenSSF Scorecard, Gitleaks, SonarQube, typos, Doppler, GitHub Secrets, pnpm, Vitest, Biome, Husky, Knip, CodeQL, Zod, Cloudflare Workers, Terraform, Terraform Cloud, TFLint, PostHog, PostgreSQL, Neon - Platform policies: Public source, AGPL-3.0, Shared personal-project monorepo - Ideas: Adaptive Planning (https://robbiepalmer.me/ideas/adaptive-planning.md), Directed Acyclic Graph (DAG) (https://robbiepalmer.me/ideas/directed-acyclic-graph.md), Epistemology (https://robbiepalmer.me/ideas/epistemology.md) # Vision Replace the project board as the primary model of work with a directed acyclic graph that people and agents can share. The graph should answer five questions: * What outcome matters most? * Which work is ready now? * What blocks the critical path? * Who currently holds each work item? * What evidence would prove it complete? The first user is me, across the projects in this repository. The first test is whether it can replace the mixture of Shortcut, GitHub, live agent sessions, and memory that currently holds the plan. # Problem Existing task tools assume people create, refine, assign, move, and close tickets. Agents make each of those actions cheap enough to flood the interface. A board full of generated prose can contain more information while making the actual state of delivery harder to understand. Much of that information should never require human attention. People care about priorities, product choices, risk, blocked outcomes, and whether the evidence is strong enough. They should not have to supervise every transition that leads there. A flat backlog also hides the important structure. Research may unlock a design decision. That decision may unlock two prototypes. Only one prototype may need to reach production before downstream tasks become useful. A visible DAG can show the critical path and the work that can safely run in parallel. # Approaches tried I have used Jira, Linear, GitHub Issues, GitHub Projects, Shortcut, Zen, CCPM, and extensions that try to add epics to simpler trackers. I have also watched teams fall back to local Markdown plans or keep the real execution plan in somebody's head. Simple Kanban boards, work-in-progress limits, lead time, flow, and team ownership have made teams much more productive in the past. Those principles still matter. The interface built around humans creating and moving every ticket does not survive agents producing and completing far more intermediate work. It becomes a sea of weakly written tickets which no person should need to read. Shortcut remains part of the current workflow, alongside GitHub issues, security notifications, Renovate pull requests, PostHog-created fixes, and live agent sessions. The Work Graph should absorb useful events from those systems without making any of them authoritative. # Responsibilities The public knowledge graph owns initiative and project prose and their long-lived relationships. Work Graph keeps operational mirrors of those scopes so they can carry operational stack rank without becoming a second prose source of truth. The Work Graph owns: * flexible work items, their parent-child hierarchy, and dependencies; * contextual initiative, project, and ticket stack ranks; * explicit, reason-bearing expedites; * owner-defined priority and policy; * optional briefs, acceptance criteria, context links, and completion evidence; * work state and the currently active lease; * blockers and attention requests; * plan revisions, including split, replacement, invalidation, and newly discovered work; and * projections for people, agents, and external tools. It does not choose the model, machine, subscription, or person that should do a work item. The [Agent Coordinator](/projects/agent-coordinator) owns that concern. # A constrained but adaptable graph Agents should be able to change the plan when execution teaches them something. They may split work that exceeds its intended scope, add a missing dependency, mark earlier work as invalid, or propose a different route to the outcome. Allowing arbitrary workflows invented during every session would make state hard to query and unsafe to automate. Owners should define which transitions, evidence requirements, and plan changes are allowed. Projects with low risk can grant broad authority. Production systems can require review at specific boundaries. # Adaptive planning The graph should support [adaptive planning](/ideas/adaptive-planning) towards a fixed goal. Expect the plan to be wrong and revise it as evidence arrives. Knowledge work changes what we know, including whether a planned item still helps reach that goal. [Epistemology](/ideas/epistemology) informs how we assess the evidence behind those decisions. Detail should follow evidence. Ready work needs a bounded scope and completion criteria. Work behind unresolved research or design decisions should remain provisional, with room to refactor, rescope, and reprioritise it. Downstream position often means more uncertainty, but graph depth alone cannot measure confidence. The graph should record the assumptions that make a branch useful and the evidence that could invalidate it. Only work in flight is committed. Regularly replenish and reprioritise the ready queue, then pull its highest-priority eligible item when capacity becomes available. Interrupting active work is expensive and needs a reason strong enough to justify the lost progress and context. A revision should identify the affected branch, retain its history, and explain the evidence behind the change. The graph should expose critical paths and opportunities to parallelise work, then help reduce lead times by removing waits and dependencies. Forecasting is outside its scope. It does not store estimates or predict delivery dates for queued or active work. Workers can report progress and blockers without turning either into a forecast. The Work Graph records those assumptions, commitments, and revisions. The [wider initiative](/initiatives/semi-autonomous-software-development#an-adaptive-model-of-the-organisation) owns the feedback loop that uses delivery evidence and available capacity to propose better plans. The Agent Coordinator continues to own actor selection. # Core model The first schema should stay small: * A **knowledge scope** mirrors an initiative or project and owns an ordinal position among scopes of the same kind while the knowledge graph remains authoritative for its meaning. * A **work item** is the only recursive unit of planned work. It may be childless, gain children during execution, or become executable again after its children terminate. Epic, task, and subtask are presentation labels. * A **dependency** determines when work becomes ready and exposes the critical path. Released and cancelled blockers both satisfy it. * A **lease** gives one actor temporary ownership without making abandoned work disappear. Its epoch fences requests from an actor whose stale lease was reclaimed. * **Context** links a work item to a knowledge scope, governing or background ADR, pull request, note, or supplemental reference without pretending those relationships have equal workflow meaning. * An **attention request** asks a person for a decision, authority, access, review, or help after the actor exhausts the allowed alternatives. Executability is derived. An open item is ready when it has no active lease, unresolved attention, unsatisfied dependency, or non-terminal direct child. Adding children to claimed work makes the parent wait. Once those children terminate, the parent can be claimed again for synthesis or completion. The system never terminates the parent automatically. Released work is successfully complete. Release is not a way to give up a lease or return unfinished work to the queue. For repository-backed work, the release transition requires evidence that the change was merged and deployed. A passing local build, a commit, or an open pull request does not qualify. The system needs a history of changes even if the main interface shows only current state. Otherwise an expired lease or rewritten plan can erase the context needed by the next actor. # Leases and handoff Only one actor should hold a work item at a time. A lease can be renewed while work continues and expires when an agent runs out of time, focus, or usage allowance. Expiry makes the item reclaimable. A monotonically increasing lease epoch prevents a delayed request from the previous worker changing it after takeover. A useful handoff should preserve findings, artifacts, attempts, unresolved problems, and the recommended next action. The exact contract should emerge from personal use rather than demand a long report for every small item. # Attention inbox The human interface should be an attention inbox, probably its own application. It should collect: * ambiguity that changes the product or plan; * missing authority, secrets, or access; * repeated technical failure after the actor has tried the allowed alternatives; * review or approval required by owner policy; and * discoveries that change scope or priority. Each item should include the decision needed, why it is needed now, options the actor considered, the affected critical path, and the consequence of waiting. A response should update the graph and allow eligible work to resume. The previous worker remains visible in lease history so a later scheduler can prefer continuity without reserving the work indefinitely. # Public work, private telemetry The work DAG should normally be public. Public work lets contributors and agents understand the same plan without translating it into a second tracker. Execution telemetry does not belong there. Token usage, model calls, retries, latency, private logs, and detailed cost data should flow to the data lake. The Work Graph can keep the evidence and summary needed to govern work without becoming an analytics warehouse. # Market test Linear has become the closest commercial competitor. Its [Agent platform](https://linear.app/docs/agents-in-linear) lets people delegate issues to installed agents, and its [coding sessions](https://linear.app/docs/coding-sessions) run Codex or Claude Code in managed cloud environments. Linear can carry issue history into the session, expose work through MCP, and return a pull request for review. Its coding environment currently belongs to one repository. [Linear's paid plans](https://linear.app/pricing) cost $10 per user per month for Basic and $16 for Business when billed yearly. Jira lists $7.91 per user per month for Standard and $14.54 for Premium on its [pricing page](https://www.atlassian.com/software/jira/pricing). This shows that teams pay for work coordination, but both products also have free plans that can serve the first users. Linear coding sessions add usage charges to the seat price. Model tokens pass through at the provider's published rate without markup, and each session costs $0.25 per 20-minute sandbox block. That is $0.75 per session-hour before tokens. Concurrent sessions each incur the charge. At launch, Linear granted eligible workspaces a shared pool of promotional AI credits equal to $20 multiplied by the number of unsuspended users. The grant does not recur monthly. The Work Graph should not exist merely because paid task trackers exist. It must beat Linear plus its MCP interface for my real workflow. Different people and agents should be able to find ready work, hold leases, change the plan within policy, and attach the evidence needed to close an item. The graph must also work across repositories and long-running environments without making one coding-session provider authoritative. Do not set a standalone price yet. First replace Shortcut and memory for one real project. For later users, ask whether the graph replaced a paid tracker, prevented them from buying one, or made the combined remote workspace worth more. Those behaviours support a price. A feature comparison does not. # First useful release 1. Model knowledge scopes, flexible work items, dependencies, leases, notes, attention requests, typed context, and an immutable event history. 2. Produce a deterministic ready queue globally and within an initiative, project, or parent item. Fuse contextual initiative, project, and ticket ranks, and propagate blocked descendant urgency to blockers. 3. Atomically claim the next eligible item or a chosen item, renew its lease, and reclaim it after expiry with fencing against the old worker. 4. Let a worker release, cancel, or decompose claimed work. Decomposition adds a child DAG and makes its ready leaves inherit the parent's priority position. 5. Expose the workflow through an unversioned REST API and installable TypeScript CLI. Keep MCP as a later adapter over the same application layer. 6. Attach initiative, project, ADR, pull-request, note, and reference context without demanding a long ticket template. 7. Deploy the service behind Cloudflare Access with service-token credentials for headless workers. 8. Enter the remaining Work Graph plan into the service and use it to complete its own MVP. # Later work * Analytics that find recurring waits, failed handoffs, and demands for human intervention * Automatic creation of infrastructure work when a repeated bottleneck has a credible systemic fix * Team ownership and multiple policy domains * Projections into GitHub, Shortcut, or chat where they help people work * A public DAG view and dedicated human attention inbox * MCP access after the CLI has proved the application operations * Automatic merge and deployment when required evidence and owner policy agree * Public contributor workflows for Open Collective Development # Success The Work Graph succeeds when the next useful item is visible without reconstructing the plan from tools scattered across the workflow, expired work can be resumed by another actor, and human attention goes to decisions rather than ticket administration. Learning should change the plan without causing constant disruption. Track avoidable interruptions and rework alongside progress towards outcomes, and check whether people can keep moving when downstream work is uncertain. # Non-goals * Scheduling models or managing their capacity * Storing private operational telemetry in the public graph * Arbitrary labels in place of fields with defined scheduling, workflow, or query meaning * Delivery forecasting and estimates * Automatically terminating a parent when its last child terminates * Asking owners or agents to calibrate a global numeric priority scale * Maximizing task throughput without regard for outcomes * Replacing owner judgment with one fixed risk policy ## Initiatives - [Semi-autonomous Software Development](https://robbiepalmer.me/initiatives/semi-autonomous-software-development.md): A connected system that keeps useful work moving, asks for human judgment when it matters, and learns how to need less intervention next time ## Architecture Decision Records - [ADR 000: Flexible work-item graph](https://robbiepalmer.me/projects/work-graph/adrs/000-flexible-work-item-graph.md) — Accepted, 2026-09-13 - [ADR 001: PostgreSQL coordination boundary](https://robbiepalmer.me/projects/work-graph/adrs/001-postgresql-coordination-boundary.md) — Accepted, 2026-09-13 - [ADR 002: Execution leases with fencing](https://robbiepalmer.me/projects/work-graph/adrs/002-leases-with-fencing.md) — Accepted, 2026-09-13 - [ADR 003: REST API and TypeScript CLI before MCP](https://robbiepalmer.me/projects/work-graph/adrs/003-rest-api-and-cli-first.md) — Accepted, 2026-09-13 - [ADR 004: Cloudflare Access service authentication](https://robbiepalmer.me/projects/work-graph/adrs/004-cloudflare-access-service-auth.md) — Accepted, 2026-09-13 - [ADR 005: Explicit work-item termination](https://robbiepalmer.me/projects/work-graph/adrs/005-explicit-work-item-termination.md) — Accepted, 2026-09-13 - [ADR 006: Contextual stack ranking and explicit expedites](https://robbiepalmer.me/projects/work-graph/adrs/006-contextual-stack-ranking.md) — Accepted, 2026-09-18 - [ADR 008: Make Work Graph the authoritative work system](https://robbiepalmer.me/projects/work-graph/adrs/008-authoritative-work-graph.md) — Proposed, 2026-09-19 --- Markdown index of this site: https://robbiepalmer.me/llms.txt