adapter-sidecar-patternlisted

# Adapter Sidecar Pattern An adapter translates what a process emits into a platform contract. Uniform syntax does not imply uniform meaning: two duration metrics may include different work. The specialist decision is whether translation is justified, where it belongs, and how to detect plausible but incorrect output when either contract changes. ## Workflow 1. **Establish the contract before the parser.** Obtain representative source samples with producer image/version and capture conditions, the consumer schema/protocol and version, field meanings and units, and the current collection path. Inspect source/configuration where available; do not infer semantics from field names alone. For placement, obtain producer changeability, collector capabilities/access, replica counts and resource constraints. For failures, obtain timestamps, parser errors, backlog and upstream collection status. 2. **Handle missing evidence explicitly.** Request the smallest missing sample or contract needed for a decision. Continue with a conditional design, but do not invent a production parser, health predicate, resource budget or confirmed diagnosis. Label supplied facts, inferred explanations and untested hypotheses separately; name a check that could refute each consequential hypothesis. 3. **Choose the least costly adequate placement.** Before adding a container or revisiting log collection, read [adapter-or-node-agent.md](references/adapter-or-node-agent.md).