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 statussucceeds
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.
- Scaffold and catalog —
create, then ensureresourceTypekeys exist in the catalog before authoring datasource JSON. - System JSON — authentication block matches your vendor (often
repair --auth apikeyafter OpenAPI import). - One recordStorage datasource — copy a fixture; set identity band and recordStorage companions.
- Repair and validate — manifest lists, RBAC, and expose blocks aligned via
repair. - Publish and test — probe upload, integration, then scoped E2E.
- Govern — dimensions, protection upload,
verify-governancewith a scoped subject. - 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.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> --probe - [ ]
aifabrix upload <systemKey> - [ ]
aifabrix test-integration <systemKey> - [ ]
aifabrix datasource test-e2e <datasourceKey> --app <systemKey>
Govern (before production AI)
- [ ]
aifabrix dimension create+ datasourcedimensionsbindings - [ ]
aifabrix protection validate+protection upload - [ ]
aifabrix verify-governance <systemKey> --subject-email <scoped-user>
Certify
- [ ]
aifabrix verify-operations→verify-trust→verify-governance→lifecycle
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 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.