Correcting an entry
A worked example: an entry that named the wrong actor, corrected by a later entry that names it, so the original and the correction both stay visible.
A build was recorded as run by ci-runner-7. It ran on ci-runner-9. Nothing in a record is edited, so the fix is a new entry that names the one it corrects. Afterward the record shows both: the entry as it was written, and the correction beside it, with a note saying why.
An amendment is a new entry. This one stays as it was written.
The record before
| Entry | Title | actorId | lifecycle |
|---|---|---|---|
| 1 | Model build 2026-09-15-0417 passed testing | ci-runner-7 | recorded |
The record's name is entry 1's title, stored when the record was created. The correction below does not rename it.
The correction
amends names the corrected entry by the record's key, recordKey in every answer and in the history, and its number. Set lifecycle to amended, and put the reason in note.
const corrected = await pac.records.emit({
record: 'build-2026-09-15-0417',
lifecycle: 'amended',
title: 'Model build 2026-09-15-0417, corrected: the build ran on ci-runner-9',
kind: 'model-build',
occurredAt: '2026-09-15T16:04:17Z',
actorId: 'ci-runner-9',
payloads: [ref],
amends: { recordKey: entry.recordKey, entry: 1 }, // entries count from 1
note: 'actor restated',
idempotencyKey: 'build-2026-09-15-0417:correction:2026-09-16T09:00:00Z',
});On the wire amends.seq is the entry's position counted from 0, so entry 1 is seq: 0; the SDKs take entry: 1 and convert. occurredAt stays the time of the build, because that is when the action happened; the correction's own time is when it was committed.
The record after
| Entry | Title | actorId | lifecycle |
|---|---|---|---|
| 1 | Model build 2026-09-15-0417 passed testing | ci-runner-7 | recorded, amended by entry 2 |
| 2 | Model build 2026-09-15-0417, corrected: the build ran on ci-runner-9 | ci-runner-9 | amended, amends entry 1 |
On the record page and the Shared Record, entry 1 reads "amended by entry 2" and entry 2 reads "amends entry 1", with the note beside it. Entry 1 is unchanged: its seal still matches and its receipt still checks. Whoever holds the link sees the pair and reads the note. The record is still named by entry 1's title.
When the correction is refused
A correction names an entry that is already committed and comes before it. Nothing is queued in either refusal.
| Code | The rule | What to do |
|---|---|---|
RECORD_AMENDS_NOT_FOUND (422) | The record has no entry at that number. | Check recordKey and the entry number. |
RECORD_AMENDS_NOT_PRECEDING (422) | The entry named is not yet committed, or comes after this one. | Wait for it to commit, or name the entry you meant. |
A correction is a write like any other: one idempotency key, QUEUED in the answer, then record.committed at your webhook or status: committed in the history.
What this is not
A correction does not delete, replace, or hide anything. The original stays as it was written, and the record shows that it was corrected and by what. If the entry you would correct is the record's first, its title is still the record's name. If what you need is to end the record, send lifecycle: closed instead; see Records and entries. A closed record can still be corrected, from a new record whose entry names the corrected one in both amends and references; the closed record stays closed and the correction lives beside it.