op, createOp, updateOp, emittedEvent. Binding finds operations and events in your imported spec that can fill them, and expands the archetype into concrete steps against those operations.
Binding uses explicit and confirmed facts only
A candidate resting on a guessed fact is rejected, because a test resting on a guess fails for reasons that have nothing to do with your code. That rule produces two honest answers:archetype does not apply: your API has no operations that can fill the archetype’s roles. A read-only API genuinely has no duplicate-delivery story.no candidate binding grounds: roles could be filled, but no candidate expanded into a definition that validates against the pinned API.
Override a role
--bind role=operationId overrides one role. The value is an operationId from your spec. If it names something the API does not have, the expansion fails to ground rather than running a test that cannot mean anything. --bind is repeatable and also accepted by mode set.
Sandboxes imported from a docs URL
A sandbox whose contract a model extracted from documentation has only extracted facts, and an archetype never binds on extracted facts alone.scenario list prints the candidate it would have chosen as a ready --bind line:
x-pikopod-origin marker and re-import from the file. The facts are then yours, and binding proceeds without --bind. See Importing from a docs URL.
Webhook roles
duplicate_delivery needs an emittedEvent: a declared webhook event with a trigger. A spec with no webhooks, or a docs import that could not know which call fires which event, cannot bind it. Bind events to their calls in the webhooks sidecar. See Webhooks.