What an approval record is worth

What is written when a client decides

A decision from the portal writes three things in one transaction. A decision row on the approval, with the verdict - approved or changes requested - the comment, an actor type of portal and no user id. An audit row in the studio's own vocabulary saying the approval was approved or changes were requested, with the comment. And the approval itself is marked decided with the time.

After the write is durable, a second audit row records that the decision came through the portal: which door, which session, and which review round heard it. Only then are the studio's people notified, so a mail outage can never roll back a verdict, and the board moves according to the workflow's own rules.

A decision a producer records on the studio side writes the same rows with the producer's user id and an actor type of user. The two are never the same row, which is what lets the studio say with confidence whether the client pressed the button or the studio did on their word.

Which version

The version question is answered by the review round. A round is one review of one version, opened once and closed once by exactly one verdict, never reopened. When the client decides from the portal and the approval's task has a review room open, the verdict is recorded in that room, and the audit row for the portal decision names the round. The round names the version.

The portal itself shows the client the version number of what they are looking at, so the client and the studio are reading the same number at the moment of the decision. In the studio's room, two versions can be compared side by side with notes carried to the next version, so the path from the note on version two to the approval on version three is readable end to end.

Which door, and who was behind it

A door has a label the studio chose - a client, or one person at the client - and a kind: code, link, phone or email. A door that demanded a one-time code by SMS or email ties the session to a phone number or an address that received the code, and the sending and any failed attempt are audited. The session records the IP address and the browser, and the door counts how many distinct devices have ever used it.

So the record for a decision reads: door 'Dana, marketing', kind email with a one-time code, session opened on this date from this address, decision approved at this time on version three. A door for the whole client with no one-time code reads less specifically, and the studio chooses which it wants when it issues the door.

A denied entry is recorded too, with the reason - not found, revoked, expired, one-time code required - kept for the studio and never shown at the door. A link being hammered is visible in the log before it is a problem.

Append-only means append-only

The audit table has no update path and no delete path in any scope of the application, and a check in the build refuses code that would add one. A row written is a row kept. Correcting the record means writing another row that says so, the way a ledger does.

The trail outlives the people in it. When a user account is deleted, the account's rows are hard-deleted, but every audit row points at the user through a link that is set to null rather than cascaded, and the actor's email was stamped on the row at write time. A year later the row still says who did it.

The same rule keeps a freelancer's departure from erasing a studio's work: projects, tasks, comments, approvals and files are authored by a link that is nulled on deletion, not cascaded.

The whole trail around a decision

A decision is one row among many the portal writes. The trail around it includes the door being issued, with its settings and never its credential; the invitation being delivered; the door being revoked; every entry and denied entry; every one-time code sent or failed; every note posted; every brief uploaded; every deliverable downloaded; every reminder sent, by a person or by the system; and every revision round that passed the agreed number, with the round count. A change to the agreed number of rounds is audited with the old and new values.

The studio's side of the portal lists each door with first opened, last seen, distinct devices and the count of client approvals recorded. That table is read from the same rows; it is not a second source that could disagree.

• Decision: verdict, comment, actor type, time, door, session, round.
• Door: issued, delivered, revoked, entered, denied with reason.
• Around it: notes, uploads, downloads, reminders, rounds exceeded.

Erasure, export and what survives

A workspace owner can export everything the workspace owns into one file from the settings screen, and can delete the workspace or their own account without asking anyone at Tasked. Deletion is behind three gates: the workspace's or account's own identifier typed out, a fresh re-authentication, and a confirmation that names the date the action stops being reversible. An account that is the last owner of a live workspace cannot be deleted until that is resolved.

The published window is 30 days. A deleted workspace is exported, marked deleted, and destroyed permanently 30 days later by a daily purge; the same window is the one the terms, the privacy policy and the data processing agreement state, and a test in the build fails if the code and the published sentences ever disagree. The export is a zip fetched through a signed link that lives five minutes.

The audit trail survives the deletion, stripped of identifying detail, so what happened can still be shown. That is the record's worth: the approval that a client questions in a year is still there, with who, when, which version and which door, whether or not anyone involved still has an account.

Questions that keep coming up

Can an approval record be edited or deleted?

No. The audit log has no update or delete path in the application, and a build check refuses code that would add one. A correction is another row.

Does the record say which version was approved?

Yes. The decision names the review round it closed, and a round is one review of one version. The client also sees the version number on the page they decide from.

What does the record say about who decided?

The door label and kind, whether a one-time code was demanded and to which phone or email, the session's IP address and browser, and whether the decision came from the portal or was entered by a studio member with their user id.

What happens to the record if the studio deletes its workspace?

The workspace is exported, marked deleted, and purged after 30 days. The audit trail is kept beyond that, without identifying detail.

Can we get a copy of our data?

Yes. A workspace owner requests an export from the settings screen and downloads the zip through a signed link. No request to Tasked is needed.