mainsequence-metatable 0.1.45__tar.gz → 0.1.46.dev73__tar.gz

{mainsequence_metatable-0.1.45 → mainsequence_metatable-0.1.46.dev73}/.agents/skills/client/metatables-meta-tables/SKILL.md

@@ -109,7 +109,7 @@ revisions; do not recompute identity from columns or rewrite applied history.
 Read `docs/client/query-and-mutate.md` and `src/metatables/examples/query.py`. Use
 `compile_sqlalchemy_statement` with bound parameters. The request sends SQL and
 selects one DataSource; the API executes as the authenticated user, and the
-selected database backend enforces Reader/Writer permissions on the tables
+selected database backend enforces the caller's roles (`data_viewer` reads, `data_writer` and above write) on the tables
 actually touched. The API does not parse SQL for authorization. The compiler can
 resolve DataSource and dialect from the selected runtime; supply both explicitly
 for offline compilation. Preserve execution mode, row limits and timeouts.
@@ -129,14 +129,16 @@ to the separate migration-provider workflow.
 To find tables, use `MetaTable.search` as described in the
 [table discovery skill](../metatables-table-discovery/SKILL.md). Legacy convenience
 sharing/label actions are not supported API workflows.
-Use `get_access`, `set_access` and `revoke_access` for supported Reader/Writer
-sharing. Labels can be changed through the documented table PATCH path. Authorization is
-owned by the API catalog; see `docs/concepts/permissions-namespaces-labels.md`.
+Use `get_access`, `grant_role`, `revoke_role`, `allowed_actions` and `explain` on a
+table or `Namespace` for roles (`metadata_viewer`, `data_viewer`, `data_writer`,
+`editor`, `owner`); `Namespace.create(name)` makes the caller its owner. Labels can be
+changed through the documented table PATCH path. Authorization is owned by the API
+catalog; see `docs/security/ownership-and-sharing.md`.
 
 Updater output rollback uses `TimeIndexMetaTable.delete_after_date` with an
 inclusive time cutoff and explicit dimension/coordinate scope when appropriate.
 A null cutoff requires a scope. Do not replace that workflow with ad hoc SQL.
-Deletion/cascade requires edit access, relevant protection checks, and explicit
+Deletion/cascade requires `tables.delete` (`editor`), relevant protection checks, and explicit
 cascade intent; it is not an administrator-role bypass or migration repair.
 
 Before a destructive action, or to show impact in an application UI, call
@@ -144,12 +146,12 @@ Before a destructive action, or to show impact in an application UI, call
 The API returns whether the caller may run it, every blocker, and a graph of
 affected tables, foreign-key effects and reading updates; render that result
 rather than re-deriving foreign-key or permission rules in the client. Cascading
-foreign keys are allowed. Write on a table depends only on its own grants; the
+foreign keys are allowed. Write on a table depends only on its own roles; the
 cascade effects in the result are information, never a reason the action is blocked.
 
 On a TimescaleDB DataSource, time-index tables are hypertables. Their compression
 and retention policies are set only through `TimeIndexMetaTable.set_timescale_policies`
-(Writer) and read with `get_timescale_policies`. Do not add policies to table
+(`tables.update`, `editor`) and read with `get_timescale_policies`. Do not add policies to table
 contracts or Alembic revisions; to keep them in code, call the client from a
 bootstrap Job. Retention permanently drops older chunks, including backfills.
 

{mainsequence_metatable-0.1.45 → mainsequence_metatable-0.1.46.dev73}/.agents/skills/client/metatables-migrations/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: metatables-migrations
-description: "Create and evolve managed application tables through Alembic migration providers with the installed MetaTables Python client. Covers provider scope and placement, scaffolding, revision authoring, local execution, the deployment-workflow migration Job for hosted runtimes, the Team that owns an application's tables in each Environment, and reservation or finalization failures. Excludes API catalog migrations, client-library implementation, API/server changes and repository tooling."
+description: "Create and evolve managed application tables through Alembic migration providers with the installed MetaTables Python client. Covers provider scope and placement, scaffolding, revision authoring, local execution, the deployment-workflow migration Job for hosted runtimes, the namespace and roles that give the Job access in each Environment, and reservation or finalization failures. Excludes API catalog migrations, client-library implementation, API/server changes and repository tooling."
 ---
 
 # MetaTables client application migrations
@@ -46,17 +46,15 @@ migrations. Read `docs/client/deploy-application-migrations.md`.
 1. **Develop locally.** Author the revision and apply it to verified local SQLite
    with the [local development skill](../metatables-local-development/SKILL.md).
 2. **Commit the revision with the code that needs it.**
-3. **Give a Team the tables.** Before the first hosted migration in each
-   Environment, the application's tables need an owning Team: one platform Team
-   per Environment (for example `ledger-development`), whose members are the
-   migration Job's workload User and the workload User of every resource that
-   reads or writes the tables. An Organization admin creates, in that
-   Environment, each namespace the provider registers tables in, and grants the
-   Team Writer on it. Recommend one namespace per application, owned by its Team;
-   it is not required (see "Namespaces and applications" in
-   `docs/security/ownership-and-sharing.md`).
-   Tell the user these steps; they are made in the platform and in MetaTables
-   Security, not in the repository.
+3. **Give the Job access.** Before the first hosted migration in each
+   Environment, a person (no admin needed) creates each namespace the provider
+   creates tables in, with `Namespace.create(name)` or the Admin, and becomes its
+   `owner`. As owner they grant `editor` to the migration Job's workload User and
+   `data_writer` to resources that only read and write rows, directly or through a
+   Team they belong to that contains those workloads. Recommend one namespace per
+   application; it is not required (see "Namespaces and applications" in
+   `docs/security/ownership-and-sharing.md`). Tell the user these steps; they are
+   made in MetaTables (and, for a Team, the platform), not in the repository.
 4. **Deploy.** The application's `.mainsequence/workflows/` file declares a
    migration Job that calls `upgrade_application` for each provider, in
    dependency order, from the candidate image. The Job and every resource that
@@ -78,13 +76,14 @@ Rules:
   during and after a failed rollout. Add first; drop or rename in a later release.
 - Redeploying an older image does not roll back the schema. Downgrade is never a
   deployment step.
-- Tables belong to the Team, never to one workload User. Workload Users change
-  with each Environment and each recreated Job; a new one needs Team membership
-  only. Do not ask for direct table grants to a workload User, and do not run the
-  Job as an Organization admin to get around a refusal.
-- A table registered in a namespace the caller already writes gets no grant of
-  its own; the namespace's Writers own it. The Team needs Writer on every
-  namespace the provider uses.
+- Tables belong to their namespace's roles, never to one workload User. A table
+  created in a namespace gets no binding of its own. Workloads cannot create tables
+  outside a namespace (`namespace_required`). Workload Users change with each
+  Environment and each recreated Job: a direct role needs granting again, a Team
+  only membership. Do not run the Job as an Organization admin to get around a
+  refusal.
+- The Job needs `editor` on every namespace the provider uses; resources that only
+  read and write rows need `data_writer`.
 
 ## Source and runtime context
 
@@ -182,7 +181,7 @@ branch on `op.get_bind().dialect.name`.
 The client imports and executes application revisions, using the connection
 resolved for the selected environment. Environment operators supply the database
 login's DDL privileges. MetaTables does not mint migration roles or sandbox DDL.
-API Writer checks govern connection admission and provider catalog operations.
+API `tables.migrate` checks govern connection admission and provider catalog operations.
 The client reserves catalog entries, runs Alembic, closes its physical connection,
 and finalizes contracts through the API. Treat connection material as private.
 
@@ -252,13 +251,12 @@ Read `docs/operations/recovery-and-observability.md`.
   another install overwrote it. Move the provider under an application-owned
   module (see [Provider placement](#provider-placement)), preserving its provider
   identity and applied revision history. Do not edit files in `site-packages`.
-- If reservation fails with `namespace_not_writable` or `table_not_editable`
-  (403), the caller lacks Writer through the owning Team. Add the
-  `caller_user_uid` from the error to the Team with Writer on the namespace, or,
-  when the namespace or Team is missing, set them up as in step 3. A table
-  registered before the Team existed may have only a retired workload User as
-  Writer; an Organization admin grants the Team Writer on its namespace. Do not
-  change code or physical names to get around it.
+- If reservation fails with `namespace_not_found` (403), create the namespace and
+  grant the Job `editor`, as in step 3. With `namespace_access_required`, an owner
+  the error lists grants the `caller_user_uid` `editor` on the namespace, or adds it
+  to a Team that holds it. With `namespace_required`, set the table's namespace.
+  With `table_not_editable`, an owner of the table or its namespace grants `editor`.
+  Do not change code or physical names to get around it.
 - If reservation fails otherwise, compare provider scope and physical identities
   before changing code. Do not create a second catalog row for the same table.
 - If Alembic succeeds but finalization fails, physical DDL may already be
@@ -296,5 +294,5 @@ Read `docs/operations/recovery-and-observability.md`.
 Verify provider scope and placement, revision content, the selected environment
 connection, repeat execution, and final active bindings. Check that the deployment
 workflow runs the migration Job before every resource that uses the tables, and
-that each Environment has its owning Team with the Job's workload User. Report
+that each Environment's namespaces grant the Job's workload User `editor`. Report
 separately what was checked offline and what was exercised against a configured API.

{mainsequence_metatable-0.1.45 → mainsequence_metatable-0.1.46.dev73}/.agents/skills/client/metatables-table-discovery/SKILL.md

@@ -154,7 +154,7 @@ key, the time index and the identity dimensions.
   table is published.
 - `__metatable_namespace__` is the owning application or source, not a SQL schema.
   Its description (one or two sentences about the application or source) is
-  written once by the namespace's Writer; do not repeat it in table descriptions.
+  written once by someone with `editor` on the namespace; do not repeat it in table descriptions.
 
 ### Time-index tables, in addition
 

{mainsequence_metatable-0.1.45 → mainsequence_metatable-0.1.46.dev73}/.agents/skills/ms_tau_sdk/PINNED_FROM.txt

@@ -1,7 +1,7 @@
 schema=1
 library_name=ms-tau-sdk
 namespace=ms_tau_sdk
-pinned_version=2.0.16
+pinned_version=2.0.18
 skills_path=src/ms_tau_sdk/agent_skills
 skills=tau_a2a_runtime_adapter,tau_local_development,tau_project_customization,tau_repository_integration,tau_security_and_access
 command=ms-tau skills sync --path .

{mainsequence_metatable-0.1.45 → mainsequence_metatable-0.1.46.dev73}/.agents/skills/ms_tau_sdk/tau_project_customization/SKILL.md

@@ -161,7 +161,7 @@ async def revenue_by_region(tool_call_id, arguments, signal=None, on_update=None
 - `current_requester()` returns the person the turn serves, with `uid` and
   `await in_teams(team_uids, *, max_age_seconds=None)`, or `None`. `in_teams()` answers while the
   person is the verified caller of the turn's request (see `tau_security_and_access`, "Checking the
-  person's teams"); `team_uids` is deprecated. The platform names that person when the turn
+  person's teams"); the person carries no team list. The platform names that person when the turn
   starts, whoever called; it is `None` when the platform names nobody, in local mode, and in code
   outside a turn. Only it names the requester: never take a person's UID from tool arguments, the
   prompt, history, or a header.
@@ -184,7 +184,7 @@ Rules for tools that act for the requester:
   a URL, and never sets `Authorization` or an `X-MainSequence-*` header.
 - A delegated call uses the person's ordinary permissions, including administrative ones; any other
   call uses the Agent's own. Each operation decides what it needs. Never infer write permission
-  from view access.
+  from read access.
 - Return to the model only business results, such as rows, numbers, and names. Never return the
   response object, its headers, a token, a proof, or a raw error body.
 - Keep nothing for another turn or another person. The delegation ends with the turn, and a task

{mainsequence_metatable-0.1.45 → mainsequence_metatable-0.1.46.dev73}/.agents/skills/ms_tau_sdk/tau_security_and_access/SKILL.md

@@ -163,8 +163,9 @@ What makes it safe:
 
 - No tool takes a Secret value or a Secret name from the model. The name is built from
   `current_requester().uid`, so prompt injection cannot point the tool at another Secret.
-- `delegation="required"` reads the Secret as the person. The platform returns it only if the
-  person can view it; the name is a lookup key, not the protection.
+- `delegation="required"` reads the Secret as the person. The platform returns the value only if
+  the person holds `value_reader`, `editor` or `owner` on it; the name is a lookup key, not the
+  protection.
 - The value exists only inside one call. It never goes into the result, `details`, a log, an
   exception message, a file or a cache for the next turn. It travels in a header, never in a URL,
   because URLs reach logs. Errors from the outside call are caught, and the provider's raw body is
@@ -178,19 +179,19 @@ What makes it safe:
 
 A delegated read returns anything the person can view in the Agent's Environment: what they
 created and what others shared with them, directly or through a team. This holds for Secrets and
-other shared resources. Ordinary Teams use explicit membership: the creator is added once and
-can be removed; current Organization admins are protected writer members. Removing the admin
-role keeps membership and writer access but ends protection. Only Organization admins manage
-membership, and managing a workload that created a Team does not grant Team control. A Team's
-members still receive the resources shared with it. The Full directory remains unchanged.
-See the SDK Security and access guide's **Teams and membership** section for platform rollout.
-The platform enforces sharing; which of those objects a tool uses is part of
-the tool's design. For Secrets, the naming convention states that design:
+other shared resources. A team's members receive what is shared with it, and `in_teams()` answers
+membership. Who can see and manage a team is decided separately, by the `viewer`,
+`membership_manager`, `editor` and `owner` policies on it: any person can create a team and
+becomes its owner and first member, members can see the team and leave it, and Organization admins
+manage every team from their role, without being members. No membership is protected. See the SDK
+Security and access guide's **Teams and membership** section. The platform enforces sharing;
+which of those objects a tool uses is part of the tool's design. For Secrets, the naming
+convention states that design:
 
 - **A personal credential:** a name tied to the person, such as `QUOTES_API_KEY__<person uid>`.
   The person decides whether to share it.
-- **A team credential:** a name the team agrees on, shared with the team for view. The tool reads
-  it for any member.
+- **A team credential:** a name the team agrees on, with `value_reader` attached to the team. The
+  tool reads it for any member.
 - **Someone else's Secret shared with the person:** valid whenever the tool is meant to use it.
 
 Whoever can edit a Secret decides its value, so the tool uses whatever value they set. Granting or
@@ -199,13 +200,68 @@ decision people make through sharing, not one the platform makes for them.
 
 How sharing works:
 
-- The creator of a Secret can always view and edit it, and cannot be removed from it. People who
-  can edit a Secret can share it, for view or for edit, with people and teams.
-- Most people can share only within the teams they belong to; Organization admins can share
-  across their Organization.
-- `GET /api/v1/secrets/<uid>/can-view/` and `can-edit/` list the people and teams with access. A
-  tool can use them when its design needs to, for example to refuse a team key where it expects a
-  personal one. That is a choice of the tool, not a platform rule.
+- Policies on a Secret decide access: `reader` sees that it exists and its name, never its value;
+  `value_reader` also reads the current value; `editor` also reads earlier values, sets a new value,
+  deletes it and sees who has access; `owner` also decides who has access. The creator becomes its
+  owner, and Organization admins hold every policy on their Organization's Secrets from their role.
+- Owners attach and detach these policies for people, teams and workloads; whoever manages a
+  workload can also give it a policy they hold, and anyone can remove their own. No policy is
+  protected: an owner can remove the creator's. Nobody gives a policy with more than they hold, and
+  people other than Organization admins give access only to people who share an active team with
+  them, to teams they belong to and to workloads they can view.
+- `GET /api/v1/secrets/<uid>/access/` lists who holds which policy, for editors and owners, and
+  `GET /api/v1/secrets/<uid>/access/me/` answers what the caller may do with it. A tool can use
+  them when its design needs to, for example to refuse a team key where it expects a personal one.
+  That is a choice of the tool, not a platform rule.
+
+## Model providers
+
+The model a session runs on uses a provider credential or custom endpoint that the session owner
+may use; a delegated child session uses its parent's owner. A policy that only the Agent's workload
+holds does not count in a person's session. Policies on the record decide who may use it, held
+directly or through a team:
+
+- `user` uses it: a credential is selected and delivered to sessions and workloads, including local
+  Tau, and a custom endpoint receives their requests.
+- `editor` also refreshes, reconnects or revokes a credential, or changes or deletes an endpoint,
+  and sees who has access; `owner` also decides who has access.
+- The credential's person and the endpoint's creator hold `owner`, and Organization admins hold
+  every action on their Organization's records. Owners give and remove the policies in Command
+  Center's provider settings or through `/api/v1/model-provider-credentials/<uid>/access/` and
+  `/api/v1/custom-model-providers/<uid>/access/`; a refused change answers `403` `missing_action`
+  with the `granting_policies` that would allow it.
+
+Holding `user` delivers the credential, or the endpoint's stored authentication, to the holder's own
+runtime, including local Tau, where it can be copied; removing the policy stops later deliveries,
+not copies already made. To let a team run an Agent on one credential, its owner gives the team
+`user`.
+
+## Agents
+
+Policies on an Agent decide who may talk to it and manage it, held directly or through a team:
+
+- `user` talks to it and gives it Tasks, seeing only the Tasks they asked for; `viewer` also sees
+  every Task of the Agent with its requests and results; `operator` also stops any Task or
+  conversation run, other people's included; `editor` also configures it, moves it to a new runtime
+  build, deletes it, manages what its workload can reach and sees who has access; `owner` also
+  decides who has access.
+- A conversation stays its owner's: no Agent policy, `owner` included, reads another person's
+  conversation (Organization admins can read it, never change it), and only a Task's requesters
+  continue it. On an Agent that acts for its requester, a Task is visible only to its requesters
+  and Organization admins.
+- Whoever creates an Agent holds `owner`, and Organization admins hold every action on their
+  Organization's Agents. Owners give and remove the policies through
+  `/api/v1/agents/<uid>/access/`; a refused change answers `403` `missing_action` with the
+  `granting_policies` that would allow it, and an Agent the caller holds no policy on answers `404`.
+- The release an Agent runs on takes no policy of its own: `viewer` and `operator` on the Agent see
+  it, and `editor` and `owner` change it.
+
+A tool reaches Agents and their Tasks with the caller's policies: the person's in a delegated call,
+the Agent's workload's otherwise. To send another Agent work without a delegation, the workload
+needs its own policy on that Agent, declared under `access.agents` in its workflow file, usually
+`policy: user`. Calling another application with `call_release()` needs a policy on its release
+that includes calling it (`resource-releases.invoke`, which every release policy has), and the
+platform checks it again on every call.
 
 ## Checking the person's teams
 
@@ -220,7 +276,9 @@ if person is None or REPORTS_TEAM_UID not in await person.in_teams([REPORTS_TEAM
 ```
 
 - `await in_teams(team_uids, *, max_age_seconds=None)` returns the subset of `team_uids` the
-  person is an active member of, as a `frozenset`. Unknown and inactive teams are left out.
+  person is an active member of, as a `frozenset`. Unknown and inactive teams are left out, and so
+  is a team the person only manages: managing a team, also as an Organization admin, does not make
+  anyone a member.
 - On the turn's requester it answers only while that person is the verified caller of the request
   the turn runs in, such as a chat or A2A Message they sent. A turn with no such request raises
   `TauSDKError`: a Task attempt the platform dispatches, a turn that resumes a caller delivery, or
@@ -230,9 +288,7 @@ if person is None or REPORTS_TEAM_UID not in await person.in_teams([REPORTS_TEAM
   `0`: only within its request); set it in `harness_agent.spec.env_vars`. `max_age_seconds=0`
   always asks the platform: use it before a write that must see a removal at once.
 - A check the platform cannot answer raises `BackendError`; it never answers "not a member".
-- `team_uids` on the requester is deprecated and warns when read. It is empty when the turn does
-  not know the person's teams, and raises when the caller's assertion carried no team list, as
-  every assertion will once the platform stops signing them. Use `in_teams()`.
+- The requester carries no team list; `in_teams()` is the only membership check.
 
 ## What never reaches the model
 
@@ -274,4 +330,5 @@ Patch the extension module's `current_requester` and `platform_client` with fake
 - Secret values stay inside one call, in headers, never in results, logs, errors, URLs or caches.
 - The naming convention says whose Secrets the tool uses, and the people sharing them know it.
 - A refused delegated call is reported, never retried as the Agent.
-- The Agent's workload holds no grants it does not need, and none on people's Secrets.
+- The Agent's workload holds no grants it does not need, and none on people's Secrets; `user` is
+  enough on an Agent it only sends work to.

{mainsequence_metatable-0.1.45/src/mainsequence_metatable.egg-info → mainsequence_metatable-0.1.46.dev73}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: mainsequence-metatable
-Version: 0.1.45
+Version: 0.1.46.dev73
 Summary: Main Sequence MetaTables Python client and standalone API
 Author-email: Main Sequence GmbH <dev@main-sequence.io>
 License-Expression: MIT
@@ -14,7 +14,7 @@ Classifier: Operating System :: OS Independent
 Requires-Python: >=3.13
 Description-Content-Type: text/markdown
 License-File: LICENSE
-Requires-Dist: mainsequence[mcp]<10,>=9.0.27
+Requires-Dist: mainsequence[mcp]<10,>=9.0.29
 Requires-Dist: alembic<2,>=1.18
 Requires-Dist: cachetools
 Requires-Dist: cryptography<51,>=46
@@ -51,7 +51,7 @@ Requires-Dist: twine<7,>=6; extra == "dev"
 Provides-Extra: docs
 Requires-Dist: mkdocs<2,>=1.6; extra == "docs"
 Provides-Extra: agent
-Requires-Dist: ms-tau-sdk==2.0.16; extra == "agent"
+Requires-Dist: ms-tau-sdk==2.0.18; extra == "agent"
 Provides-Extra: mysql
 Requires-Dist: PyMySQL[rsa]<1.2,>=1.1.1; extra == "mysql"
 Provides-Extra: mssql
@@ -93,7 +93,7 @@ through Settings; startup never runs Alembic.
 
 - [Install and connect](docs/client/installation-and-connection.md), including the complete local CLI workflow.
 - [Understand the concepts](docs/concepts/architecture.md) and [identity and scope](docs/concepts/identity-and-scope.md).
-- [Understand the security model](docs/security/index.md): administration, Reader/Writer table ownership, sharing, and implementation status.
+- [Understand the security model](docs/security/index.md): administration, roles on namespaces and tables, and implementation status.
 - [Follow the market-data tutorial](docs/client/tutorial.md) with its complete examples folder.
 - [Define and migrate managed tables](docs/client/define-and-migrate-tables.md).
 - [Register existing tables](docs/client/register-existing-tables.md).

{mainsequence_metatable-0.1.45 → mainsequence_metatable-0.1.46.dev73}/README.md

@@ -34,7 +34,7 @@ through Settings; startup never runs Alembic.
 
 - [Install and connect](docs/client/installation-and-connection.md), including the complete local CLI workflow.
 - [Understand the concepts](docs/concepts/architecture.md) and [identity and scope](docs/concepts/identity-and-scope.md).
-- [Understand the security model](docs/security/index.md): administration, Reader/Writer table ownership, sharing, and implementation status.
+- [Understand the security model](docs/security/index.md): administration, roles on namespaces and tables, and implementation status.
 - [Follow the market-data tutorial](docs/client/tutorial.md) with its complete examples folder.
 - [Define and migrate managed tables](docs/client/define-and-migrate-tables.md).
 - [Register existing tables](docs/client/register-existing-tables.md).

{mainsequence_metatable-0.1.45 → mainsequence_metatable-0.1.46.dev73}/docs/adr/api/0002-application-administration-and-table-ownership.md

@@ -1,5 +1,10 @@
 # ADR 0002: Application administration and table ownership
 
+> Amendment (2026-10-19): [ADR 0024](0024-namespace-and-table-access-roles.md) replaces Reader/Writer
+> with roles (`metadata_viewer`, `data_viewer`, `data_writer`, `editor`, `owner`) checked as actions.
+> Any person creates a namespace and owns it, namespace owners grant on it instead of
+> Security, and Organization admins hold every action, data included.
+
 > Amendment (2026-10-01): [ADR 0013](0013-application-owned-migrations.md) establishes application-owned
 > client Alembic execution using the configured environment connection. Its DDL
 > privileges belong to the environment database role. It supersedes this ADR's

{mainsequence_metatable-0.1.45 → mainsequence_metatable-0.1.46.dev73}/docs/adr/api/0007-database-enforced-table-access.md

@@ -1,5 +1,10 @@
 # ADR 0007: Enforce table grants in the database
 
+> Amendment (2026-10-19): [ADR 0024](0024-namespace-and-table-access-roles.md) keeps the two
+> privilege sets: `data_viewer` maps to Reader's `SELECT`, `data_writer`, `editor` and `owner`
+> to Writer's privileges, and `metadata_viewer` to none. An admin group role holds write
+> privileges on every managed table; admins' login roles are its members.
+
 > Amendment (2026-10-01): [ADR 0013](0013-application-owned-migrations.md) establishes application-owned
 > client Alembic execution using the configured environment connection. Its DDL
 > privileges belong to the environment database role. It supersedes this ADR's