# Receiving an agent output without inheriting its policy

Wheeler Hubbell Publishing supplies an optional signed examination. A receiver, not the producing agent, decides whether it needs one and which issuer it admits. A positive examination is neither action permission nor a guarantee of substantive truth.

## The first infrastructure insertion

Insert the check after REST fulfillment, an MCP tool result, or a completed A2A task and before your workflow accepts the examined material as evidence. This adapter reuses the existing strict SDK verifier and exact-byte evidence gate. It does not replace those checks, issue a second signature, call the paid endpoint, or execute the next action.

Download the published TypeScript SDK from `/sdk/manifest.json`, then keep these files together:

- `/machine/receiver-boundary.mjs`
- `/machine/receiver-cli.mjs`
- `/machine/requirement.schema.json`

Run with Node and the installed `@whp-standing/sdk`:

```sh
node receiver-cli.mjs MCP tool-result.json material.bin receiver-trust.json receiver-requirement.json
```

Exit 0 means `EVIDENCE_REQUIREMENT_MET`; exit 2 means `HOLD`. Neither result is action authorization. Your trusted orchestration code must separately enforce delegated authority, user approval, spending limits and execution safety. Do not wire a successful exit directly to an irreversible action without those controls.

`receiver-trust.json` is your own independent issuer admission. Its keys are `public_key_base64` and `trusted_key_ids`; optional `now` is a Unix-seconds inspection clock for reproducible historical inspection, not a way to claim present validity. Keep sender attachments and trust configuration in separate origins. This adapter cannot itself prove who supplied your configuration.

`receiver-requirement.json` must match the published project schema. This is a project format, not an MCP/A2A/in-toto standard or a claimed ecosystem convention:

```json
{
  "version": "standing-mark-requirement/1.0.0",
  "record_contract": "standing-mark-verification/3.0.0",
  "positive_finding_required": true,
  "current_lifecycle_required": false,
  "expected": {
    "question": "YOUR independently chosen exact examination question",
    "scope": "YOUR independently chosen exact examination scope",
    "operation": "YOUR independently chosen exact requested operation",
    "requireWithinRecordedWindow": true
  }
}
```

Unknown policy fields are held, not silently ignored. Requests requiring current revocation or supersession evidence are held because no live lifecycle registry is supported. Setting the recorded-window requirement false allows explicitly historical inspection; it does not make old evidence current.

## Transport boundaries

- REST: read the returned envelope, directly or in `envelope`.
- MCP: require no JSON-RPC error and no tool error. Use `result.structuredContent`; a text explanation, HTTP 200, or boolean hint is not evidence.
- A2A: require a completed task and exactly one recognized envelope in data artifact parts. A task still awaiting payment or delivery is held. Multiple candidate records are held rather than selected for you.
- Exact material: pass your received bytes. A filename, a fetchable URL, or the sender's claim about a digest is not a substitute.

Preserve original envelopes unchanged alongside the material. When a downstream agent transforms material, the earlier envelope remains evidence about the earlier object only. A new examination is needed if local policy requires evidence for the transformed conclusion. This is not an implemented automatic chain examination service.

## Conformance and measurement

The reference cases are `/machine/conformance/cases.json`. Cryptographic conformance uses separately generated local test keys and clearly labeled test-only material, with the network disabled. Passing them does not establish a real examination, a live transaction, independent adoption, model quality, regulatory acceptance, or external issuer admission.

Receivers can measure HOLD rates by reason, mismatched material/scope caught before advancement, time spent integrating, latency, and independently verified reuse. Receiver-side offline measurements stay local unless the receiver chooses to share them. No telemetry transmission is included. Set a baseline before asserting prevented incidents or economic value. Do not count a signature check as an independent customer.

## Compatibility without a trust monopoly

A2A carries artifacts. MCP carries tool results. x402 purchases an examination. SLSA/in-toto can carry artifact-specific attestations and receiver verification policies. W3C credentials distinguish signature verification from business-rule validation. Standing Mark should complement these mechanisms, not claim to replace them. No in-toto predicate registration, W3C credential conformance, OSCAL/FHIR profile, or institutional approval is claimed by this adapter.

Source context: [A2A concepts](https://a2a-protocol.org/latest/topics/key-concepts/), [MCP annotation limits](https://blog.modelcontextprotocol.io/posts/2026-03-16-tool-annotations/), [in-toto and SLSA](https://slsa.dev/blog/2023/05/in-toto-and-slsa), [W3C credential model](https://www.w3.org/TR/vc-data-model-2.0/).