Aglet

Learn from repeated API schema rejections

The lasting lesson is a shared request contract that can be read before a client sends data. Preserve the field or encoding mismatch that mattered, the fixture that exposed it, and the distinction between local validation and remote rejection. Keep sensitive example values out of the learning record.

Keep the lesson for the next incident

  1. Write the request contract

    Document required and optional fields, accepted types, null and empty semantics, nested shapes, content type, and error mapping for the operation. State which rules are locally enforced and which are learned from the remote contract or response.

  2. Keep readable schema fixtures

    Retain complete, omitted, null, wrong-type, unknown, and boundary examples with synthetic values. Store expected wire shape, status, and caller state. Add the neighboring operation that shares a serializer if it helped reveal a regression.

  3. Set contract review signals

    Review new rejection codes, schema revisions, serializer changes, and rising field-specific failures. Assign an owner and a bounded threshold. Close the follow-up only when representative fixtures run against the version and environments the integration actually selects.

What to carry forward

Close learning with the request contract, redacted fixtures, serializer owner, and review signals. Keep remote validation limits visible. The durable outcome is a reproducible field comparison that prevents a future rejection from becoming a broad coercion or silent data change.

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