The Atlas skill

The model in one paragraph

A weighted, multi-parent DAG laid over a canonical single-home graph. Underneath, every canonical node (project, topic, entry, entity) has exactly ONE home. Above it sits the Atlas: a layer of pointers you walk. Many pointers may aim at the same node, so a node effectively has many parents, each edge carrying a weight. You get a clean walkable spine and honest many-branch richness at once. That duality is the point: do not flatten it into a tree, do not dissolve it into a free graph.

The three laws

Read protocol: walking the Atlas

Goal: get from "I have a question" to "I am looking at the 1–3 nodes that answer it" while loading as little as possible.

1. 1.Start at the root Atlas index: outline it. You get a handful of realms, each with a summary and a child count. Read summaries only.
2. 2.Pick ONE realm whose summary matches your need and outline it. Repeat. Each level narrows realm → category → project.
3. 3.Descend one level per step. After each outline, stop and read summaries before choosing the next child. Do not pre-load siblings.
4. 4.On reaching a project, keep funnelling into topics, and open full entry bodies only at the leaf.
5. 5.Follow the heavy edge by default — weight encodes "the usual way in". Use a lighter edge only when your question genuinely comes from that angle.

Never search or crawl broadly as a first move to "grab everything"; never open bodies above the leaf. If you are loading more than about five nodes at one level, you have abandoned the walk — back up and pick ONE child.

Write protocol: placing a node

Add knowledge so future walks find it from every angle it deserves — and from no angle it doesn't. Ask, in order:

1. 1.What kind of thing is this? A decision, task, fact, question, note, resource — pick honestly.
2. 2.Does it need state or sub-parts (a status, an answer, discussion — anything that will change or accrete)? If yes it is not a bare entry, it is a container.
3. 3.Where does it hang? Name its primary parent and give that edge a heavy weight.
4. 4.Does it legitimately belong in a second place? Only on a real cross-cutting need — add light secondary parents, lazily.

Weight is meaning, not priority theatre: the heavy edge is high because that IS the usual way in. And write real summaries — the summary is what every future walk reads instead of the body, so a vague one breaks the walk for everyone after you. Prefer extending an existing node over creating a near-duplicate.

The governing rule: containers and sealed facets

This is the law that keeps the deck from rotting, and the most distinctive thing about PlotDeck.

• ·A card MUST NOT carry mutable state as a property. There is no status field. There is no answered flag.
• ·Anything with state or accreting sub-parts is a container — a normal citizen of the graph that carries outward links and may hang under several parents.
• ·Its state and sub-parts are facets: each is its own small child with exactly ONE parent and no edge that leaves the container.
• ·So a container is a branch on the outside (findable from many angles) and a leaf on the inside (its facets are invisible to navigation).

The invariant: navigation only ever traverses meaning-bearing containers. Facets have no outward edges, so a facet can never become a path, a hub, or a cross-edge. That is what buys multi-parent richness without the graph turning to mush.

In practice: to mark something done you do not set a property and you do not edit prose — you attach or replace a status facet. To answer a question, the answer is a sealed child of the question's container, not an edit to the question. If you ever feel the urge to give a facet one outward link "just this once", stop: that urge is the rot. If it needs outward links it was never a facet — promote it to its own container.

This discipline is high-ceremony: every status change is a child object, not a flag flip. A human erodes that out of friction, which is why the deck is built AI-first — an agent holds it by default. But an agent's failure mode is judgment (misclassifying a facet, or forgetting the rule late in a long context), so the server enforces the seal rather than trusting it.

Threads: the answer flow

A Thread is the canonical container for a question and its resolution. The container carries the outward links and hangs next to what it questions, so context is one hop away. Inside, as sealed children: the question (verbatim, never overwritten), a status facet (open / answered / parked), and once answered, an answer facet.

1. 1.Pull only Threads whose status facet is still open.
2. 2.Read the question plus the one or two entries its parent links point at — the links do the work of supplying context.
3. 3.Capture the answer as a new sealed child of the same Thread, and link it resolves → the question. That edge stays inside the container, which is the one facet-to-facet link the seal permits.
4. 4.Flip the status facet to answered. Never touch the question body.

Do not "simplify" this shape. The question stays verbatim so the trail survives — what was asked, what was decided, when. The answer is its own node so it carries weight and can later be superseded; you cannot supersede a paragraph edited into a question. Status-as-facet is what makes "show me only what is still open" a cheap, structured query instead of prose parsing. And because it is all sealed inside the Thread, nine open questions never become nine loose fragments each sprouting edges.

What the server enforces

Facets are a real primitive, not a naming convention. Single-parent is a column, so attaching a facet writes no edge at all — and facets never appear in outline, search, entry listings or graph crawls, by construction rather than by filtering.

Do / never