Documentation Index

Fetch the complete documentation index at: https://docs.aifabrix.ai/llms.txt

Use this file to discover all available pages before exploring further.

Minimum viable external system checklist

Prev Next

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

Where it lives

Layer Location
Integration bundle integration/<systemKey>/
System manifest <systemKey>-system.json
Datasource manifest <datasourceKey>.json (one file per entity)
Governance rbac.yaml, integration/.protection/

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 catalogcreate, 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.
  7. Certify — operations, trust, governance, lifecycle when AI workers 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.jsontype, 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> --probe
  • [ ] aifabrix upload <systemKey>
  • [ ] 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

  • [ ] aifabrix verify-operationsverify-trustverify-governancelifecycle

Defaults and examples

Identity band every recordStorage datasource must include:

Field Purpose
key Stable datasource key in deploy manifest
displayName Operator-facing label
systemKey Parent external system key
entityType recordStorage for CRM-style entities
resourceType Catalog key (customer, contact, …)
primaryKey Normalized id field(s)
externalId Indexed join identity in metadataSchema

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):

Topic Public guide
Schema bands Build a record storage entity
Field mappings Configure business vocabulary
CLI ladder Test ladder
Full index Build AI-ready systems README

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 viabledocumentStorage, 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.