Deliverables, goals, and decisions
A project can start with just tasks. Add deliverables to name what the team will provide, goals to explain what should improve for the client, and exclusions for work that is explicitly not included. Decisions record choices and their reasons, including questions that remain open.
Open Plan in the project navigation. Choose Deliverables for what you intend to hand over, Goals for the improvement the client wants, Decisions for the full log (and agent proposals), or Plan History for what changed. A status filter sits on Deliverables and Goals. On Deliverables, Cards and Timeline switch the same list: Timeline draws each included deliverable across dates. A start and a target date make a bar; a target date alone is a diamond. Dragging sets those dates and does not move tasks. Expand a row to see its tasks. Faint marks are earlier target dates. There is no whole-project / one-item selector. New decisions start as Proposed; choose another status when appropriate.
Start with a deliverable
Section titled “Start with a deliverable”For a clinic website redesign:
- Deliverable: Booking form — something to provide.
- Goal: Make booking an appointment easier — the improvement you want.
- A manager opens Plan → Deliverables → Add deliverable and enters a name. Nothing else is required.
- Expand More details (optional) to describe what is included, assign an owner, set a target date, optionally set an hour budget, and write Done when, for example “Works on mobile and sends a confirmation email.” Managers see logged hours versus that budget; a deliverable goes over when hours exceed the budget plus the hive’s tolerance (Settings → Hours & rates). Members never see the budget or the over state.
- Open a task and select Booking form as its Deliverable. Extra deliverables go under Also serves and do not count twice. A task can have no deliverable. From the task itself, Keep this as a deliverable does the same job when you already have the card: it creates the deliverable from the title and shows its description and Done when on every task linked to it. Start the next task adds another card on that deliverable without copying the comments.
- Deliverables sit in a card grid like projects. Each card shows a progress line when work is linked, then status, date, hours, and the owner’s face. Select a card (or its chevron) to expand it and read it. Only one card is open at a time; it takes as many grid cells as it needs and the others fill the remaining cells. Select a task to open its drawer. Status and due date sit on each task. Linked goals and interfaces are chips. Decisions and Origin are on the same card, behind those labels. To change the deliverable, open ⋮ and choose Edit — the same card becomes the editor.
- When the client takes the work, the owner or a manager chooses Accept. Leftover tasks do not have to be finished first. If the source was a meeting line, the row shows Provisional — confirm in writing until you link a written file (for example an email attachment) as confirmation. Managers can Revert acceptance with a reason; that does not delete the confirmation links.
- On the open card, Serves / Blocked by / Fits with are chips. After Edit, managers add with + or remove from the chip (the ⋮ menu still has Edit linked goals and Edit interfaces). Serves does not mark the goal achieved. If the other side later changes Done when or its target date, that change appears on this deliverable’s Plan History.
Deleting a deliverable or a goal from its menu moves it to the project’s Trash. Restore it from the project menu until the retention window removes it. 7. Choose Edit, then set Dropped or Excluded. Accepted is recorded only with Accept. After that the status control hides — use Revert acceptance if you need to change status again.
Add goal lives on Goals. To mark something out of scope, choose Edit on a deliverable and set Excluded. Neither is a required setup step. For goals, How will we know? records the evidence you intend to check, such as patients successfully booking during a usability test. This can be added later. Record evidence creates a validated or wrong decision. A goal shows Achieved only after that validated decision — completing linked work is not enough.
Goals have their own Plan tab. Each goal is the same kind of card: linked-work progress when supporting deliverables exist, a short checklist of those deliverables, then status, outcome, and the owner’s face. Each list starts on active items; use the status filter to find accepted, dropped, or excluded work. Not included lists exclusions. Other tasks keeps work without a deliverable visible. Existing items keep their links and numbers. Some other screens still use the older Feature label for these same items.
Retired phases
Section titled “Retired phases”Older projects may still have phases. They appear under Retired phases. Convert one to a deliverable, or delete it. New phases cannot be created. Grouping the plan by phase is gone; each task has one primary deliverable, so every count counts that task once.
With All statuses selected, managers can use Move up / Move down in an item’s menu. Deliverables, goals, and remaining phases each keep their own order.
Linked work: …% complete on a goal averages completion across supporting plan items. Finishing tasks does not prove the client got the intended improvement. Check the evidence in How will we know?.
The project card shows how many deliverables are accepted on top, and task completion under that. A project with no deliverables keeps a faded bar in that spot. Hold a bar and a honey drop names the count. The board remains a task workspace; a task does not need a deliverable.
Decision Log
Section titled “Decision Log”Decisions are first-class, not comments you hope someone will find.
A decision belongs to the project. Related to (optional) can stay Project-wide, or identify one main plan item. For example, “Use WordPress so staff can edit pages” can affect both the homepage and CMS setup. A deliverable is not required to record a decision; additional relationships live in Origin.
Record title, reason, alternatives, and evidence. “We don’t know yet” is a valid row. That is the point.
| Status | Use it when |
|---|---|
| Assumption | You are proceeding as if it were true |
| Unknown | You have not decided |
| Proposed | On the table, not accepted |
| Accepted | The hive is acting on it |
| Validated | Later evidence confirmed it |
| Wrong / superseded | It no longer holds |
On a wide screen the log is a split line: open, proposed, and rejected sit left of the history; accepted and validated sit right. Narrower screens keep every decision on one side of the line.
Open a decision to read the reason. Change status from the dropdown — it saves as you pick. Use the pencil to edit the title, why, and other fields; the ⋮ menu moves it to the project’s Trash. A Conflict badge means an agent write was flagged against that decision; a manager or the decision owner can dismiss it from the menu. The write itself was not blocked.
An assumption or unknown can name an internal owner and, when the project has a client, the person at the client who owes the answer. Resolve creates a learning-item task linked to that unknown so someone can close the gap. Open learning items show as chips that open the task.
When a decision settles (accepted, validated, wrong, superseded), InHive takes a checkpoint of the whole plan. The card’s v-chip opens its latest checkpoint comparison. This shows changes across the project since the previous checkpoint; they were not necessarily caused by that decision. Older checkpoints captured fewer details and comparisons say when coverage is partial. Feature membership changes use the names recorded at each checkpoint.
An accepted decision can become something agents treat as a rule. Do not mark a guess as accepted to make the list look tidy.
Propose from knowledge will only create decisions as assumption / unknown / proposed — never as accepted.
Plan History
Section titled “Plan History”Plan History records plan item and decision edits automatically, along with task creation and changes to task titles, acceptance criteria, and deliverable memberships. You do not need to write a separate changelog. Routine task progress and time tracking remain in Activity.
Use See how this evolved in an item’s details to jump here. Each change is a compact
row on a timeline: what kind of work it was, the title, a short action, the date, and
the person’s face. Open a row to see each field as before → after — the name already
on the row and the plan number are not repeated — then Open item to act on the
current work.
A task shared by two deliverables is still one task; membership changes appear under both the
deliverables it left and the deliverables it joined.
Origin today follows the current, permission-checked trail to decisions and the meeting, message, or comment behind the work. It may have changed since the historical entry. Compare saved plans provides the broader project comparisons.
Detailed history begins when this capability is installed. Earlier work remains in Activity and existing checkpoints. Entries are currently individual edits: approving a meeting’s proposals can produce several entries. Plan History omits tasks that are in Trash or have moved to another project. Deleting a feature or a decision still leaves a history entry. Deleting a goal does not.
Unknowns headline
Section titled “Unknowns headline”Open assumptions and unknowns show on the project top bar, with a debt level: none / watch / at risk / critical.
Scoring is rule-based: no owner, no learning item, aged with open tasks, hours already logged against a low-confidence call. It is not an AI “are we in trouble?” score.
Each open item offers Resolve. Paying them down — decide, create a learning item, or accept that it is still unknown and give it an owner — is how the hive stays honest.
Links and origin
Section titled “Links and origin”Objects can link to each other (blocks, implements, documents, discusses, …). Source links (a chat message, a transcript line, a comment) keep the words attached to the decision. When you approve a proposal pack that contains a decision, the work it spawns links itself to that decision — tasks implement it, the deliverable is related — so the trail exists from the first minute.
When someone asks “why is it like this?”, follow the trail rather than reconstructing from memory. On a task, that trail sits under Started from in the drawer. Ask cites those sources when they are in the knowledge base. From a chat line, meeting line, or comment you can create a task, deliverable, or decision and link it. Suggest with AI may preselect the kind and priority; you can change them, and you still press create.
Related
Section titled “Related”Changes reviewed together
Section titled “Changes reviewed together”A scope change approved from a meeting or assistant appears as one Change applied entry in Plan → Plan History. Expand it to see the new agreement and the exact changes to affected work. An earlier replaced decision stays in the record as superseded. Origin today follows the currently available source trail; it respects current project and source access. The final checkpoint includes the completed group. Existing individually recorded changes remain visible.