Tables you fill in yourself

Some of what a business knows isn't in any system: who visited which store and what came of it, what a customer said on a call, the target each rep agreed to. A table you fill in keeps it as a table like any other, with columns you name and type. Dashboards, metrics, models, the assistant and your agents read it the way they read everything else, so "visits this month" is a number like any other.

What one is

• Columns you name, each with a type that is fixed when the table is made: text, a number, a date, yes or no, one of a list you give (Nina, Sarah), or a row of another table (a store, a customer, a product, picked by its name).
• Columns it keeps for you: a number for each row, who added it and when, and who changed it last and when. Nobody can put another name there.
• A value that doesn't fit is refused with the reason, and nothing is written: a word where a number goes, a date that isn't one, a store that isn't in the stores table. All of a date is read: 2026-10-10 is a date, and so is 2026-10-10 09:15 (its day is kept), but 2026-10-10x is refused, never cut short.
• One row per something, if you say so when you make it (one row per store per day): adding the same store and day again changes that row instead of adding a second.
• In Data it has its own mark, a grid with a pencil, its count is the rows it holds right now, and its page's Columns say what each column holds.

Fields, or a table of your own?

Fields sit beside the rows of a table that comes from somewhere else: a checkbox on a Shopify order, a note on an invoice (Your fields on any table). A table you fill in is rows of your own, where each visit, each call, each target is a new row. A table that comes from a source, a file or a model never becomes one, and only its own doors write one, so every row says who and when. Sending it to the trash and bringing it back keeps it a table you fill in.

Who adds, fixes and deletes rows

• Anyone who can change your data adds rows: an admin, a teammate who sees everything, an agent's key that writes the dataset.
• Through a dashboard's form, anyone who can see that dashboard adds rows, even someone whose group sees only a few dashboards, with their own name on the row. That's the only way in for them: they still can't read the table itself or anything else. A form or list that isn't on the published page, taken off or only commented out of its code, opens nothing.
• A row is fixed or deleted by an admin, or by whoever added it. A sales rep can correct their own visit; only an admin can change a colleague's. Click a row in the page's list and its panel says who added it and who changed it last, and under that What changed: every change, newest first, with who, when and what each value went from and to.
• Adding rows at once, up to 1,000, is one step: every store in it is looked up, and if one row doesn't fit, none are added, and the message says which row and why.
• A deleted row isn't lost without a trace. Its history, read through the API (GET /tables/{dataset}/{table}/rows/{id}/history), says who added it, every change and when, with what each value was and became (a change made by adding the same store and day again too), who deleted it, and what it held. The table as it was is kept for 30 days, like every table.
• An agent's key that sees a dataset with personal details hidden sees them hidden here too: in a row's history, and in the names of a linked table's rows. It picks such a row by its number, not by a name it can't see.
• After a row is added, changed or deleted, every number that reads the table is worked out again, so a dashboard showing "visits this month" moves with it.

On a dashboard

Put the table's form on a dashboard and the people who use that page fill it in there: "Log a store visit" with its fields (a date that starts at today, a pick-list for a store, Yes for an order taken, a note), and beside it the visits so far, newest first, a long note cut short to fit. Show more, under the list, brings the next 500 and says how many are left, down to the very first visit. Click a visit to open it, all of its note with it: whoever added it, or an admin, can fix it or delete it there; anyone else reads it. When the table keeps one row per store per day, adding a visit that is already there changes it, and the form says Changed instead of Added; added again with nothing different, it changes nothing, and the form says Already there. Someone whose group sees only that dashboard adds visits through it and nowhere else, and each visit carries their name. The page's numbers (visits this month) move as soon as a visit is added. Ask the assistant to add the form, or your agent with the dashboard skill.

Ask for it in plain words

The assistant makes the table, adds rows, fixes and deletes them, and says what it did: the rows it added and their numbers, or the reason a value didn't fit. It writes only when you ask, as you, and never into a table that comes from somewhere else. Your agent on a laptop does the same over MCP, and the CLI has ovs table make --entered and ovs rows. A table's columns and links are fixed once it's made, so the assistant asks which table a link points at when two could be meant, and a wrong one is put right with a new table. Someone whose group sees only the dashboard who asks their chat to add a visit is told, in one sentence, to use the dashboard's form.