Skip to main content

Map Of Reality Template

What is true right now?

A map-of-reality page lets an LLM, agent, or human inspect the current state before making claims or plans.

Use this when the page job is map-of-reality. Markdown files with REALITY in the filename must use this type.

This is the first part of the Dreamineering method: know the truth of what you have to deal with before imagining the Dream or choosing the Bridge.

Use

Apply this standard before writing a Dream or Bridge file. First locate the real artifacts. Then draw or link the diagram that explains how they work together.

Frontmatter

type: map-of-reality
template: map-of-reality-template
template_url: /playbook/standards/templates/map-of-reality-template
loop_phase: evolution
level: working

Shape

  1. Name the boundary of the system being mapped.
  2. Inventory the artifacts, assets, code, data, and proofs that exist.
  3. Link to diagrams or diagram sources that explain how the system works.
  4. State the operating flow, ownership, and dependency paths.
  5. Mark capability state as REALITY, DREAM, or CONSUMED.
  6. Name gaps, unknowns, stale claims, and the next proof needed.

Skeleton

TITLE

This map records what exists now for SYSTEM.

## Boundary

What is inside this map, and what is outside it?

## Existing Artifacts

| Artifact | Path or link | State | What it proves |
| --- | --- | --- | --- |
| Artifact A | `path/or/url` | REALITY | Proof signal |

## Assets And Code

- `path/to/code-or-data` - what exists and how it is used.

## Diagrams

- [Diagram Name](/playbook/) - what the diagram explains.
- `path/to/source` - source file for an editable diagram, when available.

## Operating Flow

How do the artifacts, people, agents, instruments, and systems interact?

## Gaps

- Gap A - what is missing, stale, unproven, or under-instrumented.

## Next Proof

What smallest check would make this map more true?

Checks

  • The page maps current state, not desired state.
  • The filename contains REALITY only when frontmatter says type: map-of-reality.
  • Every major claim points to an artifact, path, diagram, code surface, data source, proof, or explicit unknown.
  • Diagrams explain how things work; they are not decoration.
  • Capability state is honest: REALITY, DREAM, or CONSUMED.
  • The next proof makes the map easier to update next time.

Failure Modes

  • The page turns into a plan.
  • The page describes intent without locating the artifact.
  • Diagrams are missing where the system needs visual explanation.
  • Stale claims stay unmarked.
  • The map hides gaps because they are uncomfortable.

Context

Questions

What would an LLM need to know before changing this system?

  • Which artifacts actually exist?
  • Which diagram explains the current flow?
  • Which claim is still a DREAM?