Diagnostic Workflow – From Observation to Intervention

The HCS Diagnostic Workflow is a small loop that turns the Core Model into a usable lens.

It provides a structured way to trace observable issues in cooperation back to their systemic root causes in the Matrix and Pyramid — before you decide how to intervene or which System Mode to operate in.

Most improvement efforts fail because they start with practice changes (Level 4) rather than asking:

“At which level of cooperation is this actually unstable?”

This workflow keeps analysis grounded and ensures each corrective action strengthens the right layer of the system.

Why This Workflow Exists

The workflow exists to:

• move from vague problem labels (“communication issue”, “planning is bad”)
  to specific matrix cells and levels;
• respect the Level Rule (stabilize lower levels before adjusting higher ones);
• avoid jumping straight into tools and methods without understanding what function they are supposed to serve.

It focuses on the Core Model first:

• Conditions × Needs → Functions (Matrix)
• Levels 1–5 (Pyramid)

Extended Human Dynamics and System Modes are layered on after this basic structural pass.

When to Use the Diagnostic Workflow

Use this workflow when:

• you observe recurring friction, not one-off incidents;
• multiple people describe the same issue in different words;
• you are tempted to “roll out a new practice” but cannot clearly say which function it should support;
• you are in Stabilization Mode and need to understand where to repair first;
• you are in Growth, Conflict, or Reset Mode and want a clearer view of the underlying structure.

It works at multiple scales:

• within a single team;
• across client–vendor relationships;
• across functions (e.g., business, product, engineering, operations).

Workflow Overview

The diagnostic loop has five steps:

1. Observation – Capture neutral evidence.
2. Matrix Mapping – Locate the function (Condition × Need).
3. Level Check – Identify the lowest unstable level.
4. Function → Practice – Decide what to strengthen and how.
5. Trial & Learn – Run a small experiment and review.

You can run this loop in minutes for a single issue, or more formally for bigger patterns.

Step 1. Observation – Capture Evidence

Start with what you see, hear, or measure — without interpretation or blame.

Focus on observable behavior, not motives or personality.

Examples:

• “Critical dependencies were discovered three days before release; downstream team blocked twice this sprint.”
• “Access requests for test environments waited 10–14 days before approval in the last three cycles.”
• “In three consecutive steering meetings, we changed the priority of the same initiative.”

Good observations answer:

• what happened,
• when and where,
• who was affected,
• how often it occurred.

This ensures diagnosis starts from data, not opinion.

Step 2. Matrix Mapping – Locate the Function

Next, ask:

“If I ignore individual motives for a moment, where does this live in the Matrix?”

Map the observation to the HCS Matrix:

• Pick the most relevant Condition (vertical axis):
  Common Purpose, Interdependence, Communication, Trust, Change/Uncertainty.
• Pick the most relevant Core Need (horizontal axis):
  Shared Understanding, Mutual Commitment, Feedback Loops, Distribution of Roles, Autonomy & Agency.

This gives you a specific function (cell) to work with.

Example:

Issue: Dependencies discovered late; downstream team repeatedly blocked.
Likely cell: Interdependence × Feedback Loops → Outcome Reflection / Coordination Feedback

Another example:

Issue: Different leaders give conflicting statements about what “success” means.
Likely cell: Common Purpose × Shared Understanding → Alignment on Why

This step prevents vague labels like “communication problem” and anchors the issue to one or a small set of functions.

If several cells seem plausible, note the top 2–3 and keep them as hypotheses.

Step 3. Level Check – Find How Deep the Root Is

Now, decide at which level of the Pyramid the instability appears first.

Use this as a quick guide:

If the problem is mainly about…	It likely belongs to…
No shared reason to cooperate, no real trust, no basic communication ground	Level 1 – Preconditions
Misalignment, unclear expectations, weak feedback, low perceived agency	Level 2 – Core Needs
Broken coordination, planning, or learning cycles	Level 3 – Functions
Ineffective or over-complicated methods	Level 4 – Practices & Frameworks
Lack of reflection on how we work, inability to adapt the system itself	Level 5 – Meta-Practices & Innovation

Examples:

• Repeated late dependency discovery, even after checklists exist →
  likely Level 3 – Monitoring & Feedback function, with a possible Level 2 – Feedback Loops issue beneath.

• Constant disagreement about what success means, despite having KPIs →
  likely Level 1 – Common Purpose and Level 2 – Shared Understanding problem; KPIs are Level 4 artifacts.

The Level Rule applies here:

Stabilize lower levels before expecting higher levels (functions, practices, innovation) to work.

If you find signs of instability at multiple levels, treat the lowest one as the primary diagnostic target.

Step 4. Function → Practice – Decide What to Strengthen

Once you know:

• which function is under strain (Matrix cell), and
• which level is unstable (Pyramid),

you can choose or design a practice to support that function at the correct level.

Use the 25 Matrix functions as a reference for what “healthy cooperation” looks like. The practice can be:

• an existing method you already use;
• a method borrowed from a known framework;
• a lightweight, custom agreement that fits your context.

Examples:

1. Matrix cell: Communication × Feedback Loops → Signal & Response
2. Observed issue: risks and blockers appear “out of nowhere”.

3. Practice ideas:

   • Add a daily or twice-weekly “risk surfacing” moment.
   • Introduce a simple, visible “stop-the-line” signal for serious blockers.
   • Define who must respond and within what time.

4. Matrix cell: Interdependence × Distribution of Roles → Coordination

5. Observed issue: no one is clearly responsible for cross-team dependencies.
6. Practice ideas:
   • Introduce a rotating “dependency coordinator” role.
   • Add a simple rule: “No new work started while unresolved cross-team blocker > X days.”

The question is always:

“What practice or agreement would directly strengthen this function,
at this level, in this context?”

If the function is missing entirely, start with something small and explicit, not a heavy framework.

Step 5. Trial & Learn – Validate and Iterate

Treat each diagnostic outcome as a hypothesis, not a verdict.

For each chosen practice:

1. Define a simple signal or metric to watch.

2. Time-to-unblock, frequency of rework, number of escalations, etc.

3. Set a review date (e.g., after two sprints, one month, one release).

4. Run the practice and then review:

5. Did the specific observable issue improve?
6. If not, did something else become visible (e.g., resistance, new constraints)?

If the practice does not help:

• Re-check whether you targeted the correct level.
• Ask whether a lower level needs attention first (e.g., trust or shared understanding).
• Use the Diagnostic Dynamics file to explore contextual, relational, or political factors that may be blocking change.

The point is not to find the perfect practice on the first try,
but to keep the loop short, explicit, and learnable.

Output Template

You can use this lightweight template for documentation or reflection:

Observation:
Matrix cell(s):
Lowest affected level:
Function to strengthen:
Practice(s) selected:
Signal/metric to watch:
Review date:
Outcome / next step:

It fits naturally into retrospectives, 1:1s, coaching sessions, or system reviews.

Practical Example (Full Loop)

Observation
“Design team’s updates rarely align with development progress; misinterpretations surface during QA. This has happened in the last three sprints.”

Matrix Mapping
Likely cell:
Communication × Shared Understanding → Language / Terms

Level Check
- Level 2: Shared Understanding is weak (different mental models of the same work).
- Level 3: Coordination function between design and dev is under strain.

Function to Strengthen
Create and maintain shared language and explicit handoff criteria.

Practice(s)
- Introduce a short weekly alignment session between design and dev leads focused only on “what changed and what that means”.
- Create a shared “definition of ready” checklist for design handoffs.

Signal / Metric
- Reduction in QA rework caused by misunderstanding.
- Fewer clarifications needed after design handoff.

Review Date
- After three sprints.

Outcome / Next Step
- If signal improves: consider light optimization or extension.
- If not: revisit Level 1–2 assumptions (are purpose, priorities, or roles actually aligned?).

Summary Table

Step	Question	Output
1. Observation	What is happening, concretely?	Neutral description of events/pattern
2. Matrix Mapping	Where does this live structurally?	Condition × Need → Function (cell)
3. Level Check	How deep is the instability?	Lowest affected level in the Pyramid
4. Function → Practice	What should we strengthen? How?	Target function + candidate practice(s)
5. Trial & Learn	Did it help? What did we learn?	Measured outcome + next adjustment

Essence

Every cooperation issue can be traced through the same Core Model lens:

Observation → Matrix → Level → Function → Practice → Learning

This workflow does not replace judgment, System Modes, or Extended Human Dynamics.
It provides a stable structural backbone for all of them — a way to keep diagnosis grounded while you decide how to act.