> ## Documentation Index > Fetch the complete documentation index at: https://docs.parable.work/llms.txt > Use this file to discover all available pages before exploring further. # Problems > Keep one outcome, question, risk, or decision in a shared Ponder thread with its context, Messages, and proof. # Problems A Problem is the shared, durable thread for one outcome, question, risk, or decision. People and Ponder work through it together, and anyone with access can return later and follow what was asked, answered, decided, and proven without reconstructing a one-off chat. Every Ponder conversation happens inside a Problem. A Problem lives in one Workspace and keeps its Messages in order. A Parable's Problems form one tree. Its root Problem is made with the Parable. Ponder opens the root when no other Problem is chosen, and the Problem picker names it for the Parable. Every other Problem sits under a parent Problem, and you can start one under any Problem at any time. Each set of Changes you start belongs to one Problem, and a Problem holds at most one set. Pulls, the set a Versioned setting's save opens, and sets opened through the API outside Ponder belong to no Problem. The root Problem holds none, so a change asked there goes into a new Problem under the root. A Problem's set of Changes keeps the author who started it, but the people who work in the Problem share it: anyone in Publishing or Primary who can see the Problem may edit it, prepare it, propose it, and pocket, restore, or delete it. When you want a change of your own beside that set, it goes into a Problem under it. A child Problem's set starts from the newest Release, not from its parent's Pending Changes, and it publishes on its own. Each Message records the view it was sent from: the open Parable, its Version or Changes, the data reading, and the selected Piece. Opening something else later never rewrites earlier Messages. Context links are optional references to a Parable, Version, set of Changes, or Piece; they help Ponder find the right material and never grant access. A Problem also carries the people responsible for it, links to other Problems (a parent, one it blocks, or one it runs alongside), Pings sent from it, and Proofs. A Proof is evidence recorded against the Problem: a Picture, People, a Ponder Run, or a Plot. Judging a Proof records a verdict and recalculates whether the Problem is unresolved, failed, or proven; nothing already recorded is rewritten. Ordinary replies run directly in the thread. A Run is a separately managed Process. It starts when you ask Ponder to work on a Problem that way, or when a Power asks for a Ponder level that the current reply does not run at. Everyone sees only the Problems and context their current Workspace access permits. Setting who is responsible for a Problem, linking Problems, and attaching context change nothing about Parable responsibilities, membership, or permissions. Setting responsibilities replaces the whole list and asks for approval by default. Pocketing a Problem puts it away without deleting anything; no new Runs start until it is taken out of the Pocket. Pinning a Page to a Problem gives everyone in it a tab for that Page beside the Parable's home Page; while the editor is hidden, the chosen tab shows the live Page above the chat. Pin a Page you just built or one the conversation keeps returning to, and unpin it when it stops helping; pinning never changes the Page. An approval authorizes only the exact action it presents; declining performs nothing. 1. Decide whether the work needs a new Problem. Keep refining the same outcome in one Problem; start a new one when the outcome, owner, or review path differs. Give it a name a teammate can recognize later, a one- or two-sentence description of its outcome, and an icon. It goes under the current Problem unless you name another parent. 2. Open or name the material. Navigate to the Parable or Piece, or name another target in the Message; Ponder works on the named target and reads current details before acting. 3. Send one clear request: the result you want, what good looks like, and any boundary that must hold. 4. Bring people in. Ask Ponder to put questions to the people in the conversation or to Ping specific people; set who is responsible when ownership is clear. 5. Record evidence. Ask Ponder to add a Proof for a claim that must be supported by more than agreement, then judge it. 6. Organize. Link related Problems, attach context that should travel with the thread, and pocket a Problem when its work is done or paused. A good Problem has a recognizable name, one outcome, the right responsible people, and Proofs that match its claims. Check it by opening the Problem: confirm its Messages, links, responsibilities, open Pings, and resolution status. Ponder can find Problems, open one, and show how Problems connect. A successful reply is not a published change; publishing goes through Changes and review. If a teammate cannot see the Problem or its context, fix their Workspace access or Parable participation; never paste restricted content into a Message to work around it. Related Powers: Pings, Participants, Publishing, Workspaces. Find each by its title; do not guess stored names. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.