Orbit
lockedThe architectural metaphor. The concern is the centre; everything else orbits around it.
Definition
Orbit is the architectural model for Hearth.
The concern sits at the centre. Around it orbit every capability the concern may use: people, lifecycle, workflow, documents, communications, data, AI assistance, integrations, audit trail.
Workflow is important, but it is not the centre. It is one capability among many that the concern may use.
Orbit explains the architecture. hearth names the human place where the work happens.
What orbits a concern
- People
- Roles
- Relationships
- Lifecycle (the spine — see lifecycle-spine)
- Workflow
- Documents
- Communications
- Tasks
- Data
- Decisions
- Risks
- Obligations
- Quality controls
- Governance
- Knowledge
- AI assistance (via whisper)
- Integrations
- Audit trail
Why this matters
Most operational systems put workflow at the centre — they ask “what process are we in?” and force the human to move through the steps. The concern becomes secondary to the procedure.
Orbit inverts this. The system asks “what concern are we caring for?” and treats process as one of many tools the concern can use. The procedure serves the concern, not the other way around.
This is the architectural expression of the k2-case-management-framework thesis: case as GPS, not railway. A railway forces the route; a GPS understands the destination and adapts the route to the journey.
What it is not
- Not a database schema. Orbit is a mental model, not a foreign-key diagram.
- Not a UI layout. Although the visualisation of a concern with its orbiting capabilities is a likely UI pattern, Orbit-as-architecture is independent of any particular screen.
- Not unique to Hearth. The orbit metaphor exists in other systems; what’s unique is the discipline of honouring it consistently rather than letting workflow drift back to centre.
Design tests Orbit implies
- Is the concern visible and central in every UI screen?
- Does workflow show up as one orbiting capability, not as the dominant frame?
- Can a concern exist without any workflow attached, and still function?
- When the system needs to render information about a concern, does it surface the concern’s context first, or the process’s state?