The daily priority list.
“Your six items that are blocking other people.” Which is a different list from your six oldest items, and it is the one that should be read first.
Zepth Core · Task Management
Tasks & Cross-Module Tracking
A task divorced from its record decays. A task born from the record closes into it.
Last updated
Zepth Core module
Tasks & Cross-Module Tracking
AI agent built into the module
Tasks born from recordsBall-in-court ownershipOne list per person, across modulesReassignment with a trail
Overview
Tasks are the connective tissue of a project: the assigned, dated, owned to-dos that spill out of meetings, inspections, RFIs and reviews.
What makes them different from a to-do app is context. Every task carries the record it came from — the NCR it closes, the RFI it chases, the meeting action it discharges — and every module’s open items roll up into one accountable list per person. Not one list per module, which is how work gets lost between systems that are each individually fine.
Context is the whole difference
“Chase the thing” is a task that will decay. It has no evidence attached, no definition of done, and no way to prove it happened — so in three weeks it is either forgotten or it is a source of an argument, and quite often both.
A task born from a record is a different object. It knows which NCR it is closing, which submittal it is chasing, which meeting item it discharges. It carries the evidence into the conversation, and when it closes, it closes INTO the record — so the NCR shows the action that resolved it rather than pointing at a task-management system that somebody would have to go and look at.
That is not a feature. It is the reason project to-dos behave differently from personal ones: on a project, the task and the record are the same fact viewed from two angles, and any system that separates them has created a gap and then asked people to remember to bridge it.
Ball-in-court, and ageing by owner
At any given moment, every open item has exactly one owner. Not two, not a department, not “being looked at”. One person, in whose court the ball currently sits.
And “with the consultant” is a STATUS, not an excuse. It tells you where the ball is; it does not tell you that nothing can be done. Somebody still owns chasing it, and that somebody is on your side of the fence.
Which makes ageing-by-owner the accountability lens that actually works. Not ageing by module — because the person carrying eleven overdue items across five modules looks fine in all five. One list per person, across everything, read oldest-first. That is the weekly review, and it is uncomfortable in exactly the way a weekly review should be.
And nothing should die with its owner
People go on leave. People resign. Reassignment with a trail — so the task moves, keeps its history, and does not quietly vanish along with the mailbox — is the same doctrine that governs project correspondence, and it fails the same way when it is absent.
The test is simple: if a project engineer left tomorrow, would anybody know what they were carrying? On most projects the honest answer is no, and it is no because the answer lived in their inbox and their memory, in that order.
The value
Why it matters
Tasks carry their evidence, so “chase the thing” stops being a category of work.
Every open item has exactly one owner — and “with the consultant” is a status rather than an excuse.
One accountable list per person, across every module, so nobody looks fine in five places at once.
Work survives leave, turnover and resignation, because it was never living in a mailbox.
Capabilities
What you can do
01
Tasks born from records
From meeting actions, inspection failures and due responses — carrying the context they came from, and closing back into it.
02
Ball-in-court ownership
Exactly one owner at any moment. “With the consultant” tells you where the ball is; somebody still owns chasing it.
03
One list per person, across modules
The only view that catches the person carrying eleven overdue items spread thinly across five systems.
04
Reassignment with a trail
Leave, turnover, resignation. Nothing should die with its owner, and on most projects a great deal does.
The workflow
How it actually runs
- 1
Let tasks be born from the record
A meeting action, a failed inspection item, a due response. Raised automatically, carrying their context — rather than re-typed into a separate system by somebody who will summarise them badly.
- 2
Owner and date, mandatory
A person, never a department. A department cannot be asked why an item is sixty days old, and cannot explain itself.
- 3
Age and escalate by rule
Read the list oldest-first, by owner, across every module. The person with eleven overdue items across five modules looks fine in all five of them.
- 4
Close into the originating record
The NCR shows the action that resolved it. Otherwise the record points at a task system, and the task system points back, and neither is the answer.
AI that does the work
How AI changes Tasks & Cross-Module Tracking management.
Ageing clusters by owner.
The person quietly accumulating overdue work across five modules — invisible in each of them, and unmistakable when the lists are added together.
Tasks converted from records automatically.
Meeting actions, failed inspection items and due responses become tracked tasks with their context attached — rather than being re-typed by somebody who will paraphrase them.
The engineer’s judgment stays in charge; the AI removes the latency and the blind spots.
Best practices
- Never raise a bare task. A to-do with no record behind it has no evidence, no definition of done, and no way to prove it happened — and it will produce an argument in three weeks.
- Review ageing by owner, not by module. Someone carrying eleven overdue items across five modules is invisible in every one of them, and visible immediately in a single list.
- Treat “with the consultant” as a status. It says where the ball is. It does not say that nobody on your side owns chasing it, because somebody does.
- Reassign with a trail before people leave, not after. The question “what were they carrying?” has an honest answer on very few projects.
Dashboards & reporting
One list per person, across every module, read by age. Ball-in-court status on every open item, with exactly one owner. Ageing clusters by owner rather than by module — because the module view is what hides them. And closure back into the originating record, so the NCR shows the action that resolved it rather than a cross-reference to somewhere else.
Live dashboards
Drill-down & filters
Export to Excel / PDF
FAQ
Common questions
What is different about tasks in a project record versus a to-do app?
Context. A to-do app holds “chase the thing” — no evidence, no definition of done, no proof it happened. A project task knows which NCR it closes, which submittal it chases, which meeting action it discharges. It carries the evidence with it and closes back into the record, so the NCR shows what resolved it. On a project, the task and the record are the same fact seen from two angles, and separating them creates a gap that people are then asked to remember to bridge.
What is ball-in-court?
The discipline that at any moment, every open item has exactly one owner — the person in whose court the ball currently sits. Not two people, not a department, not “being looked at”. And “with the consultant” is a status, not an excuse: it tells you where the ball is, and somebody on your side still owns chasing it.
Read the full answerHow should task ageing be reviewed?
By owner, oldest-first, across every module at once — never module by module. The person carrying eleven overdue items spread across five modules is invisible in all five and unmistakable in a single combined list. That is the whole reason to combine them, and it is why the weekly review is uncomfortable in the way it ought to be.
Read the full answerWhat happens to tasks when someone leaves?
On most projects, they vanish — because they lived in an inbox and a memory, in that order. Reassignment with a trail, so the task moves and keeps its history, is the same doctrine that governs project correspondence, and it fails identically when it is missing. The honest test: if a project engineer resigned tomorrow, would anybody know what they were carrying?
Sources
- Ball-in-court is a construction-administration convention, not a standard. We describe it as the convention it is.
- This page carries no stat band. There is no defensible published benchmark for task-completion discipline, and inventing one on a page whose entire argument is accountability would be a poor joke.
Related modules
Related answers
Terms defined here
Zepth is the construction project delivery platform — it runs construction, procurement and asset management on one record, and does the work: reading the drawings, reviewing the submittals, matching the invoices and flagging the risks, with a human sign-off on anything consequential.
See it on your project.
A short, tailored walkthrough on your real workflow — no generic demo.