Deployment and upload

Upload publishes integration config to the dataplane. Deploy promotes through Miso Controller when your environment requires full platform lifecycle promotion.

Role Assistant packages: For Role Assistants, upload and deploy share one dataplane promote path with --env (dev / tst / pro) — settings + Evidence, not this Connected System Miso deploy model. See Manage Role Assistant packages.

Prerequisites

Local validate green: aifabrix validate <systemKey>
aifabrix auth status green (user or CI app credentials)

Where it lives

Action	Target
Upload	Dataplane pipeline validate + publish
Deploy	Controller-managed promotion (`aifabrix deploy`)
Online truth	`aifabrix show <systemKey> --online`

Local files under integration/<systemKey>/ are source of truth until upload.

How to set

Preflight validate:

aifabrix validate <systemKey>
aifabrix json <systemKey>

Probe upload (catch auth/schema without full mutate):

aifabrix upload <systemKey> --probe

Publish:

aifabrix upload <systemKey>
aifabrix upload <systemKey> --verbose

Compare online vs local:

aifabrix show <systemKey> --online

Deploy (when controller promotion required):

aifabrix deploy <systemKey> --probe
aifabrix deploy <systemKey>

Post-upload tests:

aifabrix test-integration <systemKey>
aifabrix test-e2e <systemKey>

Typical sequence before certification:

validate → upload --probe → upload → show --online → test-integration → test-e2e
  → verify-operations → verify-trust → verify-governance → lifecycle

Defaults and examples

Command	When
`upload --probe`	Every publish attempt in CI
`upload`	Dev iteration after probe green
`deploy`	Managed env promotion
`show --online`	Drift check before certify

Credentials: upload may push credential references — if denied, fix permissions and kv:// resolution (Configure authentication).

Upload publishes every datasource key with root entityType, resourceType, primaryKey, and indexed externalId — probe failures on unknown resourceType mean catalog sync lag, not pipeline outage.

Role catalog gate (fail-closed)

Purpose: business and management set access boundaries in one Role catalog. Development teams reuse those roles on applications and Connected Systems — they do not invent a parallel access model per system.

Modern identity groups are already hard to govern. AI Fabrix intentionally avoids each integration or AI surface creating its own role/group reality. Publish fails closed so a system cannot “bring its own” roles that were never agreed in the catalog.

Applications and Connected Systems declare roles in RBAC. Every role key referenced there must already exist in the Controller Role catalog.

Business sets Role catalog
  → Integrator references role keys in RBAC
  → Catalog check on deploy / upload
  → Missing key → fails (no invent-on-publish)
  → Add or activate role in Controller → retry

The platform does not create missing catalog roles during deploy or upload. Typical fix: open Roles in the Controller, add or activate the key (or use an existing seeded key), then probe again.

Everyone (aifabrix-everyone) is one catalog role used for LLM and platform-search consume — same rule as any other key: grant it only because it already exists in the catalog, not because a system invented it. See AI Fabrix roles.

Sanitized probe success shape:

{
  "success": true,
  "systemKey": "example-crm",
  "phase": "probe",
  "datasources": ["example-customers"]
}

Validate

aifabrix upload <systemKey> --probe
aifabrix show <systemKey> --online

Do not run certification pillars on unpublished local-only config.

Common mistakes

Mistake	Fix
Upload without validate	Fix schema locally first
Skipping probe in CI	Add `--probe` gate
Assuming deploy = upload	Use upload for dataplane publish in dev
Stale online after edit	Re-upload + show --online
RBAC role key missing from Role catalog	Add/activate the role in Controller first; do not invent roles per system at publish time
Listing every Role Assistant on LLM/search RBAC	Grant consume to catalog Everyone instead of a private role list — AI Fabrix roles

Limits

Deploy permissions and environment promotion policies vary by organization — confirm with your platform operator which path applies in tst/pro.

Upload publishes key, displayName, systemKey, entityType, resourceType, and companion bands from local JSON — if show --online differs from git, re-run repair --dry-run before blaming the pipeline. Probe upload is mandatory in CI: it catches auth and schema failures without mutating production config. After upload, run test-integration before test-e2e — upload success does not prove vendor credentials or sync configuration. Use show --online to compare deployed displayName and datasource lists with local git before certification pillars. Single-datasource upload via datasource upload still requires root systemKey and resourceType on the file.

Post-upload drift check — compare online datasource key list to application.yaml:

aifabrix show <systemKey> --online
aifabrix validate <systemKey>

If probe fails on externalId or primaryKey, fix datasource JSON locally before retrying upload — the pipeline will not patch missing join identity during publish.

Controller deploy promotion may lag dataplane upload in shared dev environments — run show --online on the environment you intend to certify, not only the machine where upload succeeded.

Protection manifests under integration/.protection/ upload separately — integration upload success does not publish dimension grants; follow Protection manifests and upload before verify-governance.

Credential push during upload may be denied by platform policy while schema publish succeeds — treat probe + integration test as the minimum bar before announcing deploy completion to operators.

Record show --online snapshots in change tickets when operators approve publish — diffing online vs git is the fastest rollback signal when probe passed but integration tests fail post-upload.

Documentation Index