The model
Six objects, and one rule about who owns what.
Most trackers have one object called a task and a field called assignee. That is the shortcut that makes them lie about status. Onerity splits the model where the reality splits.
- Accounts
- The root object, not the project. Projects end; the account history is what matters at renewal. Everything else hangs off an account.
- Workstreams
- A bounded piece of work for one account — a launch, a readiness push, a renewal. An account can run several at once, and each carries its own sequence and dates.
- Playbooks
- A reusable template of steps, each with an offset in days from the start date and a side that owns it. Instantiating one generates a dated sequence for a new client.
- Typed actions
- Work you own. Every action has a kind drawn from a vocabulary you extend — meetings, deliverables, setup, execution — so the tracker can say what the work actually is rather than holding a wall of free text.
- Blockers
- Work someone else owns. A separate object, because merging it into tasks destroys the one thing this tool does better than memory: knowing what is stuck on somebody you do not manage. A blocker has an owner on their side, the deadline it endangers, and a chase clock — and a lifecycle that starts at not yet asked.
- Meeting ingestion
- Paste a transcript. Onerity proposes creates, updates and completions, each carrying a verbatim quote and the speaker. The quote is checked mechanically against the transcript you submitted, so an invented one cannot get through. A human accepts or rejects every item; there is no auto-apply.
Blockers
“Not yet asked” is a state, and it is the one everybody skips.
A tracker that treats waiting as a status on a task has to answer an impossible question: is this late? If the client has not replied, the tool says overdue and you learn to ignore it. If it stays quiet, the launch date arrives anyway.
Separating the object lets each state mean something. Nothing is outstanding with the client until you have actually asked — before that, it is your move, and it appears in your list rather than theirs. Once asked, the clock is theirs, and what it counts against is the business date at risk rather than an arbitrary task deadline.
Ingestion
Your calls do the data entry, and you keep the final say.
The reason trackers go stale is not that people are lazy. It is that updating one is a second job performed after the conversation that produced the update. So the update happens on Friday, from memory, badly.
Paste the transcript instead. What comes back is a queue of proposals, not a set of changes — each one carrying the sentence that justifies it and the name of whoever said it, so reviewing is reading rather than trusting.
What the AI is allowed to do
Three limits, and they are structural rather than settings.
- It never writes to your data. Every derived change lands in a review queue and is applied by a person.
- Every proposal carries evidence. An item whose quote does not appear in the transcript you submitted is discarded before you ever see it.
- Model confidence sorts the queue. It never authorises anything.
These are properties of how the system is built, not toggles in a settings page. There is no configuration that grants the model write access, because the write path does not accept one.