Protection manifests and upload

Configure overview: Configure business policies. This page is the detailed CLI workflow for integration/.protection/ YAML.

Create and publish protection manifests under integration/.protection/ that map principals to dimension grants.

Prerequisites

• Datasource uploaded and dimensions in catalog with correct valueType
• Dimension bindings on Business Entity JSON (Configure business policies)
• aifabrix auth status green

Where it lives

integration/.protection/
  <datasourceKey>.yaml    # one file per datasource key

CLI arguments use datasourceKey (e.g. my-crm-companies), not systemKey.

How to set

1. Optional starter — probe live datasource + catalog:

aifabrix protection create <datasourceKey> --type country-sales

2. Edit grants — illustrative fragment:

spec:
  datasourceKey: my-crm-companies
  version: "1.0"
grants:
  - principal:
      type: group
      id: "Sales Managers"
    dimensions:
      - dimensionKey: customerRegion
        valueType: static
        valueExpression: emea

3. Validate locally + on dataplane:

aifabrix protection validate <datasourceKey>
aifabrix protection validate <datasourceKey> --warnings-as-errors

4. Upload:

aifabrix protection upload <datasourceKey>
# or batch:
aifabrix validate .protection --warnings-as-errors
aifabrix upload .protection

5. Inspect deployed state:

aifabrix protection list
aifabrix protection show <datasourceKey>

Use --dry-run on upload in CI to fail without mutating production protection.

Defaults and examples

After upload, re-sync datasource when your workflow requires protection projection on stored records.

Example protection manifest fragment (integration/.protection/<datasourceKey>.yaml):

version: "1.0"
datasourceKey: example-customers
grants:
  - dimension: customerRegion
    principal: role:sales-manager
    values: ["EMEA", "APAC"]

Validate references datasource key, displayName, systemKey, entityType, resourceType, and dimension catalog keys — typos fail before upload. Protection manifests never replace datasource JSON — they reference deployed datasources by datasourceKey under integration/.protection/.

Validate

aifabrix protection validate <datasourceKey> --warnings-as-errors
aifabrix protection upload <datasourceKey>
aifabrix verify-governance <systemKey> --subject-email scoped-user@example.com

Common mistakes

Limits

Protection expressions are environment-specific — no secrets in git. Complex FK inheritance scenarios need coordinated dimension + FK configuration; see foreign keys page.

Before protection upload, confirm the datasource key is deployed and dimension catalog valueType matches manifest grants. Batch upload via upload .protection still requires each file to reference a valid datasourceKey and systemKey context from live dataplane state.

Protection grants reference dimension keys bound on datasource JSON — fix top-level dimensions and indexed externalId on the datasource before iterating on YAML grants alone. Run protection validate --warnings-as-errors in CI before protection upload to catch datasourceKey typos early.

FK inheritance: child Business Entity protection may reference parent dimensions — ensure parent foreignKeys[] and indexed externalId are deployed first (Configure business policies).

RecordStorage datasource context (protection applies after deploy):

{
  "key": "example-customers",
  "systemKey": "example-crm",
  "entityType": "recordStorage",
  "resourceType": "customer",
  "primaryKey": ["externalId"]
}

Batch upload .protection in CI should pair with protection validate --warnings-as-errors on every changed manifest file — partial batch success leaves some dimensions unprotected while others publish.

Subject-scoped proof uses verify-governance <systemKey> --subject-email after upload — protection YAML alone does not satisfy the governance pillar without live dataplane evaluation.

Dimension catalog valueType must match grant expressions — static region lists fail validation when the catalog expects dynamic identity-bound types even when YAML syntax is valid.

Protection upload order matters when FK inheritance applies — publish parent datasources and dimensions before child protection manifests that reference inherited scopes.

Static grant lists in protection YAML must match dimension catalog keys exactly — typos in customerRegion vs customer_region fail validate with messages that resemble RBAC misconfiguration.

Never store resolved principal secrets in protection YAML — principals reference identity groups and roles already synchronized via identity sync.