List one contract's correction chain
Lists every correction one contract carries, so an operator can prove WHAT was superseded, in which order, and which correction is current.
A contract nobody has had to correct answers 200 with an empty list, never 404. Having never been corrected is a normal state of a registered contract, and a miss there would read as “no such contract”.
One contract can carry SEVERAL independent chains: one for its CCB and one per corrected payment. They are laid end to end rather than interleaved, each ordered root first and head last, because there is no order BETWEEN chains and publishing one would invent a fact. Each item names its own correction_type and payment_reference, which is what tells the chains apart.
is_head is declared by the server and answers “which correction is current”. The head is the one correction nothing supersedes, which is a TOPOLOGICAL property: deriving it from a timestamp can name an already-superseded row, so it is derived here once instead of once per client.
supersedes_event_id is null on a first CCB correction, and that null MEANS the original contract-registration fact. It travels as null rather than being omitted, so a reader never has to tell “no such field” apart from “supersedes the original”.
There is NO paging and no cursor. The chain’s order is topological, and a keyset needs a position that survives the next append, which supersession links are not. The answer is bounded at 200 items instead, and reaching the bound is REPORTED through truncated rather than swallowed: a cut nobody is told about reads as a complete audit trail on the one surface whose purpose is proving what was corrected. truncated is also true when a chain link points at a correction this answer does not carry, which means the same thing to the reader.
Three columns of the stored row never leave: the client’s own transport key, and the gateway’s object key and version id. The published resource_uri is the only address a caller is given, and it is the same path the correction fact names.
It answers from a LOCAL table and never reaches the Dataprev rail. It answers 501 on a deployment that composed no correction family, which is a deployment posture rather than a wrong URL. The tenant is derived from the validated identity and is never read from the request.
Authorizations
JWT bearer token issued by the identity provider.
Path Parameters
The rail contract number whose corrections to enumerate. Exact, control-free UTF-8, bounded in BYTES: 2..15, the same bound the intake enforces.
2 - 15"99999999999AN1"