The verification block

Available

What it does

After the write, the platform reads back from the source and applies the declared predicate:

write → response (id) → read-back(id) → predicate → VERIFIED | FAILED | UNKNOWN

Shape

{
  "name": "crm.create_deal",
  "direction": "write",
  "verification": {
    "operation":    "crm.get_deal",
    "business_key": "id",
    "expect":       { "field": "closed", "equals": "N" },
    "max_wait_ms":  15000,
    "on_missing":   "UNKNOWN",
    "version_field": "resource_version"
  }
}

Field	Required	Meaning
`operation`	✅	Read-back operation — it must exist and be `direction: read`
`expect`	✅	Success predicate — declarative, not free text
`business_key`	—	Name of the key passed to the read-back
`max_wait_ms`	—	How long to wait for the record to appear (max 10 min)
`on_missing`	—	When not found: `UNKNOWN` (default) or `FAILED`
`version_field`	—	If set, reads from a stale replica are detected

⚠ `business_key` does two jobs

This is where mistakes happen most:


1️⃣	The field name in the write response — the resource id is taken from it
2️⃣	The read-back argument name — that value is passed under this name

So the two must be identical:

// crm.create_deal response:   {"id": "10001", "created": true}
// crm.get_deal input:         {"id": "10001"}
"business_key": "id"          // ✅ matches both

`expect` — the predicate

Exactly one of in or equals.

"expect": { "field": "status", "in": ["DELIVERED", "delivered"] }
"expect": { "field": "closed", "equals": "N" }

⚠ The provider’s taxonomy lives in the manifest, not in code. When the provider renames its states, a manifest line changes — not code.

`on_missing` — why the default is `UNKNOWN`

record not found in source  ≠  the action did not happen

Index lag or eventual consistency can hide the record temporarily. Defaulting to FAILED would close the operation incorrectly.

Choose FAILED only when the source is read-after-write consistent.

Always return the predicate field

If the predicate field is absent from the read-back response, the verifier returns UNKNOWN with field_missing — verification silently does nothing.

// ✅ Right: the field is always present, even when empty
out["closed"] = closed        // may be ""

// ⛔ Wrong: field omitted entirely when empty
if closed != "" { out["closed"] = closed }

What if there is no read-back

That is a normal situation — the provider’s API is what it is. Then:

the operation stays at ACKNOWLEDGED;
the connector stays at L2 (certification);
this is not a defect — it is an honest answer.

Certification levels
Conformance suite — C9–C11 test exactly this block