Concern Management

Definition

Concern Management is the first-pass operational model for Hearth.

It answers the practical question behind concern: what is the minimum shape a concern must have before the platform can actually help a person stay in flow?

The answer is deliberately smaller than a full enterprise data model and more concrete than a vague “work item” shell.

What it includes

The minimum viable concern model for Phase 1 and early Phase 2 has eight required parts:

Part	Why it is required
Identity and type	The human must know what this concern is
Lifecycle state	The human must know where it is in the spine
Why it matters now	The concern needs a current reason for attention, not just a label
Participants and roles	The human must know who is involved and who matters
Chronology	The concern needs a usable history of what happened
Obligations, deadlines, and risks	The concern needs operational pressure and consequence visible
Context pack	The concern needs the key documents, communications, evidence, and notes that explain the current situation
Work state	The concern needs next movements, blocked state, and the boundary between human-only, prepare-only, and delegable

The work state is where Hearth becomes distinct. It should show:

• what needs attention now
• what is blocked
• what can wait
• what Whisper may prepare
• what may be delegated
• what remains human-only
• where confidence is high, medium, low, or unknown for the relevant job

First-pass complaint exemplar

For the complaint prototype, a concern is minimally functional if a cold reviewer can answer these questions from one surface:

1. what complaint is this?
2. where is it in the lifecycle?
3. why does it matter now?
4. who is involved?
5. what has happened so far?
6. what is due or risky?
7. what is the next movement?
8. what may Whisper do, and what must stay human?

Deliberately deferred

These are important later, but not required in the first viable model:

• full relationship graphing between concerns
• financial model depth
• configurable workflow canvas
• team-performance telemetry
• advanced nesting / spawning rules
• broad analytics and reporting surfaces

If one of these becomes required before the concern is even intelligible, the model has become implementation-heavy too early.

What it is not

• Not the final canonical platform schema
• Not a workflow definition
• Not a task list with extra metadata
• Not a demand to model everything before anything can be useful

The model is minimum viable only if it makes the concern legible sooner, not if it simply reduces the number of fields.

Design tests it implies

• Can a user understand the concern and next movement without traversing multiple surfaces?
• Does the model make blocked state visible before the user hunts for it?
• Can the model support Flow Cues without becoming a task inbox?
• Does it distinguish clearly between operational pressure and final judgement?
• Does it leave room for future richness without forcing it into the first prototype?