This directory contains documentation intended to help developers and AI assistants understand the Natlas project.
Natlas is a Narrative Atlas / Story Modelling Tool. Its purpose is to represent and explore story structure through a structured visual model rather than treating a story as only a linear text document.
The documentation is intentionally separated into different levels of authority.
docs/
├── README.md
└── exploratory-notes/
├── ...
└── ...
This folder contains working and exploratory documentation gathered during the design and development of Natlas.
The files in this folder are useful for understanding:
- concepts and terminology used by the project;
- design ideas and reasoning;
- possible data models;
- visual and interaction concepts;
- architectural experiments;
- decisions that were being considered;
- explanations of specific parts of the system;
- previous discussions that may still contain useful context.
These documents are deliberately kept separate from this README because they are not necessarily authoritative specifications.
They may be incomplete, outdated, overly specific, speculative, or even inconsistent with one another.
When using these documents to understand or modify the project, follow these rules.
An exploratory document should answer:
"What was being considered or understood about the project?"
It should not automatically answer:
"What must the implementation be?"
The actual code and more authoritative project documentation take precedence over these notes.
Some documents describe ideas that were later changed.
A statement such as:
Natlas will use X.
may actually represent an earlier design direction rather than a permanent architectural decision.
Likewise:
The model should contain X.
may describe an experiment or proposal rather than the current domain model.
Use the notes to build a mental model, but verify important implementation details against the current code and newer documentation.
Different documents may describe the same concept differently.
If two exploratory notes disagree:
- do not silently combine them into a new rule;
- do not assume the most recently encountered statement is correct;
- do not modify the code simply to make the documents agree;
- inspect the current implementation and surrounding context;
- if the difference affects an important design decision, surface the ambiguity rather than hiding it.
Contradictions in these notes are acceptable. They are part of their exploratory nature.
When there is a conflict between an exploratory note and the existing implementation, the implementation is normally the stronger source of truth for what currently exists.
However, the exploratory note may still explain why something was designed that way, so do not discard its context merely because the implementation has evolved.
A useful distinction is:
Exploratory notes
↓
Explain concepts, reasoning, experiments, and possible directions
Current code
↓
Defines what actually exists
Explicit current requirements / authoritative specifications
↓
Define what the system is expected to become
If an authoritative specification is introduced later, it should take precedence over exploratory notes where they conflict.
These documents exist partly to give AI coding assistants enough context to reason about Natlas without requiring every concept to be rediscovered from the codebase.
When working on Natlas, an AI should:
- Read this README first.
- Use the files under
exploratory-notes/to learn the project's vocabulary and conceptual background. - Inspect the current code before making implementation assumptions.
- Distinguish clearly between existing behavior, documented intent, and exploratory ideas.
- Preserve established concepts unless the requested change explicitly modifies them.
- When documentation and code disagree, investigate the discrepancy instead of blindly following either source.
- When an important ambiguity cannot be resolved from the code or documentation, ask for clarification or explicitly state the assumption being made.
The goal is contextual understanding, not blind adherence to every sentence in the notes.
The exploratory documentation discusses concepts such as:
- stories and narrative structure;
- branches and alternative story paths;
- story nodes;
- gap nodes representing temporal or structural intervals;
- different gap sizes such as short, medium, and long gaps;
- fillers used to preserve spatial alignment without representing story content;
- alignment matrices;
- positional/transposition logic for mapping the narrative model to a visual space;
- visual representation and interaction through a structured matrix rather than an unrestricted canvas.
These concepts are mentioned here only as an orientation guide. Their exact definitions and relationships should be verified against the relevant documentation and current implementation.
In particular, do not infer that every concept listed here is already finalized, implemented, or immutable.
Natlas documentation is allowed to evolve.
During development, it is often useful to document an idea before its final form is known. Those documents can preserve valuable reasoning even after the implementation changes.
Therefore:
Exploratory documentation should preserve useful context without pretending to be a final specification.
If a concept becomes stable and important enough to serve as an implementation contract, it should eventually be promoted into a more authoritative document rather than relying indefinitely on an exploratory note.
Until then, the files in exploratory-notes/ should be treated as a context library: valuable for understanding Natlas, but not a source of unquestionable truth.