Apply an integration definition

Create a Connected System from a Builder Integration Definition (BID) — the preferred static/custom create path. BID apply is not a test command.

Contrast: Path A aifabrix create scaffolds an empty folder; Path B wizard imports OpenAPI or MCP. BID apply materializes integration/<systemKey>/ from business create language (systemKind, catalog resourceType, propertyKeys).

Never paste secrets into BID files.

Prerequisites

Builder CLI installed; aifabrix auth status green when catalog checks need a session
Catalog resourceType keys you will reference already exist (or create them first)
A BID JSON file on disk

Where it lives

Artifact	After apply
BID file	Your authored `bid.json` (input)
Package	`integration/<systemKey>/` system and datasource JSON

Apply writes the package. It does not upload, deploy, store credentials, or start a Role Assistant subscription. The local folder is the working copy until you publish.

How to set

Author BID with systemKind, catalog resourceType, and propertyKeys (ASCII keys). Do not invent role keys outside the catalog.
Validate

aifabrix integration-definition validate ./bid.json

Use --fix-hash when the CLI asks you to refresh definitionHash.

Dry-run, then apply

aifabrix integration-definition apply ./bid.json --dry-run
aifabrix integration-definition apply ./bid.json

--force rewrites the package even when the hash matches. --output-dir overrides the destination folder.

Repair and validate the system

aifabrix repair <systemKey> --rbac --expose
aifabrix validate <systemKey>

Repair aligns catalog roles and exposed profiles with the materialized package. Skip that step and upload will often fail closed on unknown role keys or empty exposed bands.

Prove — Connected System tests, then Publish and certify. Apply does not certify operations, governance, or AI Trust.

Re-apply when you change BID identity, datasources, or relationships. If the hash already matches and you only edited generated package JSON, prefer repair instead of --force so you do not wipe local repair output. BID validate fails closed when a datasource resourceType is missing from the live catalog — create or list the type first, then re-validate the file.

Defaults and examples

Create path	Use when
BID apply	Static or custom packages from business create language
`aifabrix create`	Empty folder scaffold you will fill from fixtures
Wizard	OpenAPI or MCP import

Field (conceptual)	Meaning
`systemKind`	Kind of Connected System (catalog)
`resourceType`	Catalog resource type key on each datasource
`propertyKeys`	Business property names on the BID
`definitionHash`	Stamp the CLI validates; `--fix-hash` rewrites it

Full BID documents also carry identity, datasources, relationships, and acceptance blocks. Copy-paste a complete BID only from a schema-valid file in your workspace — this page does not embed a dummy manifest.

Validate

validate must succeed before apply. A successful apply is not an E2E pass. Dry-run first in shared workspaces so you see planned files without writing.

Common mistakes

Mistake	Fix
Treating apply as `test-e2e`	Apply creates files; tests prove them
Pasting API keys into BID JSON	Use `kv://` / `aifabrix secret` after the folder exists
Skipping `repair --rbac --expose`	Align roles and exposed profiles before upload
Applying before catalog `resourceType` exists	Create or list resource types, then re-validate BID
Skipping `--dry-run`	Preview planned files, then apply

Limits

BID JSON Schema is enforced by the CLI. Until a public schema copy is published in docs anchors, treat any JSON snippet you copy from elsewhere as illustrative unless integration-definition validate succeeds on that file. Apply is local materialization — publish still uses upload / deploy.