Test protection and governance

Test ladder: Test ladder and protection. Configure: Configure business policies.

Prove ABAC visibility — which record keys each subject user can see — separate from vendor connectivity (test-e2e).

Prerequisites

Integration uploaded; protection uploaded for governed datasources
Subject users with business roles (not platform admin)
aifabrix identity sync -e <env> after role/group mapping
Datasource JSON with top-level dimensions and indexed externalId

Where it lives

Scenario packs — generated on dataplane; optional copies under integration/<systemKey>/scenarios/
Commands — verify-governance, governance generate, governance verify, governance download, governance upload
Protection manifests — integration/.protection/<datasourceKey>.yaml

How to set

Map role to groups:

aifabrix identity role set-groups sales-manager -e dev --groups "Sales Managers"
aifabrix identity sync -e dev

Confirm protection deployed — Protection manifests and upload.
All-in-one (recommended first run):

aifabrix verify-governance <systemKey> \
  --subject-email scoped-user@example.com \
  -v

Stepwise (repeatable in CI):

aifabrix governance generate <systemKey> --certification-profile bronze
aifabrix governance verify <systemKey> --subject-email scoped-user@example.com --json

Local pack authoring (advanced):

aifabrix governance download <systemKey>
# edit scenarios/*.yaml
aifabrix governance upload <systemKey>
aifabrix governance verify <systemKey> --pack integration/<systemKey>/scenarios/pack.yaml

Done when output reports VERIFIED or actionable per-datasource failures.

Defaults and examples

Flag	Purpose
`--no-sync`	Skip publish; use deployed integration
`--certification-profile bronze`	Default generate profile
`--pack <path>`	Verify one local YAML
`--json`	CI-parseable output

Test	Proves
`test-integration`	Pipeline + credentials + sync
`test-e2e`	Vendor API + CRUD path
`verify-governance`	Subject sees only in-scope record keys

Governed datasource context (protection references datasourceKey):

{
  "key": "example-customers",
  "displayName": "Customers",
  "systemKey": "example-crm",
  "entityType": "recordStorage",
  "resourceType": "customer",
  "primaryKey": ["externalId"],
  "dimensions": {
    "customerRegion": { "source": "country" }
  }
}

Validate

aifabrix verify-governance <systemKey> --subject-email scoped-user@example.com
aifabrix governance verify <systemKey> --subject-user-id <uuid> -v

Only after governance passes for scoped subjects:

aifabrix test-e2e <systemKey>
aifabrix verify-operations <systemKey>

Common mistakes

Mistake	Fix
Testing as platform admin	Scoped subject with business role
Skipping identity sync	Run sync after group changes
Expecting E2E to prove ABAC	Use verify-governance
No protection uploaded	Upload protection before generate

Limits

Scenario packs require realistic subjects and dimension data in your tenant. Empty dimensions may produce misleading results — seed test data matching protection grants.

Governance tests evaluate record keys visible to a subject — they do not replace test-e2e vendor CRUD proof or verify-trust metadata checks. Run the full certification ladder before production Role Assistant pilots.

Platform admin tokens bypass business ABAC — always use a scoped subject email aligned with rbac.yaml business roles.

Generate scenario packs only after protection manifests validate green — governance generate against missing grants produces false negatives that waste debugging time on subject mapping instead of YAML typos.

Re-run identity sync after every group membership change in Entra or your IdP — stale identity projection is the most common cause of unexpected verify-governance failures in dev tenants.

Store expected visible record key sets from governance verify --json in CI artifacts — diffing key lists across releases catches accidental scope expansion before production promotion.

Run protection validate --warnings-as-errors before generating scenario packs — invalid manifests produce governance tests that fail for YAML reasons unrelated to ABAC design.

Identity sync latency varies by tenant size — allow retry/backoff in CI governance stages rather than single-shot verify-governance immediately after group changes.

Foreign-key-linked datasources require governance tests on each datasourceKey with protection — child scope may differ from parent even when systemKey is shared.

Document expected denied record keys for negative tests — governance verification is meaningful only when both allowed and denied keys are asserted in CI artifacts.

Documentation Index