One row, many resolvers

Resolving from anywhereDashboardHTTPSDKCLIMCPMQTTScanconditionalresolveresolveBySignalKeyresolve_by_signal_key

A person, a service, an operator, an agent or a machine can resolve the same row. The workflow receives the same typed answer either way.

The situation

An inspection row is usually resolved by a person at a bench. Some days a vision service answers first, or an agent clears a backlog, or an operator scripts a fix. The workflow should not care which.

The recipe

const result = await conditional<{ pass: boolean }>(`inspect-${serialNumber}`, {
  role: 'inspection',
  metadata: { serialNumber },
});

# HTTP (a service or webhook)
curl -X POST https://lt.acme.dev/api/escalations/resolve-by-signal-key \
  -H "Authorization: Bearer $TOKEN" -H 'Content-Type: application/json' \
  -d '{ "signalKey": "inspect-SN-123", "resolverPayload": { "pass": true } }'

# CLI (an operator)
ltc esc resolve $ESCALATION_ID --data '{"pass": true}'

await lt.escalations.resolveBySignalKey({ signalKey: 'inspect-SN-123', resolverPayload: { pass: true } });

The dashboard renders the role’s form for a person. An agent calls the resolve_by_signal_key MCP tool. A scan rule or a machine on MQTT resolves through the same endpoints.

The guarantee

Exactly one resolve wins. It marks the row resolved and delivers the payload to the waiting workflow in one guarded transaction; every later attempt answers 409. Every surface runs the same RBAC and, for roles that enforce, the same schema gate. See Conditional.

Resolving from anywhere