Story: Name the installation's own data
Table of Contents
This page documents a story in Sprint 27. It captures the goal, current status, acceptance criteria, and the tasks that compose it.
1. Goal
The installation owns a class of data the schema does not name: the facts about the deployment itself. This story names it, gives it the policy shape it wants, and moves the Operations reads onto it, so a read of the fleet is honest rather than a workaround. It adds no security exception and no tenant parameter.
2. Status
| Field | Value |
|---|---|
| State | DONE |
| Parent sprint | Sprint 27 |
| Now | Nothing. |
| Waiting on | Nothing. |
| Next | Nothing. The remaining migration is the successor story Move the installation's remaining reads onto its own class. |
| Last touched | 2026-10-07 |
3. Acceptance
- The codegen can express installation-scoped data, so a model declares its owner instead of hand-writing a policy.
- The grid and node samples carry that shape and are read whole by a session the permission admits.
- The work counts are superseded by story 84345A75 (the usage ledger); this story no longer claims them.
4. Tasks
| Task | State | Start | End | Description |
|---|---|---|---|---|
| Give installation-scoped data its policy shape | DONE | 2026-10-07 | A model cannot say that its rows belong to the installation, so such a table hand-writes the shared-reference policy: own tenant or system-tenant rows. This task adds the codegen feature that states it, and moves the grid and node samples onto it. | |
| Read the fleet whole in the grid handler | DONE | 2026-10-07 | The grid handler reads the newest sample per node through a hand-written tenant predicate written for tenant data. Drop it, let the policy decide, and prove the fleet comes back. |
5. Decisions
- The installation records what it did; it does not read across tenants. A super administrator needs to know which tenant is using the grid. The work that answers it, the batches, workunits, results, reports and schedules, is tenant-owned, so reading it across tenants is the widening the guard exists to stop. The answer is not a read at all: the compute service is already inside each tenant when it dispatches that tenant's work and when it takes the result back, so it records what it did as an installation fact. The grid's global view is a ledger the installation keeps about its own operation, not a view over its tenants' tables.
- A usage row carries the operation, not the tenant's content. The tenant, the host, the app version, the duration, the cores and the outcome. It does not carry the input bundle, the config, the output, the stderr or the report definition. Those stay tenant-owned, and a row that copied them would be a cross-tenant leak under another name.
- The grid's global view needs no exception from the tenancy audit. This supersedes the earlier framing of the global view as a cross-tenant aggregate, which was wrong. What the installation observes about itself is installation data from the moment it is written, so the guard never applies.
- The policy flag is named for the rows it admits, not the session it
serves.
:rls_own_or_system_tenant_rows:states both comparisons on thetenant_idside – the session's own tenant's rows, or the system tenant's – so no reader can mistake it for:rls_system_tenant_visible:, which names the session and emits the guardedcurrent = systemwidening. Shared reference and installation data want the same rows and the same write rule, so one flag serves both, and the two flags are mutually exclusive. - The story was re-scoped on 2026-10-07. Its acceptance was wider than its two tasks: it named the roster, the logs, the bus and the versions, which the tasks do not touch, so it could never close as written. The remaining migration moved to the successor story Move the installation's remaining reads onto its own class, and the work counts are story 84345A75 (the usage ledger). The acceptance now claims only what the work in PR #2761 delivers.