Sitting

Read one topic of the user's knowledge base end to end, in publication order — as standing research queries, a briefing, a trajectory, or a search for what contradicts or is missing from it.

Reach for this when the user wants to know what their saved material actually SAYS about a subject over time — "what have I been collecting on agentic payments", "how has the thinking on X moved", "read everything I've saved about Y", "what's in my blind spots". It is the opposite of the search tool: search finds the few best-matching items, this assembles EVERY item on a topic and reads the whole set in date order. Search answers "where is it"; this answers "what happened".

Do not reach for it to look something up, to answer a factual question, or to find a specific post — that is the knowledge-base search tool, and it is free and instant. This assembles a large context and, on read, makes a model call (the other actions do not).

The five actions:

• preview (FREE, the default) — name a topic and find out what is actually there. It grows the region and reports its size, the stretch of time it covers, how many people wrote it, a few of the items by name, and anything about its shape that would make a read disappointing. It calls no model. Costs one metered embedding for a typed phrase (a fraction of a cent) and nothing else. This is not a permission step. It is here because a phrase can resolve to four items or to two hundred and the user cannot tell which in advance — the size is a property of what they have saved, not of the words they typed. Skip it whenever the user has already said to go ahead. A preview alone queues nothing — consumption subscribes a region, construction does not. Nothing reads it, and nothing spends, until read or lens actually consumes it.

• read (SPENDS) — reads the assembled region with a model. A topic too big for one sitting is read in PARTS, oldest stretch first; each read carries forward the claims every earlier part established and is asked to confirm, revise or refute them. Two lenses, pick with lens: - queries (default) — emits standing research queries from the material. Those then run on a schedule against papers, repos and datasets, catching what gets published NEXT in that thread. - claims — extracts 8-15 falsifiable claims the material actually makes, each one naming specifics (systems, numbers, dates), citing every atom that supports it, and stating what observation would prove it WRONG. Use this when the user wants to know what their saved material actually establishes, not what to watch next. Pass a sitting_id from a preview, or pass query to build and read in one step. The two lenses spend and read INDEPENDENTLY — reading a region for claims does not use up or block its queries read, and the reverse holds too.

• render (FREE) — hand back a region that was already built, as the document a reader would see. Nothing is re-grown and nothing is re-read.

• watchlist (FREE) — the standing questions currently being watched on the user's behalf, with how often each runs, how many times it has come up, and whether the user typed it or a read of their material proposed it. Pass a sitting_id or query to see one region's; pass neither for everything. SHOW THIS ONLY WHEN ASKED — "what am I watching", "show my watchlist", "did anything change". Never volunteer it at the start of a session or alongside unrelated work. add puts questions the user names onto the list; those never decay and are removed only by drop. drop retires a question EVERYWHERE — a question two regions both watch is retired for both, because the list is one list of questions, not a copy per region. Say so before dropping something the user did not name precisely.

• lens (SPENDS only on material never lensed before) — hand back an instruction plus a document, and read them YOURSELF, right here in this conversation, to answer the user directly. This is how you answer a question ABOUT the material rather than generating queries against it. The document is NOT the region's raw text. A topic read across several sittings is summarised one stretch at a time, and what comes back is those summaries labelled with the dates they cover — so you are joining stretches, not re-reading everything. Each stretch is summarised once ever, so asking the same lens again is free, and asking a DIFFERENT question of the same lens is free too. Only material that has never been lensed this way costs anything. Pass lens to pick which reading: - briefing — what this material actually says, as knowledge, not a table of contents. - trajectory — how the thinking on this topic MOVED over time: what changed, reversed, or got abandoned. - disconfirmation — what in this material would UNDERMINE a belief. Pass claim with the belief being tested; without one, it red-teams the material's own apparent thesis. - gaps — answer a question using only this material, and if nothing here answers it, the CLOSEST it comes and why that falls short (never a bare "nothing here"). Pass claim as the question. - sprouts — everything no sitting has ever read: true orphans, unread regions, fracture leftovers. This is what "what's in my blind spots" means. Needs no sitting_id, query, or atom_ids — it is not about one topic. Like read, pass a sitting_id from a preview or a query/atom_ids to build one in the same call (sprouts needs neither). The answer YOU give is never written anywhere — no queries, no table, no record of it — because it is about the topic as it stands today and would be wrong the moment anything is added. This is a conversation, not a rail.

What comes back from a read, lens queries: a consensus — how the conversation moved, what reversed, what is unresolved — plus the queries it emitted. Show the user the consensus. It is the part written for a human.

What comes back from a read, lens claims: a claims list, each one {claim, falsified_by, atom_ids}. Show the user the claims themselves — falsified_by is what lets them decide whether to believe one, so surface it alongside the claim rather than dropping it.

What comes back from a lens: instruction and document. Read document following instruction and write the answer yourself — there is no second call to make, and nothing here reads the document for you.

Read the warnings in a preview back to the user. They say when a region is a poor fit for the question — a region spanning three days has no arc to find, a region that is 85% one author generates queries pointing back at that author's own work. Pass the lens you intend to use to preview and the warnings are specific to it (a short span breaks trajectory and barely touches briefing). They are advisory: nothing here refuses to read, because whether the region is right depends on what the user is asking and only they know that.

A region is read once per lens (by read). A second read of the same sitting_id with the SAME lens is refused as already read — it would be the same input for the same money. The two read lenses do not share this guard: a region read for queries can still be read for claims, and the reverse. A region is re-read (same lens) when it has GAINED enough new material to be worth redoing, and the rail decides that on its own; to force it, preview the same phrase again, which grows a fresh region over the corpus as it is NOW. lens (the action) has no such limit — each stretch is summarised once and reused after that, so reading the same region's briefing twice costs nothing the second time.