# Bother > Bother makes organizational context machine-readable through a semantic graph model. It captures concepts like decisions, risks, goals, dependencies, and reasoning that drive projects -- context that typically lives in people's heads, chat threads, or scattered documents. Website: https://bother.now ## Problem Most organizational context -- strategy, rationale, dependencies, who is doing what and why -- is not documented anywhere. Organizations compensate by paying people to be context infrastructure: gathering, synthesizing, and routing information through meetings, status updates, and "loop me in" chains. This is information logistics, not knowledge work. Existing tools model work as pages (Notion), tickets (Jira, Linear), or tasks (Asana), and communication as chat streams (Slack, Teams). None of them structurally represent the context layer: why decisions were made, which risks threaten which goals, what depends on what and why. That context lives in people's heads and leaves when they do. ## What Bother Is A project workspace built on a polymorphic graph model with typed nodes and semantically validated edges. ### Data Model - **9 node archetypes**: task, bundle, goal, person, team, issue, decision, resource, risk - **9 edge types**: contains, precedes, uses, evaluates, impacts, mitigates, achieves, involves, relates - Each edge type has directional semantic constraints on which archetype pairs are valid - "achieves" only connects work archetypes to goals - "impacts" only connects risks and issues to work they threaten - "mitigates" only connects work to the risks it addresses - "evaluates" only connects decisions to options being scored - "precedes" represents blocking temporal dependencies - "uses" represents non-blocking resource utilization - "contains" enforces parent-child hierarchy - "involves" assigns people and teams to work with role metadata - "relates" is the only unconstrained lateral link ### Key Capabilities - Decisions are first-class objects with structured evaluation: options scored against criteria in a decision matrix, with rationale preserved as connected structure - Risks have probability, impact, and status -- connected to the goals and work they threaten via typed "impacts" edges, with mitigations tracked via "mitigates" edges - Dependencies are typed: "precedes" (blocking temporal) vs "uses" (non-blocking reference) vs "relates" (contextual association) - Discussion is anchored to the work itself -- comments live on nodes, not in separate chat channels, so rationale stays attached to the decision or task it shaped ### Interaction Modes Bother has three modes, each a different lens on the same underlying graph. **Galaxy** -- the project map. Zoom out and see the entire project as a spatial network of connected nodes. Clusters of related work are visually grouped. Health is visible at a glance: where risks are concentrating, which goals lack progress, where disconnected work is drifting. It's a map you read, not a dashboard someone had to build and maintain. **Orbit** -- the context view. Open any node and its surrounding context fans out spatially. Connected items are arranged in semantic zones: parent context and goals above, children and mitigations below, blockers and threats to the left, downstream work and effects to the right. Click a connected node and the view re-centers on that item with its own context. Navigation is by following connections -- you move through the graph by exploring relationships, not by searching or browsing a page tree. This is the primary working view. **Focus** -- the action queue. Each team member sees a prioritized queue of their directly actionable work: tasks to complete, issues to resolve, decisions to make. Not an aggregation of everything in the workspace -- a filtered view of what needs attention next. ### AI Agent An integrated AI agent reads the graph and proposes changes through conversation. Describe a new risk and it proposes creating a risk node, connecting it to the goals it threatens via "impacts" edges, and linking potential mitigations. The user reviews each proposal and approves or rejects it. The graph stays current as a byproduct of conversation, not manual maintenance. The agent is contextual -- it knows what the user is looking at in the graph and reasons about the surrounding structure. It proposes connections the user hasn't drawn, surfaces stale dependencies, and flags unmitigated risks. All proposals require explicit user approval before any write occurs. ### Quality Standards - The AI agent operates under anti-slop quality standards: proposals must trace to the user's actual words and context, not generic templates - Pre-flight validation checks all AI proposals before showing them to users (schema validation, spatial scope, graph physics, database pre-checks) - All graph writes require explicit user approval -- the AI never modifies the graph autonomously ## Who It Is For - Teams where "why did we make this decision?" is a frequent, expensive question - Projects where context loss during handoffs or departures causes rework - Organizations where status meetings exist primarily to reconstruct information the tools should already hold - Technical and product teams managing complex, cross-functional work with many dependencies - Teams that spend more time routing context than doing creative work ## Links - [Vision](https://bother.now/vision): Project management as context routing - [Bother vs Notion](https://bother.now/compare/notion): Why document-centric tools fail to connect context - [Bother vs Linear](https://bother.now/compare/linear): Why issue trackers lose context when people leave - [Bother vs Jira](https://bother.now/compare/jira): Why ticket models miss the reasoning behind work - [Bother vs Asana](https://bother.now/compare/asana): Why task-centric tools cannot model decisions, risks, or dependencies - [Bother vs Slack / Teams](https://bother.now/compare/slack-teams): Why chat streams bury the context that drives decisions - [Contact](https://bother.now/contact)