A Product‑Level PRD and Iteration Path

1. Product Thesis

This document describes a personal cognitive operating system designed for neurodivergent people who live and work under chronic cognitive friction. The system is not a generic productivity app. It is a three‑layer architecture that treats the person as an inner system, then builds protocols and interfaces on top of that system, and only then worries about engineering. This approach is informed by a decade of frontline operational experience.

The three core questions it answers are:

• Who am I, as an inner system that is not always coherent?
• How do I run, when willpower alone is not reliable?
• How do I perceive what is happening, so that I can act instead of dissociate?

Everything else – data schema, storage, APIs, synchronisation – exists to serve these three layers.

2. Layer 1 – “Who I am”: Inner Kingdom Architecture

One‑line summary: Build the inner kingdom before you build the tools.

Problem

For people with C‑PTSD, dissociative tendencies or complex inner parts, most productivity tools assume a unified, rational “user” who can simply decide and execute. This does not describe the lived reality. Emotions, impulses and protective reactions arrive as different “voices” that fight, avoid, sabotage or over‑perform. Without a way to model this inner plurality, any task system will be brittle.

Design

Represent the self as a set of parts rather than a single agent:

• “Girl Who Carries Shame”, “Angry Protector”, “Executive Functioner”, “Substitute Boy”, “Royal Self”, etc.

For each part, define:

• Colour, energy pattern, typical emotions, protective strategies, trigger patterns.

Visualise alliances and conflicts between parts as an internal organisation chart or kingdom map. Treat C‑PTSD and dissociation not as noise, but as a first‑class configuration object: the system must acknowledge and model fractured self‑structure, not quietly assume it away.

Outcome

• Vague emotional chaos becomes a manipulable internal model.
• The user can see “who is at the wheel” during friction events, and how different protocols affect part dynamics.
• This inner model becomes the backbone for everything the system does later: which protocols to recommend, how to pace tasks, how to interpret metrics.

3. Layer 2 – “How I run”: Protocol Engine

One‑line summary: Replace willpower with protocols; let the system carry you through each step.

Problem

In high friction states (perfectionism, shutdown, social exhaustion), “just do it” fails. What people actually need is a small, reliable sequence of questions and actions that can be triggered under load. Most tools either offer flat checklists or generic advice; neither is sensitive enough to ND patterns.

Design

Treat protocols as first‑class runtime entities, not as static features. Core examples:

• Dimension Reduction Protocol – compress a blurry project into 3–5 concrete candidate tasks, then choose a single first physical action.
• Inner Council Protocol – convene internal parts into a structured council: each part speaks, needs are acknowledged, the centred self decides.
• State Calibration Protocol – check energy, focus, and bodily signals; adjust plan to what is realistically safe now.
• Boundary Check Protocol – check whether a task violates self‑defined boundaries; generate a protective response.

Bind protocols to situations:

• When perfectionism spikes, suggest Dimension Reduction.
• When social exhaustion rises, suggest Boundary Check.
• When internal conflict markers appear, suggest Inner Council.

Outcome

• The system becomes an inner automation platform rather than a static to‑do list.
• Protocols can be logged, analysed and iterated; the system learns which combinations reduce friction for this specific person.

4. Layer 3 – “How I perceive”: Transformable Control Room

One‑line summary: Let the same underlying data appear in the view that matches your current cognitive state.

Problem

One fixed interface cannot serve all states. A neurodivergent person may oscillate between tunnel‑vision focus, scattered hyperactivity, shutdown and floating dissociation. Forcing the same kanban or calendar view on all states adds friction instead of removing it.

Design

Represent core entities – frictions, tasks, states, notes, tags – in a shared data schema (MindOS schema) and allow multiple views:

• Kanban boards, calendars, graphs, plain text lists.
• Markdown as the atomic unit, Obsidian / Notion as frontends; YAML frontmatter for structured fields.
• Generate weekly “inner system operations reports” mapping friction types and effective protocols.

Treat UI as a cognitive strategy:

• Deep CSS‑level theming and layout control, allowing sensitive users to stabilise themselves through visual order.

Outcome

• The same data can be rotated until it becomes graspable in the current state.
• The interface acts as an externalised control room for the inner kingdom, not a foreign dashboard imposed from the outside.

5. Usage Story: From a Stuck Evening to a Running System

It is 22:00. You are staring at the same sentence in Obsidian and have not typed a single new word in 20 minutes. Your chest is tight, your mind is racing, your shoulders hurt.

Log the Friction

You hit a hotkey and record a friction entry in Obsidian:

• Title: “Perfectionism, can’t write”
• Intensity: 8/10
• Tags: writing, self‑doubt, night

Identify Parts and State

In the Inner Kingdom view, this friction is tagged as:

• Parts involved: Perfectionist Executor, Girl Who Carries Shame
• Current state: low energy, high mental speed, high tension

Run a Protocol – Dimension Reduction

You choose Dimension Reduction. The protocol walks you through focused questions:

• What is the perfect version? What is the smallest version?
• List 3–5 subtasks.
• Result: “Open a new note and type three subtitle options.”

Act, then Reflect

You perform the action. The friction intensity drops from 8 to 4. The weekly review later shows perfectionism as a recurring night-time pattern, and Dimension Reduction as your most effective escape route.

6. Shared Kernel: A Cognitive OS, Not Another App

Even when compared with more engineering‑heavy blueprints, the core spirit is shared:

• The product is a personal cognitive / psychological operating system, not a notes app.
• Cognitive friction and protocols are the central loop: friction is logged; protocols transform it; data feeds back into the model.
• Ecosystem thinking: Obsidian, mobile, and browser capture are integrated points.

The key difference is emphasis: this document starts from inner architecture and lived experience, then descends into engineering.

7. Differentiation and Integration

What is unique here

• Existential starting point: Model parts and trauma as configurable objects.
• Protocol engine as runtime: Executable flows bound to conditions.
• Interface as perception layer: UI as a cognitive regulation strategy.

Integration Strategy

Keep the three philosophical layers as the North Star:

• Data: MindOS schema with local‑first storage.
• Sync: Simple, single‑source flows (iOS + Obsidian).
• Extensions: Focused plugins, not a full marketplace.

8. MVP and Iteration Path

MVP (Must-have)

• MindOS data schema + local storage (Core Data / SQLite).
• iOS minimal UI: friction log, task list, state metrics.
• Obsidian plugin: send friction notes into the unified schema.
• One protocol: Dimension Reduction, bound to friction records.
• Themes: ND‑friendly visual hierarchy and readable typography.

Phase 2 (Expansion)

• Inner Kingdom configuration UI for parts and relations.
• Additional protocols: Inner Council / Boundary Check.
• Weekly Systems Review view and report generation.

---

This product exists to let at least one real person repeatedly experience the following micro‑loop:

“I log a friction → the system recognises it → it guides me through a protocol → I do a specific physical action → I see friction and state change in my data.”