Private Preview - features may change without notice
GramSpec
Architecture Spec API Reference Pricing About
Start free

Keep it true · 8

Who answers for a table

A model says what the business decided its data means. A steward is the named person who answers for one table of it. Naming them asks nothing of them and gives them nothing; it gives a question about that table somewhere to go.

Stewardship. One flow names a person against a table and tells them. The other sends a sentence somebody could not judge to that person, who reads it on Home after signing in.GRAMSPECYou, modelingSomeone reading themodelThe stewardmay have no account yetA table's stewardin Grammar, or many at oncein TeamA sentence in ReadAsk whoever answers for itSign-inmatched by emailStewardshipfinds the person, orholds a place for themAssignmentsby connection andtableThe feedlines addressed to apersonHomewhat is addressed toyou12341234 Stewardship. One flow names a person against a table and tells them. The other sends a sentence somebody could not judge to that person, who reads it on Home after signing in.GRAMSPECYou,modelingSomeonereadingthe modelThestewardmay have noaccount yetA table'sstewardA sentence inReadAsk whoeveranswers for itSign-inmatched by emailStewardshipAssignmentsby connectionand tableThe feedlines addressedto a personHomewhat isaddressed toyou12341234
Blue circles name a steward. Green squares are a question reaching them.

Naming a steward

  1. You name a person against a table. In Grammar, on the table's own panel, or in the Team panel for many tables at once: a name and an email. One person can be the default for every table on a connection, and a table's own steward overrides that default.
  2. The person is found, or a place is held for them. They need no account to be named, and being named gives them nothing: not the graph, not a board, not a row of data.
  3. The assignment is kept against the connection and the table, never in the graph. Two models built on one database cannot disagree about who answers for Customer, and a graph that is exported or served through the API carries nobody's email.
  4. They are told, with the table's sentences attached. A line addressed to them goes into the feed carrying the sentences that define the table, so they can read what they answer for without being given the graph. No email is sent; the line waits for them.

A question reaches them

  1. Someone reading the model cannot tell whether a sentence is true. From that sentence in Read they send it to whoever answers for the table it is about.
  2. The steward is looked up and the question is written to the feed. The table's own steward, otherwise the connection's default, otherwise nobody, which is an ordinary answer. Nothing becomes pending and nothing waits on a reply.
  3. The steward signs in. On every sign-in the account is matched by email to the place held for them. Their own name replaces the one that was typed, and the team sees that they have arrived.
  4. Home shows what is addressed to them. One list, newest first. The lines addressed to you are the unread ones.

What a steward is not. There is no sign-off, no approval and no “pending”. A steward is who to ask, and the model is exactly as true as it was before anyone asked.