Minimum viable external system checklist

Use this index with Quickstart to build one recordStorage datasource using public docs only — no private knowledgebase or Builder repo required during the exercise.

Prerequisites

• Developer workstation setup
• Tenant ACTIVE
• aifabrix auth status succeeds

Where it lives

How to set

Work through the checklist in order. Stop and fix validate errors before advancing — each phase assumes the previous phase is green.

1. Scaffold and catalog — create, then ensure resourceType keys exist in the catalog before authoring datasource JSON.
2. System JSON — authentication block matches your vendor (often repair --auth apikey after OpenAPI import).
3. One recordStorage datasource — copy a fixture; set identity band and recordStorage companions.
4. Repair and validate — manifest lists, RBAC, and expose blocks aligned via repair.
5. Publish and test — probe upload, integration, then scoped E2E.
6. Govern — dimensions, protection upload, verify-governance with a scoped subject (skip subject emails when every datasource sets accessControl.abac.applicability: notApplicable).
7. Certify — operations, trust, governance, lifecycle when Role Assistants will consume capabilities.

Scaffold and catalog

• [ ] aifabrix create <systemKey> --type external
• [ ] aifabrix resource-type list — create keys if missing
• [ ] aifabrix resource-type create --key customer --display-name "Customer"

System JSON

• [ ] <systemKey>-system.json — type, authentication.credential, openapi/mcp block
• [ ] aifabrix validate integration/<systemKey>/<systemKey>-system.json

One recordStorage datasource

• [ ] Root fields: key, displayName, systemKey, entityType, resourceType
• [ ] primaryKey, metadataSchema.properties.externalId
• [ ] fieldMappings.attributes, sync, exposed
• [ ] See Build a record storage entity

Repair and validate

• [ ] aifabrix repair <systemKey> --auth apikey (if API key vendor)
• [ ] aifabrix repair <systemKey> --rbac --expose
• [ ] aifabrix validate <systemKey>
• [ ] aifabrix datasource validate <datasourceKey>

Publish and test

• [ ] aifabrix upload <systemKey> --dry-run for a non-mutating local preflight when needed
• [ ] aifabrix upload <systemKey> and wait for durable qualification (--no-wait / --resume <jobId> when detaching)
• [ ] aifabrix test-integration <systemKey>
• [ ] aifabrix datasource test-e2e <datasourceKey> --app <systemKey>

Govern (before production AI)

• [ ] aifabrix dimension create + datasource dimensions bindings
• [ ] aifabrix protection validate + protection upload
• [ ] aifabrix verify-governance <systemKey> --subject-email <scoped-user>

Certify

• [ ] Re-upload the current candidate with policy-required --gate checks after prerequisites are ready; inspect lifecycle and individual pillars for diagnostics

Defaults and examples

Identity band every recordStorage datasource must include:

Minimal JSON skeleton (extend before upload):

{
  "key": "example-customers",
  "displayName": "Customers",
  "systemKey": "example-crm",
  "entityType": "recordStorage",
  "resourceType": "customer",
  "primaryKey": ["externalId"],
  "metadataSchema": {
    "type": "object",
    "properties": {
      "externalId": { "type": "string", "index": true }
    }
  },
  "fieldMappings": { "attributes": {} },
  "sync": {},
  "exposed": {}
}

Public build-path references (integrators):

Sign-off

Record systemKey, datasourceKey, environment, and date when Scenario A passes. Use the fail log in temp/docs-validation/5.0-manual-build-proof.md (maintainers) if a step blocks — integrators should capture command, doc page, and sanitized error only.

Limits

This checklist is minimum viable — documentStorage, multi-datasource FK graphs, and MCP-only systems need additional pages under Model and Govern phases. Empty sync / exposed in the skeleton above will fail validate — replace with real blocks from a fixture before upload.