| name | 0.4.1-understand-command_message |
| description | [0.4.1] A message that encodes an invocation of an operation on the receiver, carrying method name and arguments. |
understand-command_message
CALL NUMBER: enterprise_integration_patterns.command_message : deep_message(9)
DEFINITION: A message that encodes an invocation of an operation on the receiver, carrying method name and arguments.
Invoke this skill to understand command_message down to its primitives. The RELATIVE ROOT below is the least-fixed-point closure of everything it bundles from — the full import cone, grouped by the lib each prim comes from. Projected from a prover-typed KB (MAP/SWI-Prolog consistency gate): every reference below resolves.
THE RELATIVE ROOT (the import cone, by lib)
from ?
- command_priority (d1): A metadata field indicating the urgency or precedence level of a command message, used by schedulers and routers to order or filter command processing.
- command_target (d1): The logical or physical destination endpoint to which a command message is addressed, specifying which receiver should process the invocation.
- command_timeout (d1): The maximum duration a sender will wait for a command to complete before considering it failed; exceeding this triggers timeout handling or retry.
- execution_context (d1): A structured record of runtime state passed alongside a command, providing the environment information needed to correctly process the operation invocation.
- fault_payload (d1): A data envelope containing error details returned when an operation fails, typically including fault code, description, and optional context for recovery.
- idempotency_key (d1): A unique identifier assigned to a command that allows receivers to detect and discard duplicate submissions, ensuring safe retries without double execution.
- operation_arguments (d1): The parameter values supplied to the operation being invoked by a command message, structured according to the target interface's argument schema.
- operation_identifier (d1): A named or coded reference that uniquely identifies which operation a command message is requesting, mapping to a procedure on the target system.
- result_payload (d1): A data envelope containing the return value or outcome produced by a successfully executed operation, structured to match the expected response schema.
- target_interface_version (d1): A version descriptor indicating which contract version of the target interface a command message adheres to, enabling version-aware routing and validation.
from deep_message
- dm_004 (d2): document_schema: A formal contract defining the expected payload_structure fields, their types, cardinality, and optionality for a given business_object_type.
- dm_005 (d2): content_identifier: A stable unique reference (document_id, correlation token) that identifies this specific document instance across systems and message stores.
- dm_008 (d2): payload_extractor: A component that retrieves specific fields from the payload_structure for routing, correlation, or downstream transformation.
- dm_009 (d2): schema_registry_entry: An entry in the message_type_registry binding a business_object_type to its document_schema and authorized handlers.
- dm_001 (d3): payload_structure: The internal data shape of a document message, comprising typed fields and nested data elements that constitute the complete business data being transmitted.
- dm_003 (d3): business_object_type: A typed classifier identifying the kind of business entity the document represents, such as purchase_order, invoice, or shipment_manifest.
- dm_007 (d3): document_origin: Metadata identifying the originating system, agent, or process that produced the document_message.
- dm_002 (d4): semantic_envelope: Metadata wrapper around the payload describing document provenance, intent classification, and temporal context without prescribing receiver action.
- dm_006 (d5): processing_hint: An optional non-directive annotation suggesting preferred handling, urgency, or routing preference without constituting a command.
from enterprise_integration_patterns
- correlation_identifier (d1): A unique ID placed on both request and reply messages so the sender can match responses to their originating calls.
- dead_letter_channel (d1): A channel where messages go after exhausting retries, signaling a delivery failure requiring intervention.
- guaranteed_delivery (d1): The assurance that a message sent over a channel will eventually be delivered, even if the receiver is temporarily unavailable.
- idempotent_consumer (d1): A consumer designed to safely process the same message more than once without side effects, essential for guaranteed delivery.
- message_expiration (d1): A property on a message indicating it becomes invalid after a certain time and should be discarded if not delivered.
- message_router (d1): A component that inspects message content or metadata and forwards the message to one or more downstream channels.
- message_store (d1): A durable repository of all messages processed by an integration component, enabling replay and audit trails.
- message_type_registry (d1): A catalog that maps message type names or namespace identifiers to their schemas and handlers in the integration system.
- request_reply (d1): A message exchange pattern pairing an outgoing request message with a correlated response message returned to the original sender.
- return_address (d1): Metadata on a reply message indicating which channel and possibly which queue the response should be routed to.
- schema_validation (d1): The enforcement that a message payload conforms to its declared schema before it is routed or transformed.
- at_least_once_delivery (d2): Message delivery semantics where a message is retried until acknowledged, guaranteeing delivery but allowing possible duplicates.
- exactly_once_delivery (d2): Message delivery semantics ensuring that a message is processed precisely one time, combining delivery guarantees with deduplication.
- content_based_router (d2): A router that examines message payload fields to determine the destination channel, decoupling sender from destination knowledge.
- dynamic_router (d2): A router that consults a registry or lookup table at runtime to determine destinations, allowing routing rules to change without redeployment.
- message_filter (d2): A router that discards messages that do not meet a predicate condition, suppressing unwanted messages from downstream consumers.
- recipient_list (d2): A router that sends the same message to a list of recipients computed at runtime from the message content or context.
CONSUMERS (what needs this)
cmd_001, cmd_002, cmd_003, cmd_004, cmd_005, cmd_006, cmd_010, message
Projected from the enterprise integration patterns KB (154 concepts / 176 relations) — consistency-typed by MAP; the facet list after the colon IS the cross-lib dependency web.
(leaf — this is an actual skill.)
