Configure CIP argument keys

Keep CIP and Runtime write arguments manifest-driven. Declare association and write field names on the Business Entity; do not hardcode provider foreign-key vocabulary in platform configuration or prompts.

Runtime classifies capability-execute arguments into platform meta, association seeds, and write body before CIP runs. Integrators own the seed and body names through published datasource fields.

Prerequisites

Configure business policies — foreignKeys[] planned
Configure AI contract — writable exposed attributes agreed
Configure data flow — CIP bodyTemplate / parameters use the same field names
Understanding that CIP execution is not Process Execution continuation

Where it lives

Concern	Manifest location
Association / FK seed names	`foreignKeys[].fields` (+ `targetDatasource`)
Writable body attributes	`exposed` + `fieldMappings.attributes`
Dimension source fields	*`dimensions..field`**
CIP parameter placeholders	`execution.cip` `bodyTemplate` / step parameters

Platform meta keys (orchestration only — never CRM body fields) include examples such as objective, scope, datasource, idempotencyKey, prior mutation refs, fkSeedFields, and association anchor identifiers. Those travel for Runtime planning; they must not be forwarded as vendor field values.

Builder MCP


Manifest sections	`datasource.foreignKeys`, `datasource.exposed`, `datasource.execution`
Help topics	`section`, `dependencyGraph`, `goldenExample`
Repair hooks	`fieldMappings`, exposure

Changing foreign keys or exposed write surfaces affects ABAC, protection, and capability certification — read dependencyGraph before patch.

How to set

List every association parameter the capability needs on foreignKeys[].fields with a clear targetDatasource.

{
  "foreignKeys": [
    {
      "name": "primaryCompany",
      "fields": ["companyExternalId"],
      "targetDatasource": "example-companies"
    }
  ]
}

Align CIP templates so bodyTemplate parameter names match those fields — not invented vendor aliases in Python or env maps.
Advertise writable attributes from exposed + mappings. Exclude platform identity keys, platform meta keys, association seeds, dimension source fields, and omit / readonly surfaces from invent-your-own write proposals.
Prefer stamped fkSeedFields on continuation after a prior create so the next planned capability seeds only declared association fields.
Validate:

aifabrix datasource validate <datasourceKey>
aifabrix validate <systemKey>
aifabrix verify-trust <systemKey>

Defaults and examples

Argument class	Source of names	Forwarded to CIP write body?
Platform meta	Product Runtime contract	No
Association seeds	`foreignKeys[].fields` / stamped `fkSeedFields`	Only as declared association fields
Write body	`exposed` + mappings	Yes (writable attributes only)

Illustrative checklist for a create-then-associate plan:

Create returns a record identity the Runtime can anchor.
Stamped seeds carry only manifest FK field names.
Update/associate CIP parameters reuse those names.
No provider-specific association field is hardwired in product code or shared configs.

Validate

aifabrix datasource validate <datasourceKey>
aifabrix validate <systemKey>

Integration and E2E tests should prove association writes using the published field names. Failures that mention missing association seeds usually mean the manifest omitted foreignKeys[].fields or CIP parameters drifted from those names.

Common mistakes

Mistake	Fix
Hardcoding a CRM association field name in product config	Declare it on `foreignKeys[].fields`
Sending `idempotencyKey` into the vendor body	Keep platform meta off the write body
Letting the model invent FK fields	Exclude seeds and identity keys from write proposals
Different names in CIP template vs foreignKeys	Align parameter names to the manifest
Confusing observer flags with argument keys	Observers watch metadata changes; they do not name CIP args

Limits

Exact platform meta key sets and planner stamps vary by Runtime release. This page teaches the neutrality law: manifest owns provider field names. Do not paste lab vendor association keys into public examples — use neutral names that match your published datasource.

Documentation Index