
The Central Task Database is the architectural foundation of Hoylu V4. It exists to solve a problem that comes up on any project with more than one planning view: How do you show the same work in multiple places without duplicating it and without losing a single, reliable source of truth for what's actually planned and completed? V4's answer is to store every Task, Milestone, and Constraint in one shared database owned by the Project itself, rather than by any individual Workspace.
In practice, a Project is the top-level container that owns the Task database along with shared settings like Teams, Labels, and Calendars, and it can contain any number of Workspaces, each showing a different slice of the same underlying data. What appears on a Workspace is a Task Card — a visual representation of a Task, Milestone, or Constraint record — and the same record can have cards in multiple Workspaces at once without being duplicated. Tasks enter the database either by being created directly on a Workspace or by converting whiteboard notes into live records. From there, they can be pulled onto a Workspace through the import dialog, filtered by team, label, or date range, or organized into a Plan, where Swimlanes are linked to a real data field on the Task — such as team or label category — rather than to whiteboard position.

The practical effect is that every view stays current automatically: a status update made through a card in one Workspace writes to the same Project-level record and are reflected everywhere that Task, Milestone, or Constraint has a card, with no manual sync step. This also makes two related actions easy to keep straight: ejecting a card removes it from a Workspace without touching the underlying record or its presence elsewhere, while deleting a Task removes it from the Project entirely and flags every card for it across every Workspace. Because the data lives at the Project level rather than inside any single Workspace or Plan, teams can build focused views, run temporary planning sessions, or restructure a Plan's Swimlanes without ever risking the integrity of the source data itself.
Comments
0 comments
Article is closed for comments.