Module 2 · Model the Policy - TextQL Docs

Goal: a written who-sees-what matrix that both the DBA and the workspace admin have agreed to — the input for everything that follows.

2.1 · The matrix

One row per persona; be concrete about the attribute that drives each restriction — that attribute is what the guard will key on:

Persona	Row scope	Column handling	Grain	Enforced by
Finance analyst	All regions	Full	Detail	Warehouse role
Regional analyst — [East]	[region = East] only	Identity fields masked	Detail	Warehouse policy or ontology guard
Executive	All regions	Aggregates only	Summary	Secure aggregate view
External [vendor/tenant]	[their tenant] only	Approved columns only	Per contract	Ontology guard + tenant scope

Prompt

Help me build an access-policy matrix for [source]. Personas: [list them]. For each: which rows they may see (and the column/attribute that decides it), which columns are masked or excluded, and the coarsest grain they need. Format as a table I can put in front of our DBA and workspace admin for sign-off.

You’ll see: the draft matrix. Argue about it now, in a document — every later module implements exactly this table, and scope arguments during implementation are how gaps ship.

One attribute, one owner — Every row restriction keys on an attribute (region, line_of_business, tenant_id). For each one, write down where it comes from and who owns it — an IdP group, a warehouse role mapping, an entitlement table. An attribute nobody owns becomes a boundary nobody maintains.

✅ Checkpoint

The matrix exists in writing with every persona’s row scope, column handling, and grain
Each restriction names its driving attribute and that attribute’s owner
DBA and workspace admin both signed off