Twelve layers of access control apply in order to every read, write and delete, on every door: the grid, the pivot, REST, SOAP, SQL and the agent endpoint.
| column | treasury | purchasing steward | controller | sales | analytics role |
|---|---|---|---|---|---|
| legal name | R W | R W | R | R | R |
| VAT ID | R | R W | R | R | R |
| bank account | R W D | •••• 4471 | •••• 4471 | hidden | hidden |
| credit limit | R W | R | R | hidden | banded |
| contact e-mail | R | R W | R | R W | hashed |
| retire record | refused | D with approval | refused | refused | refused |
R read · W write · D delete · masks and bands are cell rules; every hidden or masked cell shows why on hover, and the policy that fired is logged.
Most policies are written on attributes of the data (a sensitivity tag, a region, a company code, a lifecycle state) so a new supplier in company code 1200 is covered the moment it exists. Role lists cover the rest. Both kinds apply to every door, because every door reads through the same engine.
Personal data of contacts and employees carries a privacy tag that applies retention, masking and deletion rules across the sources; a deletion request becomes a ledger event and a write-back to each source that holds the person.
Most are set once per estate (identity, tenant, source mapping) or once per domain (domain, table, privacy tags). The day-to-day work is the matrix per role, and the quarterly certification reviews it.
Yes. There is one policy engine under every door, so an analyst's SQL and a portal's API call see exactly what the grid shows.
An agent acts as a named identity with its own grants and purpose window; its reads and proposals are logged like a person's.
Bring two systems that hold the same customers, suppliers or materials. In one working day we connect them, run the match on live rows, review the queue with your steward and publish the first golden view with its API.
