Posted: the seal, and unposting

Posted is a seal, not a status: the record is stamped with when and by whom, and becomes read-only everywhere — the grid, the record page, the drawer, imports, automations, and the API — until someone with delete-level access unposts it, with a reason, on the record. What the seal means Posting stamps the record — when, and by whom — and from that moment every write path refuses it: cell edits in the grid, the record page, the peek drawer, bulk edits, imports, automation steps, and the public API (which answers with a clean 409 rather than an error page). Posted rows wear a seal glyph, and the panel on the record collapses into the seal itself: Posted · date · name. The point is what the word starts to mean: a posted invoice is the invoice that was sent. Nobody "just fixes" a number on it three weeks later, because nobody can. What still works on a posted record The seal locks the record's content, not its usefulness: • Attachments and generated documents can still be added — they are notes pinned to the seal (the signed PDF of a posted invoice), not the sealed content. • Other records can still link to it — a payment can point at a posted invoice. • Comments and the conversation stay open. • Reading, filtering, reporting, exporting — all unchanged. Posted records are the ones your reports should trust most. What is refused Edits to any field, from any direction — including the paths people forget are write paths: imports that would update matching rows, automations whose step targets a sealed record (the run log says so plainly), and API writes. Subitem changes beneath it count as edits. And a posted record cannot be deleted: the seal outranks the bin — unpost first, then delete if you must. Unposting: the audited escape hatch Sometimes the sealed thing is wrong, so the seal opens — deliberately, and on the record. Unposting requires delete-level access (state reversal is a delete-class act) and always requires a reason, which lands in the audit trail and in the notification the interested people receive. Then fix the record, resubmit, and post again. Cascade sealing: parent and children together The policy can name Relation fields whose linked records post and unpost together with the parent — post the invoice and its line items seal with it, carrying the identical stamp; unpost it and exactly that set opens again. The cascade follows only the relations the policy names, one hop, so nothing the builder didn't choose ever locks by surprise. The period lock Give the policy a Date field and an Admin gets Lock period: pick a day, and every unposted record dated on or before it is posted in one action — closing June the way an accounting system closes June. It is the same seal, applied in bulk, and unposting a single record afterwards works exactly as it always does. Finding the posted Posted at is available to saved-view filters like any field — "Posted this month" is an ordinary saved view, and "Drafts only" is its empty-check mirror. The API returns postedAt and postedBy on every record payload, both null while the record is open. Tips • Keep a "Posted this month" saved view on financial tables — it is the closed set your reports and exports should point at. • Generate the PDF after posting and save it onto the record: the document then describes a record that can no longer drift from it. • Approval status chips colour themselves by meaning everywhere: Approved-type values go mint, Changes requested goes coral, Awaiting values go amber, and Posted wears the dark seal. Good to know • Deleting a posted record is refused everywhere, including bulk delete — unpost first. Bulk operations skip sealed rows and say how many they skipped. • Imports that update existing rows will report sealed rows as skipped rather than half-updating a batch. • Cascade sealing follows only the Relation fields named in the policy, one hop — grandchildren need their own policy or their own naming. • Unposting the parent releases the children posted with it in the same act — records posted separately, with their own stamp, stay sealed. Who can do what • Posting requires edit access on the table, or Admin — whichever the policy says. • Unposting requires delete-level access on top of that, plus a written reason; both the act and the reason are audited. • Adding attachments to a posted record follows the attachment field's own permissions — the seal does not tighten them. • The period lock is Admin-only.