Every feature in Consequent is designed to eliminate ambiguity and promote shared understanding across your team.
Tasks don't have "start dates" — they have SNET dates
This fundamental shift means you should let tasks float freely in your schedule, only setting an SNET date when you have a specific reason to constrain the start time.
Key Principle:
By default, work begins as soon as dependencies are satisfied. SNET dates are explicit constraints, not implicit planning artifacts.
Tasks don't have "end dates" — they have FNLT dates
FNLT dates express deadlines and constraints without hiding the scheduling logic. Every task finishes when the work is complete, unless constrained.
Want to "pin" a date?
Set the SNET and FNLT to the same date. This makes your constraint explicit and auditable.
Start as soon as possible, unless constrained
Unless you insert an SNET date, every task in Consequent starts as soon as possible given its dependencies. This eliminates scheduling ambiguity.
Anything less is noise in 99% of cases
Our collective experience informs us that the hour is the right unit of measure for project tasks. Smaller units add complexity without value for the audience we serve. We enforce no fractions, no 1.999 hours, no 3.9999 days. Everything is x days and y hours.
For Instant Events:
Use milestones for "instant in time" tasks like permits, approvals, and go-live moments.
Simple, logical rules that eliminate opaque relationships
Task groups ("parents") can be predecessors for other tasks. All tasks in the group must complete before successors start.
Task groups ("parents") cannot be successors, either of tasks or other task groups. This would be opaque and unclear.
Individual tasks can be predecessors for or successors of other tasks. Simple and intuitive.
Why These Rules Matter
A logical implication of a task group having a Finish-to-Start constraint INTO it is that none of the tasks in the group can start before the predecessor ends. But that's opaque and easily modeled otherwise with much more clarity. The reverse is intuitive: a group as predecessor means all its tasks must complete before the successor starts.
A deliberate design choice
In practice, we observe that the same real-world situation is modeled in incompatible ways across different planners and teams:
Option 1
A single activity: "setting + curing"
Option 2
Activity + undocumented lag
Option 3 ✓
Two explicit activities: "setting" → "curing"
Why Remove Lag?
All three describe the same reality, but only (1) and (3) are explicit and communicable. Lag introduces a second, hidden language for expressing time, fragmenting shared understanding and making plans harder to read, explain, and lint.
By removing lag, we favor explicit temporal activities. This slightly increases verbosity, but improves clarity, auditability, and consistency across teams. To offset verbosity, Consequent provides strong visual grouping and compression, so explicit phases remain readable without hiding meaning.
If your use case demands lag, we support it
Just turn on "Allow Lag" in the settings.
Rare constraint types in traditional PM tools hide what's actually happening. Consequent maps these cleanly to visible, named milestones.
Visible on the Gantt
Milestones appear prominently, not buried in constraint dialogs
Can be named
"Permit issued", "Go-live allowed" — explicit and communicable
Participate in dependencies
Milestones work with the same dependency logic as tasks
Make schedule pressure explicit
Everyone can see critical moments in the timeline
Built for speed and global distribution
Ultra-fast Rust-based engine and WASM based UI amount to as-native performance.
Multiple edge deployments with independent databases.
See how Consequent's edge deployment architecture delivers low-latency performance across multiple regions with independent databases and automated failover.
See our InfrastructureWe're not revolutionizing project management. We're removing decades of accumulated ambiguity to reveal the clear principles underneath.