​

Ponder

​

Sources

Docs: Pondering, Powers, Workspace AI processors Web App: Open Ponder from your Workspace sidebar; each Workspace has its own address. Ponder is where people and AI work through a Problem together. The Problem keeps the ordered Message thread; each ordinary response uses the model, effort, and Powers selected for that request. Another person can return to the thread without reconstructing it from a temporary chat.

​

Set appearance and sound

The Workspace sidebar places appearance and sound controls immediately before Parable Pets. Select the appearance icon to cycle Auto, Light, and Dark; a toast confirms the selected mode. Auto continues to follow the operating system. Sound effects are on by default. Select the sound icon to turn them off or back on for this browser. The choice applies across Parable and does not enable new sounds on surfaces that do not already use them.

​

Start with a Problem

If no active Parables are available to you and you can create one, Ponder creates and opens Your First Parable. Other people’s private Parables do not prevent you from getting your own. Reopening Ponder uses your existing Parable. A link that names a Parable opens that Parable even when the sidebar list has not caught up yet; Ponder re-reads the list once before it treats the link as stale and opens your first Parable instead. When Home is the only Page, Ponder starts at full width. The left/right arrow control restores the Page and preview alongside it; the up/down arrow control expands or restores the conversation’s height. These controls work independently from every tab and remember the width choice. The composer stays centered at a comfortable width. An empty conversation shows the Ponder orb without introductory copy. Ponder expanded in both directions shows the Parable title, at the same size as the breadcrumb title. Side-by-side, its header says Ponder. The restored view keeps that title as the first breadcrumb, followed by compact uppercase Piece names. Expand and restore animate smoothly, respect reduced motion, and play transition sounds only when your sound preference is enabled. The Page’s bottom editor starts closed. Choose a document tab to open it; Ponder remembers whether you left that editor open or closed. A Page without Panes shows the dotted canvas alone. The mode dropdown stays visible while your Parable is Personal: only you so far. It opens in the fullest mode your seat allows, Publishing for its Primary, and you edit it in place. Choosing Publishing there only switches you to editing. Seating a second person switches the Parable to Published Versions, where edits go through Changes and Versions. A Problem is the shared thread for an outcome, question, risk, or decision. Give it a name that a teammate can recognize later, then keep working in the same thread as the surrounding Parable changes. A Parable’s Problems form one tree. The Parable’s root Problem, named for the Parable, sits at the top. Every other Problem sits under the Problem it serves, as deep as the work needs. Nothing else starts at the top. Open the Problem picker above the composer to see the tree. Each row shows the Problem’s icon, its name and the first sentence of its description. It also shows who started it, who else is on its thread, and its state. A face is full while that person is on the thread now and faded while they are elsewhere. The presence portraits after the Release and Refresh group fade the same way. The picker opens on the root and the Problems you started. A Problem that only carries one of yours under it reads muted. Rows that scroll up sink under the search box. Each Problem has a state, read from its Changes and its Proofs: The buttons under the search show only the states you choose, with how many Problems are in each. People chooses whose Problems show: yours or everyone’s, or the people who started a Problem or are on its thread. It also filters by their participation (Primary, Publishing, Pinging or Peeking) and by Workspace Role. Workspace Roles show only when you may view the Workspace’s members. The Problem you are in stays in the list whatever states you choose and whoever started it, but a search, People or Running can leave it out. When nothing else matches, the picker says so. To create a Problem, choose New Problem at the foot of the picker. Give it a name, a sentence or two on the outcome it is for, the Problem it sits under, and an icon. All four are required. It sits under the Problem you are in unless you choose another. While Ponder creates it, Cancel is off and the form stays open. Ponder creates one Problem at a time: while it creates another, such as one for a Message sent from a Pane, the form says so and keeps what you wrote. In that time, New Problem in the Problems tab and New Problem · Start Changes in the Release menu open no form. Ponder says that it is creating another Problem, and nothing starts. Use a separate Problem when the work has a different outcome, owner, or review path. Keep the same Problem when you are refining the same outcome across several messages or pieces of a Parable.

​

Give Ponder the right context

Ponder can work from context already available to the Problem and can use authorized tools to inspect the Workspace when a request needs more. A Problem keeps its connection to its Parable even when no specific Piece is selected. When the Parable changes, its attached context still identifies the Parable; Ponder can read current details before acting. Merely opening another Parable, change, or Piece does not silently rewrite the Problem before your next message. Each Message receives the same definition revision and Latest or pinned Refresh reading used by the open Parable’s React and Plots, together with the selected Changes and Piece. Queued Messages and approval continuations retain that view. This applies to every tool in chat and Processes: context links and the current view are optional. Name another Parable, Piece, or set of Changes to work there; Ponder uses that target instead of replacing it with the open view. Without a view, Ponder can discover an authorized target and asks only when the choice remains ambiguous. A target, required fields, or current revision may still be needed by the action itself. Tools that manage context links naturally need the link they act on. Context helps Ponder understand the work; it does not give Ponder new access. You and Ponder can use only the information and actions allowed by your current Workspace access.

​

Choose a model and effort

The composer starts in the Parable’s root Problem, which Problem names for the Parable. Open the picker to work in another Problem instead. One model answers each response. The composer starts with Ponder Standard. Ponder is Parable’s own model: its effort levels are Simple, Standard, and Strong, and Parable chooses the model behind each level. The model mark in the input footer opens the model menu. Ponder comes first, then a search field and every other model, grouped by lab. Each row names the server that answers for it: Parable for every model Parable hosts. A model this Workspace cannot use stays in the list, marked unavailable with the reason. Workspace administrators set the order of the list and can hide models on Workspace AI processors. The slider beside the model mark sets the effort, and the name of the chosen level shows before the mark. For Ponder the stops are Simple, Standard, and Strong. For another model the stops are Default, where the model’s server decides, followed by the levels that model offers, in the order none, minimal, low, medium, high, Extra high, and max. A model that offers no levels has no slider. When a model offers a speed option, such as fast mode, a toggle follows the slider. The Workspace’s AI policy decides which models can answer. When it refuses the chosen model, the send fails with the policy’s reason, and Ponder does not switch to another model or processor. When it allows no model for chat, the input says Chat is unavailable under this Workspace’s AI policy and sends nothing. See Workspace AI processors. The input footer reads from left to right: Attach; the … menu with Clean up text and Keep the Parable named; then, after a gap, the effort name, the model mark, the effort slider, the speed toggle when the model offers one, Stop, and Send. One row above the input holds Problem, with a small uppercase label before its value. Participation, Release and Refresh sit together at the Parable’s top right, with the people here just after them. To use a Power, a reusable set of instructions, type @ in the input. A searchable list of Powers opens; choosing one places a Power chip in your Message, and that Power applies to the response. Delete the chip to drop it. The model and Powers guide the response; neither can expand your permissions. Each Message captures your open Parable, Changes, version, and Piece even when none is attached to the Problem. Queued Messages and approval continuations keep that view. Context links are optional reference material, not permission to use a tool; Ponder can discover or ask for a target when no view is selected.

​

Send one clear request

Write what you want to achieve, what a good result looks like, and any boundary that must remain true. Use the arrow to send the message and begin the work. While Ponder is answering, the composer stays open. Sending again queues the Message: it waits in a stack above the composer with your portrait and its place in line, and goes out on its own when the current response settles. Remove a queued Message from the stack if you change your mind; Stop, beside Send, ends the current response. Only your own queue is shown. Problem, model, effort, and Powers remain available while Ponder answers. A queued Message keeps the model, effort, Powers, attachments, and context selected when you sent it; later changes apply to later Messages. Switching Problems leaves the other response running. Stop returns your queued Messages to the composer, above your draft. After a failed response, use Resume to continue a held queue. During View as, queued Messages are held and read held in the stack; they go out in order when you exit View as, and you can remove one meanwhile. To redirect your own reply while it runs, press Cmd+Enter instead. Your words wait in the stack marked “steering this reply” until Ponder takes them, after the step it is on and before it thinks again, then appear inside the reply as Steered. You can steer only a reply to your own Message; attachments are sent as a queued Message instead, and words steered after the reply ends become your next Message. The … menu beside Attach holds Clean up text and Keep the Parable named. Clean up text fixes spelling, spacing, capitalization and closing punctuation before a Message is sent. It replaces only words it lists as corrections, using the Workspace’s names and the Parable’s terms, and never adds, removes or reorders ideas. It is on until you turn it off, and the choice is remembered in this browser. A cleaned Message shows the broom in its footer; hover or focus it to read what was typed. Everyone on the Problem sees it, as they see the Message. While a send waits on it, a broom sweeps beside the … menu. If cleanup fails, is busy or takes longer than a moment and a half, or you switch it off while it runs, the Message goes out as you typed it. If the Workspace’s AI policy does not allow cleanup, the item is greyed out and says why, for the rest of the session. Steering words are sent as typed. Keep the Parable named lets Ponder keep the Parable’s name, description and icon up to date from the Messages sent while viewing it. It is one setting for everyone on the Parable, not a personal one. A new Parable starts with it on, so the first Message names it. Editing the name, description or icon yourself turns it off; anyone who can edit the Parable can turn it back on, and everyone else sees its state, greyed out. Stop also appears for a reply that is still running after you reload or return to the Problem, and ends it for everyone in the thread. A reply paused on an approval is waiting for you, not running, so it offers the approval instead of Stop. The thread follows new content smoothly while you are at the bottom. Scrolling up keeps your reading position until you return to the latest Message; reduced motion uses immediate scrolling. Sending a Message or answering a question returns you to the latest Message, and the reply grows in place beneath it without redrawing the turn you just sent. Ordinary responses stream into the thread as the model writes. Each reply is signed Ponder, or with the name of the model you chose. A reply’s footer shows its time. Ponder answers in a bubble of its own, one shade lighter than the thread in both themes, beside a round disc. Bubbles are capped at 80% of the column, except in a narrow column, where they take its full width. While Ponder works, the disc shows an animated orb, and the row at the head of the reply reads Thinking… or the name of the tool being run. The row stays live until the answer itself starts streaming in, even when Ponder wrote a few words before its next step, and goes when the answer lands. Ponder’s chain of thought sits behind a brain beside the reply’s name, shown when you point at the reply, with THOUGHT FOR 4 SECONDS beside it once the answer lands (or the number of steps, for a reply you open later). Turn it on and the thought opens there, as its own bubble between the name and the answer: each tool step with its outcome (failed and disallowed steps are marked), opening again to its parameters and result, and the model’s reasoning in the muted voice. Opened before Ponder’s first step, it shows Gathering context… while Ponder reads the thread. Turn the brain off to hide it again. A reply with nothing to trace shows no brain. A Pane preview or a Ping question a tool produces stays in the answer, not behind the trace. The question card appears only in the reply that asked it; the thread does not list Pings, Possibilities, or Proofs after the latest Message. A single question is the card’s title. Each option is a row with its name in capitals and its summary beneath. A question whose options carry reasons shows Pros and Cons as bulleted columns beside them; a question without reasons keeps plain rows. Choose an option to answer, then use the note icon on its row to add a note or a picture to that choice. The icon opens and closes the note; a note that holds words or files starts open, and the icon stays lit while it is closed. I need more information is a choice against the options: choosing it clears them, and choosing an option or writing your own answer clears it. Something else opens one line for an answer in your own words, with a picture if that is the answer. An Ask policy can pause an ordinary chat tool call for Deny once or Allow once; approving authorizes only that presented action, and the row reads Waiting for you… until you decide. The pending request is saved with that Message; your decision continues the same tool call. Authorized tool calls, including creating a Package, run in ordinary chat. Ponder asks for a Process only when you want separately managed work. A Question appears in the reply and waits for your answer; saving the answer continues the same Problem. If the connection fails before continuation starts, the answer stays queued for retry. If the Message was saved but the response could not start, the thread reports that failure; send a new Message to continue. Tool steps distinguish a rejected action from an unconfirmed result. A rejection can be corrected. An unconfirmed write asks you to verify the saved state before continuing, so a retry cannot silently repeat the change. Pane previews report access or rendering failures directly instead of treating an error page as a finished preview. A Pane preview follows your selected Changes or version and data reading when no target is specified. Naming another authorized Parable previews that target without inheriting the previous Parable’s draft, Report, or Piece. The preview uses captured code and the settings you can read. Live SQL and Plot requests are not executed inside the captured preview, so a Pane that needs those requests can show an error in its preview. If a model sends an invalid tool response, Ponder stops that response and keeps completed actions. Send another Message to continue. The failed step’s speculative text is excluded from the next attempt’s context.

​

Move between conversation and work

Ponder opens conversation-first, filling the height of its column immediately. On desktop, a Parable with additional Pages starts with Ponder at half the available width beside the working surface. Use the left/right arrow to switch between full width and the split; that choice is remembered for the Parable. You can also drag the split. Narrow screens keep the stacked layout. Two more controls sit beside those arrows. The arrow to a line hides Ponder’s column, and the Parable takes the width; the column stays open underneath, so a reply keeps arriving. To bring Ponder back, use the panel button in the Parable’s header, on Ponder’s side: at the end of the header while Ponder is on the right, before the breadcrumbs while it is on the left. It always shows, in room of its own. Hiding is remembered for the Parable. Ponder starts on the right. The curved arrow moves it to the other side of the Parable: it slides under the Parable and settles there, and the arrow then curves the other way to bring it back. The side is kept in this browser for every Parable. At full width, Pages come into the conversation. Tabs show every Page that renders something, in the order of the Pieces tree: beside the input, stacked from its foot, when the chat is wide enough, and above it otherwise. Many tabs scroll, turning over the edges of their strip. An empty Page (one that places no Pane and whose code draws nothing of its own) has no tab, unless it is the Page you are on. The chosen tab renders the live Page on a card above the thread, and the Page settles in once every Pane is on screen; moving to another tab animates in the same frame, and choosing the open tab again folds the Page away. When a Pane opens another Page, or you use browser Back, the card follows. Drag the card’s bottom edge to resize the Page against the thread; the height is remembered for the Parable. While a Page is shown, the thread rolls away at its top and bottom edges. Pin to Ponder, in a Page’s menu in the Pieces view or in the Pin menu at the end of the Parable’s breadcrumbs, or asked of Ponder, shows a Page to everyone in the Problem: a Page pinned while you watch opens at once. Pins do not choose the tabs. The fully expanded header shows the Parable’s icon. The Pin menu (the thumbtack at the end of the breadcrumbs, right after the Piece on screen, which moves into Ponder’s header with them while Ponder is fully expanded) holds both pins. The thumbtack shows while you point at the header or a control in it has keyboard focus, and stays while its menu is open; it keeps its room otherwise, so the trail does not move when it shows. On a touch screen it always shows. Each thumbtack in the menu shows its state: upright while pinned, slashed while not. Pin to Ponder pins or unpins the open Page in the open Problem; Home is always in Ponder. Pin to Navigation for Me keeps the Parable in your sidebar or takes it out. Every active Parable starts pinned, and the choice is yours alone, kept in this browser. Pointing at a Parable in the sidebar opens its card: its preview on top, in your theme, then its mark, name and description. Right-click a Parable in the sidebar, or use the menu at the end of its row, for the menu the Pieces view gives a Piece: Move up and Move down reorder your sidebar, and Unpin from Navigation for Me takes the Parable out of it. The compact views in its header keep the rest of the work close:

• Pieces shows Pages and Packages together, including Home and each Package’s Panes and Plots. Search covers the complete hierarchy. The Add Package icon sits beside the search field and creates a root Package.
• Adding a Page, Package, Pane, or Plot opens a dialog that asks for its Name and a Description: one sentence on what the Piece is for. A Package or Pane also asks for an icon. The description shows in a band under the selected Piece’s header, where you can change it. Every Page, Package, Pane, and Plot needs one: a save that leaves one without a description is refused (PA-AU-046), and the message names each Piece.
• Problems shows the Parable’s Problem tree as cards, the same tree as the Problem picker. Each card shows the Problem’s icon, name, first sentence, people and state. The root card reads as the Parable. Select a card to switch the Problem Ponder acts on below, as the picker does. The address names that Problem (?problem=), so a reload or a shared link opens it again. Search and the filter sit at the bottom, where Pieces has its search. The filter holds the picker’s states with their counts, Running for the Problems Ponder works on now, and People. The tab opens on the root and your own Problems. New Problem opens the picker’s form.
• Collaboration contains Deployments, Participants, and Publishing. Deployments searches and lists Workspace targets; Participants uses the RACI actor picker and assignment rows; Publishing keeps publish actions and patch history. Share, the arrow up out of a square in the Parable’s header, opens it on Participants, and shows Ponder’s column first when it is hidden. A Lab has no Share.
• Each Platform Parable that you can read is a view after these, with the Parable’s own mark. A Parable with no mark shows the first letter of its name. Select it to read that Parable above the conversation, as any reader reads it: its newest published Version, on Latest data, from its Home Page. Every Workspace has these views, and nobody sets them up. A Platform Parable that is not Visible in your Workspace, or that has no published Version, has no view. The Parable that is open has no view of its own, because it is already on the screen. The view does not change the address: a reload opens the view that the address names.

The view in front shows its name beside its icon, in capitals. The other views show only their icons, and their names show when you hold the pointer on them. While Ponder fills the column, no view is in front. When the column is narrow, such as on a phone, the views move to their own row under the Ponder title. If they do not fit, that row scrolls sideways, and the view in front stays in sight. Every Participation mode shows the same views. Problems needs Pinging responsibility or above, and Peeking and Pinging show Collaboration read-only. Select a view to reveal its tree or publishing details above the conversation. Right-click the Ponder header to choose what selecting it does. Exactly one choice is checked:

• Toggle Hide / Show Sidebar, the default: the header expands fully up and right, with no sidebar; select it again to go back to exactly the sidebar you left: the split with Pieces or Collaboration, or all Ponder.
• Toggle Sidebar Split: the header shows or hides the view above the conversation, and comes back to the height you left.

Your choice holds on every Parable, in this browser. The diagonal arrow always expands fully and comes back, as the first choice does. The vertical and horizontal arrows control each direction independently. All three arrows point toward their next action, and behave the same in Pieces and every Collaboration section. The arrows, Move and Hide show while the pointer is in Ponder’s column, or one of them has keyboard focus; they slide in from the header’s end and take no room otherwise. Each change of the column moves: widening or narrowing Ponder moves the edge between it and the Parable, and the full-size arrow moves that edge and the height together, diagonally. Hide slides Ponder out to its side and Show brings it back, Move passes it under the Parable to the other side, and whichever column changes width settles into it rather than jumping. With reduced motion, each change is immediate. Your Problem remains the thread across both layouts. The first breadcrumb shows the Parable’s glyph and title. Later Pieces show small, muted uppercase labels and chevrons. Their glyphs appear when you point at or focus the row. A link that names Changes or a Release a Workspace does not have opens what it can read: your draft while you edit, or the newest Release.

​

Release and Refresh

The top right of the Parable editor reads like a sentence: RELEASE Newest | REFRESH Latest (3d ago) | VIEW AS, one joined group. View as shows its caption and icon when your seat may use it. While Release is Newest and Refresh is Latest, with no Refresh running or marked, Release and Refresh fold behind one button at the end of the group, an info square; press it to show them, and it stays pressed while they show. View as stays in the group, next to that button, folded or not. Otherwise the group shows everything. While full-column Ponder hides the editor, the same control sits in Ponder’s header. On a phone both captions stay, so Newest and Latest are never confused, and Latest’s age drops. The trail beside it names the Parable and its Pieces only. Participation leads the same group, as its mode’s icon and name alone, such as Peeking, and the people here follow the group (see Collaborate without losing the thread). Release picks the published Version on screen. It lists the Releases published in this Workspace. The newest is Newest, the default; older ones go by their numbers, and a line with nothing published is v0. A Workspace that receives the Parable from another Workspace lists only the Releases it published itself, numbered after the source Release it builds on, such as v1.20+1. A newer Release from the source is not in its menu until the Workspace Pulls it and Publishes (Publish & Deploy). A Release with sets of Changes made from it has a chevron and opens on them, the way a Refresh opens on its Providers, below a back arrow to the Releases. The sets of Changes show as the Problem tree. Each set sits on the row of the Problem that holds it, indented under the Problems above it. The row shows the Problem’s icon, name and state, then the set’s owner, state and age. For example: Churn risk shows up too late · My Changes · Proposed · 2 hrs ago. The root Problem’s row uses the Parable’s name. A Problem that only carries a set under it reads muted. A Pocketed Problem that holds a set reads faded, with a Pocketed label. Sets whose Problem the tree does not show follow under In other Problems: you cannot see that Problem, or it is past the first 500. Sets that belong to no Problem, such as a Pull, follow under Not in a Problem. The search at the top of the menu finds a set by its Problem too. Choosing a set also opens its Problem in Ponder. Opening a Problem in Ponder opens its set when the menu lists one, a colleague’s set included. A set keeps one author, but the people who work in its Problem share it. When you are in Publishing or Primary and can see the Problem, a colleague’s set opens for you to edit, prepare, propose, pocket, restore and delete, as its author can. In Peeking and Pinging it opens read-only. A set that no Problem holds, such as a Pull, opens read-only for everyone but its author. You may hold several sets at once, one for each Problem. The tree shows how sets relate, but each set stands alone. A child Problem’s set starts from the newest Release, not from its parent’s Pending set, and it publishes on its own. When two sets change the same Piece, the set published second must re-apply its change. No set of Changes starts by itself. Opening a Parable, or switching it to Publishing, starts none. In Publishing, the page opens your Pending set when you hold one, and otherwise the newest Release. A set starts in one of three ways:

• Your first change, such as typing into a Piece’s read-only code, or creating, renaming or moving a Piece in the tree. That change only starts the set, and nothing is saved. Make it again once the editor turns editable.
• Start Changes: the Start row of the Release menu, the Start Changes button in a read-only editor’s band, or another control that opens your Changes.
• An edit that Ponder makes in a Problem.

Each start follows the Problem open in Ponder. When you hold a Pending set there, that set opens. In a Problem with no set yet, the Release opens on My Changes · Start a draft, which starts that Problem’s set. A Parable’s root Problem holds no set of its own, so in the root the Release opens on New Problem · Start Changes. The same row shows in a Pocketed Problem, and in a Problem whose set is someone else’s or no longer Pending. It opens the New Problem form, and the set starts in the new Problem once you create it. When you cancel the form, nothing starts. Nothing starts Changes during View as. Changes start in a Ponder Problem, so a seat without Ponder cannot start them. The Release on screen, and the set of Changes when one is open, lead the menu, ruled off above the list, and the reading on screen is checked before its chevron. Newest is not repeated there: it is always the list’s first row. Two sets that would read alike add the clock, or the date, that tells them apart. Hovering a Release shows when it was published, and hovering a set shows when it last changed, in your time zone and clock. The closed control names a set by itself, My Changes, when it was made from the default Release, and as v1.12 · My Changes otherwise. On hover, and for a screen reader, its name adds the Problem, such as Newest · My Changes · Churn risk shows up too late. Every mode shows Releases. Every participant sees every set that is not pocketed. A seat that may work in Publishing also sees its own pocketed sets and can start its own. Choosing a set moves it to Publishing. A seat that cannot opens a set read-only. The menu has a maximum height and scrolls, and a choice shows on the control at once while the page loads it. Resting the pointer or keyboard focus on a Release for a moment starts reading it, so the click finds it read or on its way. Switching is never silent. From the moment you pick a Release or a Refresh, a running bar beside the control says what is opening, such as Opening v1.5…, and the Page you are leaving is dimmed. A new Release’s Page takes the old one’s place once it has drawn; a Refresh’s data replaces the rows in place. The bar runs until the new reading’s data is on screen. Refresh picks the stored Report run, called a Refresh, that the Pages read. Latest is the default: the newest Refresh, with its age, and Pages read the server’s Current for it. When a Pipeline changed and no Refresh has completed since, Latest still reads Current: live Plots read live data, and a stored Plot with no Refresh that fits waits and reads again when one completes. While that Refresh runs, Latest says Refreshing…. For a Parable with no Pipeline, Latest is live Provider data, with no age. When a newer Refresh completes, Latest moves to it and the Pages read again. The menu leads with the Refresh on screen, as its row reads in the list, ruled off above its actions, unless it is Latest, which is always the list’s first row: Refresh runs the Report now, Preview runs it end to end on a sample of the data, on the newest Version or on the set of Changes on screen, Plan Refreshes schedules it, and Cancel Refresh stops one that is still running. A Preview is stored like a Refresh and listed with a Preview badge; choosing it shows the Pages on its outputs, and Latest never stands for one (Reports). Choosing Preview closes the menu and leaves the page where it was; the running bar follows it as it follows a Refresh, and the other actions stay available. They show only to a seat that may work in Publishing, and choosing one from Peeking or Pinging moves you to Publishing first. Changing a schedule takes the schedule permission, which only Parable staff hold; anyone else who chooses Plan Refreshes reads the schedule read-only, in the mode they are in. During View as they are hidden: the preview shows what the person viewed may do, and nothing on the page runs while it lasts. A refusal for the moment, such as a Refresh already running, keeps the actions visible and says why once below them. Below the actions, Latest, then this month’s Refreshes one line each, such as 3 mins ago or 2 hrs ago with a Failed badge, Older Refreshes in month folders, and a folder for each other Version whose Refreshes the Version on screen cannot read, such as v1.97 · 6 Refreshes: choosing one switches to that Version with it. Two Refreshes that would read alike add the clock, or the date, that tells them apart. Each row carries its exact time on hover and in its spoken name, such as Wednesday, October 7, 2026 at 12:31pm ET. The trigger marks only the Refresh being read: a chosen Refresh names its own state after its age, and Latest is marked when the Refresh it stands for did not succeed. The Refresh on screen is checked, before its chevron. Each row opens the Providers it read, each named for its product, such as BambooHR, with how old its data was in one line, such as Updated 5 days before Refresh, or Updated Live for a connector the catalog marks streaming whose data is at most five minutes old. Two connections of one Provider are each named for their connection. The connected Providers come first, each with a green plug, or the blue read-live mark when its connector streams, then a rule and the ones not connected. The menu has no search field to read past; arrow keys and typing still find a Refresh. It reads the Refreshes again each time it opens. While a Refresh is queued or running, the closed control turns a small spinner beside its label until the run finishes or fails. While a Refresh runs, a slim bar after the group estimates how far along it is, with Est. Time Remaining on hover and Cancel beside it, which shows Cancelling… until the run stops and Refresh cancelled for a few seconds after; a chosen Refresh that failed shows what failed and the way back where the Page was. A choice shows on the control at once. The Pages then read it without holding up the press, and the address records the choice once they show it. The address carries both choices, so a copied link reopens them: version pins a Release and refresh pins a Refresh by its run id. With neither, the page shows the newest Release published in this Workspace, and the Latest Refresh. A refresh the Parable has no Refresh for, such as one that left retention, another Parable’s or a typed word, is dropped once the Refreshes are read, and the page reads Latest. A pinned Failed or Cancelled Refresh stays pinned, and its Pages say it has no rows to read. Moving to another Parable or Workspace drops refresh. A Personal Parable has no Releases, and a Parable that takes no part in reporting has no Refresh control. When nothing has been published yet, Peeking and Pinging have no Version to read, so they open pending Changes instead of an empty page: your own open Changes first, otherwise a colleague’s that your seat on the Parable may open. Any participant opens any set that is not pocketed; a pocketed set opens only for its author. Opening a set never shows you more than the Parable’s current Policies allow: a set that removes or loosens a filter Policy still reads filtered until it is published. With none to open, the page says the Parable is not published yet. Changes are read-only there; switch to Publishing to edit them. Use Participation (the Active Participation Mode), first in the group at the Parable’s top right, when the Parable surface should match what you are doing now. Publishing keeps the authoring surface available, Pinging emphasizes clarification and collaboration, and Peeking keeps a reading-focused view. In Peeking you can still send Messages to Ponder in a Problem you can see. A Ponder turn runs with your permissions, so it saves no Changes. A mode can hide controls but cannot widen your current Workspace access or Parable responsibility. See Collaboration Modes. Personal Parables save edits directly. They show the same participation control as every Parable, and their Collaboration panel lists the participants alone. Personal means only you so far: a Personal Parable opens in Publishing and you edit it directly, and adding someone switches it to Published Versions. A choice in that control never switches it. The closed control shows only the mode’s icon and name, such as Peeking, and opens the same choices. Plan Refreshes opens the scheduling dialog. Without Ponder access, Search sits above the Pieces, and Participation, where your seat may change it, leads the same group at the editor’s top right.

​

Collaborate without losing the thread

When a connection resumes, Ponder continues after the updates this tab has already received. Delayed live updates do not replay those acknowledged changes. Current access still governs every update; losing access removes the reader from the affected conversation. The presence portraits just right of the group show who is here, and Share follows them (see the Collaboration view above). The portraits show everyone with this Parable open in Ponder, you included, and Ponder while it works on someone’s turn. A person appears within a few seconds of opening the Parable and leaves soon after closing it. Hover or focus a portrait or the overflow count to reveal one roster of names, recent activity, and locations; it opens toward the Release and Refresh group. A person in a Problem that you cannot open shows on the Parable, with no Problem. A portrait shows in full color when that person reads what you read: the same Problem, the same Release and the same Refresh, in a tab in front. Otherwise the portrait fades. The tab is in the background, or the person reads a different Problem, Release or Refresh. The roster then says what differs, such as In a background tab, On Release v1.3 or On Latest. Your own portrait always shows in full color. When a conversation grows long, Ponder condenses the older part of it and shows a Compacting the conversation… step in the reply. It keeps a summary of what came before and the newest Messages in full. Pictures work the same way: Ponder keeps the most recent ones in view and remembers that older ones were shared. Attach a picture again if Ponder needs to look at it once more. Messages remain in the Problem after you navigate away. Copy a link when a teammate should review a particular message. Use a Ping when you need a person to answer a question or be informed, and use Proofs when the result must be supported by evidence rather than agreement alone. Long Problems open at their newest Messages so the conversation is ready quickly. Choose Load earlier Messages at the top of the thread when you need older history; loading a page does not change or summarize the durable Messages. Ponder may propose changes or ask to use an action. Review the target and the effect before approving. A successful response is not the same as a published change: use Publish to inspect audience, responsibility, and readiness.

​

Everyone in a Problem shares its context

A Problem has one model context, shared by everyone who can see the Problem. What a tool returned on one person’s turn (query rows, a Piece’s source, a Pane picture, an administrative read) stays in that context, and the model can repeat it on another person’s turn. Sharing a Parable or a Problem is consent to share what Ponder reads inside it: the Problem is the permission boundary, not the person. Tools still run as the author of the Message Ponder is answering. Every call is checked against that person’s permissions and the Provider Policies that bind them, and an approval is theirs to give. A person who could not run a query cannot run it again through Ponder, but can read what the model already knows. If Ann reads every row of a table and Bob’s Provider Policy keeps only his own rows, Bob can ask Ponder to repeat the rows it read for Ann in a Problem he can see, and no read happens on his turn. Keep data that only some members may see, including tables a Provider Policy narrows, out of a shared Problem.

​

What changes and what stays with the Problem

​

When something does not work

​

Next