Introduction

Scenario: A coalition personnel dataset feeds one mission Project, but partner-nation reviewers may only see the rows their release caveat permits and analysts outside the HR cell must never see the clearance column — all without splitting the data into separate Projects per audience.

Unit 6 takes security below the Project boundary. Units 1 through 5 built mandatory controls that act on a whole resource: Organizations silo enrollments, Markings gate a dataset conjunctively, and CBAC classifies entire Projects and files. But mission data rarely splits cleanly along resource lines. A single personnel table holds rows for several partner nations and columns of varying sensitivity, and you cannot give every audience its own copy without fragmenting the source of truth. Restricted Views and object/property security policies are how you enforce granular, row- and cell-level need-to-know on one shared dataset.

A Restricted View limits dataset access so a user sees only the rows they are permitted to see. The most defensible pattern for a defense org is the marking-backed Restricted View: you add a Markings column to the backing dataset — each cell a STRING ARRAY of Marking IDs — and the Restricted View shows a given row only to users who satisfy the Markings listed in that row's cell. This reuses the same mandatory Markings you already built rather than inventing a parallel access model. A Restricted View can also be built from a granular policy that tests column values directly. Either way the Restricted View is typically created by an Owner, cannot be used as an input to a transform, can back an object type for use in applications, and auto-creates a rebuild schedule so its row visibility stays current.

The deliverable is a marking-backed Restricted View over a sensitive personnel dataset, sitting inside its Project and still wrapped by that Project's mandatory Marking and Organization. Critically, you should leave this unit understanding what you can and cannot verify: existence, schema, and the inherited mandatory access requirements are all checkable through read APIs, but the row-visibility enforcement itself — and the rule logic of any granular or object/property policy — is not exposed by a documented read API. That gap is why the final step of this unit is an attested design record, not an automated check.

Capability focus: Restricted Views (marking-backed via a Markings column or granular policy); object (row) vs property (column) security policies. · Artifact: A marking-backed Restricted View over a sensitive dataset, able to back an object type.

Key concepts

Companion video

1. 1

   Confirm the Restricted View resource exists

   Create the Restricted View over the sensitive personnel dataset and confirm it exists at its expected path. As an Owner of the Project, build a Restricted View from the backing dataset so the result is a queryable resource of type RESTRICTED_VIEW that can later back an object type; remember it cannot be used as an input to a transform and that creating it auto-creates a rebuild schedule. The automated check uses Filesystem-v2 Get Resource / Get By Path to resolve the Restricted View at its path and confirm the resource type — this is an existence-only check. It tells you the Restricted View was created; it does not and cannot confirm that row-visibility enforcement is correctly filtering rows, because that enforcement is not exposed by any documented read API.

   not startedinstance check

   Run check

   Confirms the Restricted View was created at its expected path (existence-only; row-visibility enforcement is not read-API-confirmable).

2. 2

   Confirm the RV backing dataset schema includes the Markings column

   Make the Restricted View marking-backed by giving the backing dataset a Markings column, then confirm the schema. The backing dataset (here keyed as the sensitive_personnel dataset) should expose the columns the row-level logic depends on — for example person_id and clearance — plus a Markings column whose cells are STRING ARRAYs of Marking IDs; the Restricted View reveals each row only to users who satisfy the Markings listed in that row's cell. The automated check uses Datasets-v2 Get Dataset Schema to verify the expected columns, including the Markings column, are present. This is a schema-only confirmation: it proves the column that drives marking-backed row visibility exists, but the row-visibility enforcement itself is not read-API-confirmable, so a passing schema check is necessary but not sufficient evidence that need-to-know is being enforced.

   not startedinstance check

   Run check

   Confirms the backing dataset exposes the Markings column (STRING ARRAY) used for marking-backed row visibility.

3. 3

   Confirm the RV inherits the mandatory access requirement

   Confirm the Restricted View still inherits the Project's mandatory access requirements, so the granular layer sits beneath — never instead of — Organizations and Markings. Because Restricted Views live inside a Project, the Project's mandatory Marking (here a CUI Marking) and its Organization continue to wrap the Restricted View; a user must satisfy those mandatory controls before any row-level logic is evaluated. The automated check uses Filesystem-v2 Get Access Requirements on the Restricted View's RID and expects the mandatory Marking(s) and the Organization to be present. FLAG: this is the preview endpoint (getAccessRequirements?preview=true), so its contract may change and a live check can legitimately return a blocked or error result rather than silently passing — treat blocked as 'could not confirm,' not as success, and capture the response either way.

   not startedinstance check

   Run check

   Confirms mandatory controls still wrap the granular layer (the RV carries the mandatory Marking + Organization).

4. 4

   Document granular policy / object-property policy intent

   Document the granular policy and the object-versus-property policy intent, because this is the layer no documented read API can introspect. In your design record, write down the granular policy rule logic — which attributes, columns, and values decide row visibility — and state explicitly which object (row-level) security policies and which property (column-level) security policies achieve the row and column controls; for example, an object policy that limits coalition rows by release caveat and a property policy that hides the clearance column from analysts outside the HR cell, together giving cell-level security. This step is self-attested by design: it is a documented, reviewable checkpoint precisely because the granular/object/property policy rule internals are not exposed by any documented read API, so no automated assertion can confirm the rule logic — only your written record, verified against the live configuration during review, stands as evidence.

   not startedself-attested

   Mark complete

   Self-attested: the granular policy rule logic and object (row) vs property (column) security policies.