Connected System integrations drift over time — vendor APIs change, Business Entities are added, RBAC needs refresh, operators edit online config. Lifecycle commands keep local folders aligned with what is published on the dataplane.
Why it matters
Operators and integrators need a safe loop: pull truth from the dataplane, repair local files, re-validate, re-test, and confirm online state — without hand-editing generated deploy manifests.
The Operate phase is ongoing maintenance after initial certification. It is not where you design Role Assistants — see Role Assistants for Role Assistant concepts.
Prerequisites
- Existing published
systemKey aifabrix auth statusgreen for online commands- Local git backup before
downloadordelete
Where it lives
| Command | Effect |
|---|---|
download |
Overwrites local folder with online truth |
show --online |
Read-only online snapshot |
repair |
Fixes application.yaml lists, metadataSchema drift |
delete |
Destructive online removal |
Manifest section: system.lifecycle. UI: Connected System Audit & History (lifecycle / audit tab).
Builder MCP
| Manifest section | system.lifecycle |
| UI tab | Audit & History |
| Help topics | workflow, connectedSystemUi |
| Repair hooks | full repair graph after download |
Same commands documented for the Operate band: Download, repair, and show online.
How to set
- Compare before mutating local files:
aifabrix show <systemKey> --online
- Pull online config when intentional:
aifabrix download <systemKey>
- Repair drift after download or hand edits:
aifabrix repair <systemKey> --dry-run
aifabrix repair <systemKey> --rbac --expose
aifabrix validate <systemKey>
- Re-upload changed content for qualification when ready:
aifabrix upload <systemKey>
Upload waits for a durable qualification job by default. Use upload --no-wait to detach and upload --resume <jobId> to return to that same job; a CLI timeout does not cancel it. --probe is an optional post-publish runtime check, not a required non-mutating preflight. Use upload --dry-run for a local payload preflight.
- Select policy checks on upload; use individual pillars for diagnostics:
aifabrix upload <systemKey> --gate full --subject-email scoped-user@example.com
When the required protection and governance prerequisites are ready, this creates a new qualified candidate. The following standalone commands help inspect a specific failing pillar; they do not requalify changed content by themselves:
aifabrix verify-operations <systemKey>
aifabrix verify-trust <systemKey>
aifabrix verify-governance <systemKey> --subject-email scoped-user@example.com
aifabrix lifecycle <systemKey>
Optional cert sync when online state changed:
aifabrix validate <systemKey> --cert-sync
Defaults and examples
Recommended maintenance loop:
show --online → download (if needed) → repair --dry-run → repair
→ validate → upload (wait for qualification) → show --online
→ deploy when managed promotion is required
| Trigger | Action |
|---|---|
| Vendor API version bump | download/repair, validate, upload and requalify; run E2E diagnostics as needed |
| New datasource added locally | repair, validate, upload with required gates |
| Governance policy change | prepare policy prerequisites, then re-upload with a scoped governance gate |
| Operator edited online config | download, diff, repair |
Example identity fields repair syncs on datasources:
{
"key": "example-customers",
"displayName": "Customers",
"systemKey": "example-crm",
"entityType": "recordStorage",
"resourceType": "customer",
"primaryKey": ["externalId"]
}
Validate
aifabrix show <systemKey> --online
aifabrix validate <systemKey>
Log manual integration edits outside repair in your team's integration changelog when your process requires audit of hand-patched JSON.
Common mistakes
| Mistake | Impact | Fix |
|---|---|---|
| Hand-edit deploy JSON | Overwritten on next json |
Use repair + validate |
| Download without repair | Merge conflicts in YAML lists | --dry-run first |
| Reusing old proof after changed content | Promotion fails closed | Upload and wait for current-candidate qualification |
| Only verify-trust on refresh | Ops/governance stale | Select the required gates on upload |
Limits
delete is destructive — confirm environment and backups before use. download overwrites local work — commit or stash before pulling online truth.
Lifecycle commands do not rotate vendor secrets — update kv:// paths and re-upload after credential rotation (Configure authentication).
repair cannot invent missing business metadata — it aligns lists and schema bands; field mapping design still happens in Business Entities configure pages.
After download, run repair --dry-run before committing — online edits may include operator experiments you should not blindly merge into mainline git.
Schedule full pillar re-runs after vendor major version upgrades even when validate stays green — silent API behavior changes often surface first in test-e2e, not schema validators.
Once durable qualification is adopted, deploy consumes the current candidate's proof rather than rerunning the client ladder. Missing, failed, or stale proof requires another upload. A never-qualified system may still take a legacy server path; do not treat that as the preferred maintenance loop.
delete followed by re-upload is not a substitute for repair when only RBAC lists drifted — prefer repair-first workflows to preserve stable systemKey history in operator audit logs.
Compare show --online output before and after vendor maintenance windows — scheduled vendor outages mimic integration regressions until test-integration confirms credential validity.