retoorandClaude Sonnet 5.5
ec9c471780
Feed panes in the multiplexer (vpane_* control commands, main-vertical layout, header row), src/orch (board, panel, formatter, transport, CAP adapter), Agent observer and cancel flag, supervision (idle warn/cancel, user close cancels, soft then hard stop), CAP answers collected through the spill path. Research archived under background-work-limits. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
52 lines
2.3 KiB
Markdown
52 lines
2.3 KiB
Markdown
# Claim Check pattern (Azure Architecture Center)
|
|
|
|
## Metadata
|
|
|
|
| Field | Value |
|
|
|---|---|
|
|
| Institute | Molodetz Institute — Research & Retrieval Division |
|
|
| Subject | background-work-limits |
|
|
| Document type | Source Dossier |
|
|
| Tier | 1 |
|
|
| Source title | Claim Check pattern (Azure Architecture Center) |
|
|
| Source URL | https://learn.microsoft.com/azure/architecture/patterns/claim-check |
|
|
| Source publisher / author | Microsoft |
|
|
| Source type | vendor docs |
|
|
| Source date (published) | 2026-08-31 |
|
|
| Date researched | 2026-10-25 |
|
|
| Researched by | tai (agent), model: Claude Sonnet 5, on behalf of retoor |
|
|
| Research method | direct page fetch |
|
|
| Confidence | High |
|
|
| Status | Active |
|
|
|
|
## Summary
|
|
|
|
The claim-check cloud design pattern: store a large payload externally and pass only a reference through the messaging system.
|
|
|
|
## Key findings
|
|
|
|
- The sender writes the payload to an external store and sends a reference (the claim check); receivers fetch it when they need it; the messaging system never carries the payload.
|
|
- Apply it conditionally by size so small messages skip the extra hop; the schema must say whether a payload is inline or external.
|
|
- Define who owns payload deletion and coordinate retention with message expiry so a valid token never points at deleted data.
|
|
- Do not embed security tokens in the claim check; publish the token only after the payload write succeeded; deliveries can repeat so consumers must be idempotent.
|
|
- Include a content hash when consumers must verify integrity; the store must stay available as long as consumers need the payload; retrieval adds latency.
|
|
- Alternatives: compress, or split and aggregate the payload.
|
|
|
|
## Pros / strengths
|
|
|
|
A named, widely recognized pattern with the failure modes (orphans, dangling tokens, retention) spelled out.
|
|
|
|
## Cons / limitations / caveats
|
|
|
|
Written for message brokers; tai's 'broker' is the model context, but the economics (size limits, cost, degraded throughput) are the same.
|
|
|
|
## Relevance to tai
|
|
|
|
Names what tai's spill path already is: a long result is stored as a record and the conversation gets a key plus a head and tail summary (`spilled_view`). Confirms the conditional rule (only above `SPILL_LIMIT`) and the write-before-reference order. Retention of agent output records is the open point.
|
|
|
|
## Changelog
|
|
|
|
| Date | Change |
|
|
|---|---|
|
|
| 2026-10-25 | Initial dossier created. |
|