Features, decisions, unknowns
A project is more than a task list. Features group work. Decisions record why something is the way it is — including what you do not know yet.
Open them from the project section nav, or from Documents → Decisions.
Features
Section titled “Features”A feature is a workstream on the project (a numbered slice of scope): “Checkout”, “Brand rollout”, “Phase 2 API.” Each one has a status: Active, Done, or Dropped — and a kind:
| Kind | Use it for |
|---|---|
| Scope | A slice of the solution — the default, and what existing features are |
| Outcome | Something that must be true in the world (“fans see match times without calling”) — carries acceptance criteria so done is checkable |
| Phase | A time-boxed grouping (“Phase 2”) |
- Open Features. The list starts on active workstreams; use the status filter to see done, dropped, or all, and the kind filter to see just outcomes.
- Add one, name it, optionally describe it. Mark it done or dropped when that slice of scope is finished or abandoned.
- Open a feature to see its tasks, decisions, and origin. Click a task to work on it. You can also pick the feature from a task drawer.
Progress on the project card averages completion across features, plus a bucket for tasks with no feature. Tasks that never get a feature still count — they just sit in that leftover bucket.
There is no separate “feature board.” The board is still tasks. Features are how you slice the engagement.
Decision Log
Section titled “Decision Log”Decisions are first-class, not comments you hope someone will find.
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 and reason; the ⋮ menu deletes.
When a decision settles (accepted, validated, wrong, superseded), InHive snapshots the whole plan and the card gains a v-chip — click it to see what that decision actually changed: tasks, features, and decisions spawned, changed, or dropped.
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.
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, aged with open tasks, hours already logged against a low-confidence call. It is not an AI “are we in trouble?” score.
Click the control to jump to those decisions. Paying them down — decide, 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 feature 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.