Documents vs tables

Both are items in your workspace, so both can live on a board, sit in your Library, be shared, and be read by Eve. The difference is shape. A document is one thing with paragraphs. A table is many things with columns.

The quick test

If you would want to sort or filter it, make it a table. If you would want to read it top to bottom, make it a document.

That single question settles most cases. "Which posts are still in draft?" is a sort. "What did I decide on that call?" is a read.

Use a document when

• You are writing something: a draft, an essay, a script, notes from a call.
• The content is prose, and the order of paragraphs matters more than any structure.
• There is one thing here, not many things.
• You want to ask Eve to read it, rewrite it, or pull ideas out of it.
• You want the piece to become a post later.

Documents also keep version history, so a rewrite is never a one-way door. See version history.

Use a table when

• You have many of the same kind of thing: posts, ideas, hooks, tasks, clients, sources.
• You want to answer questions like "which ones are done?" or "what is due this week?"
• You want columns: status, date, priority, platform, owner.
• You want to see the same list more than one way: as a list, a kanban board, or a calendar.
• You want to check things off.

A table's rows are real items, not just text in cells, which is why a table can track things that already exist in your Library. See tables.

How they work together

This is the part people miss. A table row can open into a full document.

In a table, hover a row's name and click the @ button, then pick New document from this row. Eden creates a document named after your row, links the two, and opens it. From then on, the row tracks the piece and the document holds the writing. Rename it inside the document and the row follows.

That gives you the normal setup for content work:

• The table is the pipeline: what exists, what stage it is at, when it goes out.
• The document is the work: the actual draft, one per row.

You can go the other way too. Add from library pulls something you already saved into the table as a row, so a document you wrote last week can join the pipeline without being copied.

Ask chat to build it

You do not have to lay a table out by hand. Describe what you want tracked and chat builds it for you, columns and rows together.

• "Build me a hook bank with tier, pillar, and status."
• "Make a content calendar with status, platform, and publish date."
• "Turn my ten essay ideas into a table I can mark done."

Name the columns you want, or leave them out and let chat pick sensible ones. Either way it says one line afterwards about the two judgment calls it made: what it put in the Name column, and how it grouped the rows.

What goes in the Name column

The Name column holds the thing itself. The idea, the hook, the essay title — whatever you would say out loud to point at that row.

It is not a slot and it is not a category. "Week 1" is a position, not a thing. So is a number, and so is a label you would use on several rows. Those all belong in their own columns, where you can sort and filter by them.

The test: if a value counts up, or would repeat across rows, it is a column, never a name.

Here is a season calendar built the wrong way:

Name	Week	Essay title
Week 1	1	The Second Renaissance
Week 2	2	Why taste is the new moat

And the same table built right:

Name	Week
The Second Renaissance	1
Why taste is the new moat	2

The Essay title column disappears, because the name was already the essay title. The Week column stays, because a week number is exactly the kind of thing you sort by.

A longer version of the same content can still have its own column. Just name that column for what makes it different — Script, Full text, Notes — never a second copy of the name. A hook bank names each row by the one-line hook and keeps the three-sentence version in a Script column.

Why the Name column has no rename

Every row is a real item in your workspace, and the Name column is that item's title. It is the name that shows on your board, in your Library, in search, and in any note that links to it. That is why the Name header has no rename or delete in its menu, while every other column does.

So a row's name has to work outside the table too. "Week 1" tells you nothing when it turns up in search. "The Second Renaissance" does.

It builds the table, not a document

Ask for a table and you get a table. That is always the default.

If the same answer also produced real strategy — the thinking behind the plan, not just the rows — chat offers a document at the end, in one line: "Want me to write this up as a doc with the table inside?" Say yes and you get the write-up with the live table sitting in it. Ignore it and you keep the table on its own.

Sometimes your own ask already contains the thinking. "Plan out my content season and give me the calendar" is a request for a plan, not just a list, so chat may go straight to a document with the table inside. When it does, it tells you first, in one line, before it starts. Nothing appears by surprise.

You can also start from writing you already have. "Pull these posts out of my note into a table" replaces the list in your note with a real table and leaves the prose around it alone. See tables.

Common setups

• Content calendar. Table with status, platform, and publish date columns. Each row opens into the draft.
• Hook bank. Table where each row is named for the hook itself, with a select column for the angle. No documents needed.
• Client work. One table per client, or one table with a client column. Rows link out to briefs and drafts.
• Meeting notes. Document. One per meeting. Nothing to sort.
• Research for one piece. Document, with the sources connected to it in your Library.
• Reading list. Table, using Add from library so saved links and PDFs become rows you can check off.

Still not sure?

Start with the document. It is the cheaper mistake.

A document that turns out to be a list can be broken into a table later, and each item becomes a row. A table built for a single piece of writing just gets in the way from the first minute. When the document grows a repeated pattern, that is your signal to build the table.

Where to go next

• For columns, layouts, and keyboard shortcuts, read tables.
• For the ways to make a document, read creating items directly in the Library.
• For scoping chat to your own material before you ask, read chatting with a board.
• To arrange either one for a project, read creating your first board.