Press CTRL+K to open search

Configure CIP argument keys

  • Updated on Sep 13, 2026
  • Published on Jul 27, 2026
  • 3 minute(s) read
  • MR
  • EB
 Prev Next

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, caller identity, association seeds, and
write body before CIP runs. Integrators bind caller identity explicitly and own the seed and body names through
published datasource fields.

Prerequisites

Where it lives

Concern Manifest location
Caller identity values CIP template expression {{actor.identityAttributes.<key>}}
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.

Caller identity is a separate governed input. Bind an administrator-configured identity key from the verified bearer
token with {{actor.identityAttributes.<key>}}. Request JSON, chat context, and user_attributes cannot supply this
root. If the verified token lacks the referenced key, Runtime stops before sending the provider request.

Builder MCP
Manifest keys foreignKeys, exposed, 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

  1. List every association parameter the capability needs on foreignKeys[].fields with a clear targetDatasource.
{
  "foreignKeys": [
    {
      "name": "primaryCompany",
      "fields": ["companyExternalId"],
      "targetDatasource": "example-companies"
    }
  ]
}

  1. Bind caller identity when the operation acts on the signed-in person's own record. Put the configured identity
    key in the CIP path, query, or body template, for example {{actor.identityAttributes.hr.employeeId}}. Keep
    provider field names in the manifest; do not ask the model to infer identity from a display name or email search.

  2. Align CIP templates so bodyTemplate parameter names match declared fields — not invented vendor aliases in
    Python or env maps.

  3. 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.

  4. Prefer stamped fkSeedFields on continuation after a prior create so the next planned capability seeds only declared association fields.

  5. 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
Caller identity Verified token via actor.identityAttributes binding Only where the CIP template binds it
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:

  1. Create returns a record identity the Runtime can anchor.
  2. Stamped seeds carry only manifest FK field names.
  3. Update/associate CIP parameters reuse those names.
  4. 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
Taking caller identity from request or chat data Bind a verified token key with actor.identityAttributes
Falling back when an identity key is absent Stop before the provider request; fix identity configuration or claims
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

Related

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.

Related articles