ProtocolwareAuthority
Repository as an Operating System

Why There Is No Plan in the Doctrine

Doctrine answers a single question:

How does the system work at all?

It does not answer:

What are we going to do next?

This distinction is not philosophical.
It is structural.

Why a plan cannot live in doctrine

If a plan is placed inside doctrine, three things happen immediately:

  • it becomes treated as truth
  • it starts being interpreted rather than evaluated
  • it stops being safely changeable

That breaks the system.

Doctrine is permanent.
A plan is always temporary.

Mixing the two turns governance into storytelling.

Where the plan actually lives

In Protocolware, what people normally call a “plan” exists as PATH.

But only in a very specific sense.

PATH.md is not a task list.
It is not a roadmap.
It is not an intention.

PATH defines the space of admissible transitions.

It answers questions such as:

  • which steps are allowed at all
  • in what order they may occur
  • with which inputs
  • and with which expected outputs

Nothing more.

Nothing less.

Why it is called PATH, not PLAN

The word plan carries dangerous assumptions.

For humans, “plan” implies:

  • expectations
  • intentions
  • commitment
  • “we can always adjust it later”

In Protocolware, none of that is acceptable.

A plan is not a promise.
A plan is permission.

That is why the name matters.

  • PATH is a path the system may take
  • it is not guaranteed the system will take it
  • it is not guaranteed the system will reach the end

Stopping is allowed.
Stopping is correct.

The minimal definition of a plan in this system

This is the definition that matters:

A plan is not what we want to do.
A plan is what the system is allowed to do.

Everything else is conversation.

A minimal example

PATH.md

## step-1
inputs: —
outputs: idea.md

## step-2
inputs: idea.md
outputs: draft.md

## step-3
inputs: draft.md
outputs: final.md

Next