← Back to Protocols

Inner Council Protocol

Convene internal parts into a structured council for shared decision making.

A structured decision‑making protocol that treats internal parts as stakeholders and produces friction, note and task data that can be logged and revisited over time.

What problem this protocol targets

Neurodivergent people often report that major decisions feel like being pulled in multiple directions at once: one part wants safety, another wants impact, another wants rest, and another is terrified of disappointing others.

Unstructured, this becomes rumination or shutdown. The person knows there are multiple valid perspectives but cannot hold them all in working memory long enough to reach a decision that feels legitimate to the whole system.

The core idea

Inner Council treats internal parts as legitimate stakeholders rather than "irrational feelings" to be suppressed. The protocol provides a formal container: each part gets to speak, is recorded, and is responded to, and the final decision is documented as a council outcome rather than a unilateral move by the loudest part.

This protocol is inspired by parts work (including IFS-informed practice) and implemented in a way that can be logged and analysed using the shared schema.

Step-by-step flow (research version)

  1. Define the decision and context.
    Name the decision, timeframe and constraints.
    Output: a friction_record or decision record with tags like decision, multi-part.
  2. List the parts at the table.
    Identify which internal parts care about this decision (e.g. Perfectionist Executor, Angry Protector, Girl Who Carries Shame, Royal Self).
    Output: a set of part references attached to the decision.
  3. Give each part the floor.
    In turn, each part states what it wants, what it fears, and what it is trying to protect.
    Output: c_note entries per part, linked to the decision.
  4. Surface common ground and conflicts.
    Summarise overlaps (shared values) and explicit conflicts between parts.
    Output: synthesising note that becomes the basis for options.
  5. Generate options the council can accept.
    Translate the discussion into 2–4 concrete options that are at least tolerable to all parts present.
    Output: candidate task_entity or plan entities.
  6. Choose an option and log consent.
    Select one option and record which parts explicitly consent, which are neutral, and which are "flagging concerns but willing to try".
    Output: decision note + updated part states.
  7. Schedule a review.
    Set a small review point (e.g. in one week) to check whether the decision is still acceptable.
    Output: follow‑up task linked back to the original council.

Data hooks and schema

Entity Role in this protocol
friction_record Holds the initial tension around the decision.
c_note Stores each part's statement and the final synthesis.
task_entity Represents chosen options and scheduled reviews.
metric_entity Can optionally track stress/clarity before and after.

The Inner Kingdom System uses this protocol as one of its core engines in the "how I run" layer, especially for high‑stakes work and relationship decisions.

Relation to duoremifa tools

On duoremifa.com, Inner Council ideas show up inside deeper "自我研究 Lab · 3×3 实验室" and counselling‑style offerings, where decisions are treated as system-level experiments, not isolated choices.

The same structure—naming parts, logging their views, and committing to a time‑boxed experiment—underlies these offerings even when the UI is simplified for everyday use.

Research status

  • In active use within the Inner Kingdom System as a qualitative protocol.
  • Candidates for future work: develop a lightweight UI for logging parts and decisions; run a series of case studies on ND professionals making career or project decisions with Inner Council vs. without.
  • Over the next 2–3 years, I aim to document a series of Inner Council cases with ND professionals (career and project decisions), to ground a richer typology of internal conflict and resolution patterns.