Skip to main content
A base is a live view over the other documents in your brain. Its rows are documents, gathered fresh every time you open it. That is the whole idea: a base stores the question, never the answer. “Every competitor profile we have.” “Research notes nobody has touched in 30 days.” “Every customer document without an owner.” Write a matching document tomorrow and it appears in the base on its own, with nobody maintaining a list.
This is the difference between a base and a table. A table’s rows are data you typed into it. A base’s rows are documents that already exist. Both look like a grid — choose by what a row means.

Creating a base

Ask your agent, and describe the view in plain words:
“Give me a base of all our competitor profiles, with their tier and estimated revenue as columns, sorted by revenue.”
“Make me a review queue — every document in the research folder that hasn’t been updated in a month.”
Bases are the one format that is genuinely easier to describe than to build, which is why there is no menu item for them. You are specifying a question about your brain — how documents get selected, what gets shown, how it is sorted and grouped — and that is a sentence, not a form. Your agent turns it into the view and maintains it for you afterwards: ask for another column, a second tab, a tighter filter, and it adjusts.

What a base can express

  • Which documents appear. By type, by folder, by tags, by owner, by how recently they were touched, or by any extra property your documents carry — including time-based questions like “not reviewed in the last 30 days”.
  • What is shown about each one. Any of a document’s properties — title, description, type, tags, folder, created, updated — plus any extra property. Columns can be given a type, which decides how they sort and what can be totalled.
  • How it is arranged. Sorting, grouping, column order, and per-column summaries such as counts, sums, averages, and date ranges.
  • Several views at once. One base can hold multiple tabs over the same set of documents, each with its own filters and layout — “All competitors” beside “Needs review”.

Working with a base

The rows are read live from your brain as it is right now. The grid fills the page. Above it sits a strip carrying the base’s title and a count of what matched: 144 results, or 20 of 37 results when the view shows only the first so many. A base with more than one view shows a tab per view there too, and Sort, Filter, Columns, Group, and New sit at the right of the strip when you have edit access. Scroll down and the column headings stay put. Scroll sideways and the first column stays with them. When the view is grouped, each group’s label stays in sight while you read through it. Rows are one line each: anything too long for its column is cut short, and hovering the cell shows the whole value. Each row’s title is a link to the document behind it. Click it to open that document, or open it in a new tab the way you would any other link. Editing a cell edits the document in that row, not the base — that is the part worth internalising. Changing a tier, an owner, or a review date in the grid writes it to the real document. If the change is refused, the cell reverts and the app tells you why. It makes a base a genuinely fast way to bring a whole set of documents up to date in one pass. The title is the one cell you cannot edit here, since it is the row’s link. Rename a document in the document itself. Adding a row creates a real document, pre-filled so that it belongs in the view you created it from: its folder, type, tags, and properties are set so it satisfies the view’s filters and therefore appears in it. A base document has no properties rail and no width control — the grid is the page. Its title shows in the strip above the grid, but is read-only there. Rename it from the sidebar.

Data tables

A grid whose rows are data kept in the document itself.

Dashboards

A composed homepage built from the same kind of live questions.