# Multi-step workflows

Confirm explicit remote-processing consent before the first step. Stop immediately if any step returns a non-zero client exit status or `ok` is not `true`. Pass only the required `data` field into the next request.

## Validate, minify, then hash JSON

1. Call `/v1/json/validate` with the original JSON text.
2. Require `data.valid: true`; an HTTP 200 validation result can still describe invalid JSON.
3. Call `/v1/json/minify` with the same text.
4. Call `/v1/crypto/hash` with `data.result` from minification, an explicit SHA-2 algorithm, and the requested output format.
5. Return the minified JSON and digest, including the algorithm and output encoding.

## Encode and verify a round trip

1. Call the requested encode endpoint with explicit options.
2. Call its matching decode endpoint on the returned result.
3. Compare the decoded text with the original when it is safe to retain locally.
4. Return the encoded result only after the comparison succeeds.

## Inspect a JWT timestamp

1. Ensure the token is synthetic, expired, or redacted rather than an active production credential.
2. Explain the remote call and obtain explicit user authorization.
3. Call `/v1/developer/jwt/decode` with `--confirm-sensitive`.
4. Read the annotated `exp`, `iat`, or `nbf` timestamp.
5. If another timestamp representation is needed, call `/v1/time/convert` with that numeric claim and `unit: "seconds"`.
6. State `verified: false` and do not make an authorization conclusion.

## Sort and compare JSON

1. Call `/v1/json/sort` on each value using the same `direction` and `indent` when a human-readable canonical view is useful.
2. Call `/v1/json/diff` with the original parsed values, not the formatted strings.
3. Read `equal` and the RFC 6901-addressed `changes`.
4. Return the sorted views only when useful; the structural changes are the authoritative comparison result.
