Aglet

Prioritize incomplete API responses by data risk

Partial responses have different consequences depending on whether they drive display, exports, reconciliation, or writes. Prioritize by the data replaced or omitted, the ability to re-read safely, and the reach of the parser. Do not choose a larger payload limit before measuring the boundary.

Decide where the work belongs

  1. Describe what was lost

    For each cohort, compare expected and received fields, items, and downstream decisions. Separate a display omission from a persisted or exported gap. Keep response size, operation, and client revision attached to each consequence.

  2. Choose a safe containment

    Consider retaining known-good data, marking the new result incomplete, re-reading a bounded resource, or pausing a write. Record what remains uncertain and who can approve recovery. Do not overwrite complete state with a fragment to keep freshness moving.

  3. Set the recovery queue

    Rank durable data impact and shared parser reach ahead of cosmetic collection gaps. Set owner, sample, review date, and evidence needed to reprioritize. If completeness metadata is absent, queue an observation rather than inventing a threshold.

What to carry forward

Return a queue with missing scope, overwritten-state risk, recovery safety, owner, and acceptance evidence. Escalate fragments that can alter durable records or exports. Keep ordering provisional when the remote completeness contract is unknown. Preserve complete records until recovery evidence is sufficient.

Technical background: RFC Editor reference.

Keep the decision with the work.

Use a Work Item in Aglet to record the problem, the evidence you have, and the next decision. Add an owner and priority, then keep updates in the discussion so the next person can follow the reasoning.

Create an account See the product workflow