Configure validation and test payload

Declare schema validation rules and testPayload fixtures so unit tests, integration tests, and E2E certification have deterministic inputs.

Prerequisites

Configure data flow with operations enabled
Configure metadata and identity with primaryKey set
Test tenant credentials for live E2E (not production)

Where it lives

Layer	Location
Validation rules	`<datasourceKey>.json` → `validation` (when used)
Test fixtures	`testPayload` — `primaryKey`, `payloadTemplate`, `scenarios`
UI	Business Entity Quality / test panels vary by release — manifest is SSOT

Manifest sections: datasource.validation, datasource.testPayload.

Builder MCP


Manifest sections	`datasource.validation`, `datasource.testPayload`
Help topics	`section`, `evidencePatterns`, `repairRules`
Repair hooks	`test`

Read evidencePattern when aligning certification evidence with fixture shape. Deep E2E guidance: CIP execution.

How to set

Repair test band when fixture output drifted:

aifabrix repair <systemKey> --test --dry-run
aifabrix repair <systemKey> --test

Add testPayload before first E2E:

{
  "testPayload": {
    "mode": "live",
    "primaryKey": { "externalId": "e2e-fixture-001" },
    "useCopyForMutations": true,
    "payloadTemplate": {
      "externalId": "e2e-fixture-001",
      "name": "E2E Record"
    },
    "scenarios": [
      { "operation": "list", "enabled": true },
      { "operation": "get", "enabled": true },
      { "operation": "create", "enabled": true },
      { "operation": "update", "enabled": false },
      { "operation": "delete", "enabled": false }
    ]
  }
}

Order scenarios in array order — disable destructive steps in shared tenants with enabled: false. Read-only certification paths typically enable list and get only until a dedicated sandbox exists for create/update/delete proof.
Align scenario operations with CIP operation keys and enabled capabilities.
Validate before E2E:

aifabrix validate <systemKey>
aifabrix datasource test-e2e <datasourceKey> --app <systemKey>

Defaults and examples

Element	Purpose	Example
`primaryKey`	Stable test record id	`{ "externalId": "e2e-fixture-001" }`
`payloadTemplate`	Create/update body	Normalized metadata fields
`scenarios[].operation`	CIP operation key	`list`, `get`, `create`
`useCopyForMutations`	Safer shared tenants	`true` for copy-on-write patterns

Example minimal scenarios for read-only certification:

{
  "testPayload": {
    "mode": "live",
    "primaryKey": { "externalId": "cert-read-001" },
    "scenarios": [
      { "operation": "list", "enabled": true },
      { "operation": "get", "enabled": true }
    ]
  }
}

Illustrative fixture goals:

isolated tenant ids — never production record keys
destructive ops disabled until dedicated sandbox exists
scenario keys match Configure data flow operations

Validate

Full ladder: Test ladder and protection and CLI workflow.

aifabrix repair <systemKey> --test
aifabrix validate <systemKey>
aifabrix test-integration <systemKey>
aifabrix datasource test-e2e <datasourceKey> --app <systemKey>

Common mistakes

Mistake	Fix
E2E without `testPayload`	Add `primaryKey` + template
Scenarios out of sync with capabilities	Match `operation` keys to CIP operations
Production IDs in fixtures	Use isolated test tenant values
All scenarios enabled in shared tenant	Disable mutating ops with `enabled: false`
Missing `payloadTemplate` for create scenario	Add normalized body matching `metadataSchema`

Limits

testPayload shapes evolve with certification gates — re-run repair --test after platform upgrades. Validation rules on the same band are optional; schema compile errors usually surface through datasource validate before E2E. Live E2E requires credentials — skip mutating scenarios when only read certification is in scope. Document fixture ids in your integration README so teammates do not collide when running parallel E2E against the same sandbox tenant. Re-run validate after changing scenario lists so disabled operations are not still referenced by certification scripts.

Documentation Index