Data model

How PactPal's database is organised, in plain words. Tables marked built exist in a migration; tables marked planned show where later sub-phases are heading and may change. Column details for built tables live in the migration (packages/db/src/migrations.ts); this page explains what they mean and why.

erDiagram
  users ||--o{ deals : "sells (seller_id)"
  users |o--o{ deals : "buys (buyer_id)"
  deals ||--o{ ledger_entries : "has events"
  users |o--o{ ledger_entries : "acted (actor_user_id)"
  deals ||--o{ scope_versions : "agreed work"
  ledger_entries |o--o| scope_versions : "recorded by"
  deals ||--o{ acceptances : "signed"
  scope_versions ||--o| acceptances : "version signed"
  ledger_entries |o--o| acceptances : "recorded by (ACCEPTED)"
  users ||--o{ acceptances : "signed by (buyer_id)"
  deals ||--o{ milestones : "invoiced stages"
  deals ||--o{ deliveries : "delivered work"
  deliveries ||--o{ delivery_files : "files"
  artifacts ||--o{ delivery_files : "delivered as"
  scope_versions ||--o{ milestones : "stage of"
  ledger_entries |o--o| milestones : "recorded by (INVOICE_SENT)"
  deals ||--o{ artifacts : "has files"
  deals ||--o{ scope_drafts : "AI drafts"
  artifacts ||--o{ scope_drafts : "drafted from"
  ledger_entries |o--o| scope_drafts : "recorded by (when ready)"
  ledger_entries |o--o| artifacts : "recorded by"
  webhook_events }o--o{ deals : "matched later (Phase 4 and 5)"
  deals |o--o{ disputes : "disputed (when matched)"
  ledger_entries |o--o| disputes : "opened and decided by"
  users ||--o{ sessions : "signed in"
  users ||--o{ link_tokens : "buyer links"
  users ||--o{ seller_connections : "PayPal connections (Phase 6)"
  deals ||--o{ link_tokens : "for one deal"

#Rules that apply everywhere

• Ids are uuids chosen by the server code (passed in, so tests are exact), never counters that reveal how many deals exist.
• Money is whole minor units (cents) plus a currency code, never decimals. A deal has one currency; amounts live on the payment stages (milestones) of the agreed work.
• Times are UTC and taken by the server.
• Changes to the structure are numbered, forward-only migrations. The database refuses edits and deletes on evidence tables.
• Personal data is kept to the minimum: email, one display name, PayPal ids. The evidence log refers to people by user id, so a user row can later be anonymised without touching the log. How long each kind is kept is in privacy.md: a deal's whole record 210 days after its last activity (held while a PayPal dispute is open), raw notifications and AI drafts 60 days (9c).

#Built (sub-phases 2b to 6h-1)

users: everyone

One row per person. "Seller" and "buyer" are roles on a deal, not kinds of person, so one person can sell in one deal and buy in another.

A person invited by email has no PayPal ids. If they later sign in with PayPal, their row is linked (only when the email is proven both ways; built in 2e).

deals

A dispute is not a deal status: disputes get their own table in Phase 5.

How the status moves (4a), each change in one transaction with its log entry:

The agreed work can be edited only in draft, so the version sent is the version signed.

ledger_entries: the evidence log

One row per event, never changed or removed. An entry is identified by its deal and its position (deal_id, seq), so a citation reads deal:seq.

What protects it: the database refuses updates, deletes and truncation; a deal or user with entries cannot be deleted; and verification recomputes every fingerprint and link and names the first bad entry. Someone with full database access could switch the refusal off, but could not hide the change from verification.

artifacts and file_contents: the deal's files

A file is stored once, by the SHA-256 of its bytes, in file_contents; artifacts says which deal it belongs to and what it is. Both tables are append-only. Adding a file saves the bytes first, then in one transaction writes the ledger entry (SOURCE_ADDED or DELIVERABLE_ADDED) and the artifact, so a record never points at missing bytes.

On the website (2f-4) the seller adds source files; both sides list and download them, and every download is checked against the fingerprint first. Delivered work (deliverable) is added through delivery links in Phase 4.

Since 5b the buyer also adds source files (reference material such as a brief or pictures), signed in or by their private link: added_by is then the buyer, and the SOURCE_ADDED entry has actor buyer with IP address and browser. A buyer adds only PDF, PNG, JPEG, GIF or plain text, at most 20 files and 20 MB per deal. The files list says who added each file (seller, buyer or PactPal).

artifacts has no database link to file_contents, so the bytes can move to object storage later by changing one adapter. Limits protect the 1 GB database: 10 MB per file and 50 MB per deal.

webhook_events: notifications as received

A webhook is a message PayPal posts to our server when something happens (an invoice created or paid). Each genuine one is saved here in full, exactly once, before the server answers "got it", so a repeat is recognised even after a restart and nothing PayPal tells us is lost. Handling the contents (a milestone paid, a dispute matched) comes in Phases 4 and 5; this table is not the evidence record, the ledger is.

Unlike the ledger it can be changed and deleted: the daily retention clean-up (9c) removes events 60 days after they arrive.

sessions: who is signed in

One row per sign-in. The browser holds a random 43-character token in a cookie that page scripts cannot read; the table stores only the token's SHA-256, so the table itself cannot be used to sign in.

An expired session is refused and removed when it is next used; signing out deletes it.

link_tokens: buyer links

A private link that lets a deal's buyer into that one deal without a PayPal account. The secret travels after # in the address (/link#t=...), so the server never logs it; only its SHA-256 is stored. Opening the link shows a "Continue" button, because mail scanners open links but do not press buttons.

Using a link marks the buyer's email as proven and starts a session limited to that deal.

scope_versions: the agreed work

What a deal covers and how its price is split into payment stages. Each save by the seller is a new numbered version; old versions are kept and the database refuses edits, deletes and emptying the table.

When a version is saved from an AI draft (see scope_drafts), the ledger also gets a SCOPE_CONFIRMED entry right after the SCOPE_VERSIONED one: the version, its fingerprint, the draft's id and fingerprint (the stored winner's), and, when the council could not rank its drafts and the seller chose one, usedCandidate (its letter and fingerprint); then for each of summary, deliverables, exclusions, revisions, due date and total price whether the seller kept it (unchanged), changed it, added it (the draft left it missing) or removed it. It holds no text. When usedCandidate is present, the kept/changed words compare with that draft, not with the winner.

Payment stages are part of the content, so their titles and amounts are fingerprinted and frozen with the rest: changing an amount means saving a new version. Only the seller can save, and only while the deal is a draft.

Since 4i the content can also hold buyerProvides: up to 20 things the buyer provides, each with text (1 to 500 characters) and an optional date. It is still format 1: the list is optional and never stored empty, so versions saved before it existed keep their exact content and fingerprint. The acceptance document's terms carry it only when present, so documents for older versions are rebuilt byte for byte.

Since 4i-2 the content can also hold deliverableKinds: one mark per line of what will be delivered, in the same order: objective (can be checked), process (a step in the work), subjective (a matter of taste, with the approvalStage whose approval by the buyer settles it), or null (not marked). It is stored only when at least one line is marked, must have one entry per line, and a stage must exist in the version. The acceptance document carries it only when present. The deliveries view lists, for each delivery, the matters of taste its stage settles.

acceptances: signed agreements

What the buyer signed, kept whole. Built in 4a (migration 0009). Append-only: the database refuses edits, deletes and emptying the table.

The buyer's page is drawn only from an acceptance document (format 1), plain data built by the server: the deal title, category, the seller's display name, the version of the agreed work with its fingerprint, every term with amounts in minor units and as text, the total, and the notice shown above the sign button (with its version). Its fingerprint is the SHA-256 of its canonical JSON. When the buyer signs, the server rebuilds the document and refuses if it differs from the one their page showed.

The ACCEPTED entry holds the version, the content and document fingerprints, the typed name, the notice version and how the buyer reached the page (link or paypal), plus the browser and, when known, the IP address. The typed name and the terms are personal data, so they go with the deal, 210 days after its last activity (9c). Change orders (4j) will add further rows for later versions.

When the email service accepts a receipt email (4c), a RECEIPT_SENT entry (by the system) records the version, which side it went to (buyer or seller), the receipt's SHA-256, a SHA-256 of the lower-cased address (never the address) and Resend's message id. A failed send records nothing. At most 5 receipt emails are sent per signed version.

The receipt PDF (4b) is not stored: it is made from the newest row each time it is downloaded, after checking the row against its fingerprint and against its ACCEPTED entry (same document fingerprint, typed name and time). The same row always gives the same bytes.

milestones: payment stages invoiced through PayPal

Built in 4d (migration 0010). One row per payment stage of the signed version that has a PayPal invoice; the stage's title, amount and due date stay in the signed version (scope_versions), so they are fingerprinted with it. Not append-only: the status moves on, and the evidence is the INVOICE_SENT entry.

PAYMENT_RECEIVED (by the system, 4e) holds the version, stage, PayPal invoice id, the amount PayPal says was paid, PayPal's transactions (id, date, method) and how PactPal learned of it (notification with PayPal's event id, or status-check). It is written once, only after PactPal re-read the invoice from PayPal and found it PAID.

Since 5a (migration 0020) a paid stage also keeps invoice_number, PayPal's own number for the invoice (not its id), read from PayPal's answer when the payment is recorded, so a dispute can be matched by it.

Since 6h-3 (migration 0031) a stage also keeps seller_connection_id: the seller's own linked app its invoice is sent from (a seller_connections row), or empty for PactPal's own test seller app. It is set when the stage is reserved and never changes, so retries, payment checks and disputes always use the account that made the invoice. The INVOICE_SENT entry of such an invoice also carries paypalAccount, the seller's PayPal account id.

INVOICE_SENT (by the seller) holds the version, stage, PayPal invoice id, amount and currency, the fingerprints of the agreed work and of the invoice text, a SHA-256 of the buyer's lower-cased address (never the address) and the route PayPal answered by (rest).

deliveries and delivery_files: delivered work

Built in 4f (migration 0012); both append-only. A delivery is a set of the deal's delivered files (artifacts of kind deliverable) for one stage of the signed version, with an optional message (up to 1,000 characters), sent by the seller. A stage can have several deliveries. delivery_files lists each delivery's files in order and only allows files of the same deal.

Delivered files are not listed or served with the deal's source files: they are reached only through their delivery, so every buyer download is logged. The log entries:

• DELIVERY_SENT (seller): the delivery, version, stage, message and each file's id, name, size and SHA-256.
• DELIVERY_EMAILED (system): the delivery, a SHA-256 of the buyer's lower-cased address and the email service's message id; written only when the email was accepted. Each email carries a fresh private buyer link.
• DELIVERY_VIEWED (buyer, with IP address and browser): the delivery and how the buyer came in (link or paypal); at most once per delivery every 10 minutes.
• DELIVERY_DOWNLOADED (buyer, with IP address and browser): the delivery and the file's id, name, size and SHA-256; every download, after the file's bytes passed their fingerprint check. The seller's own downloads are not logged.

delivery_answers: the buyer's answer to a delivery

Built in 4g (migration 0013); append-only. The buyer answers a delivery once, and only after opening it (a DELIVERY_VIEWED exists): they approve it, or they request changes. The database refuses a second answer to the same delivery, so two tabs cannot answer twice. After a change request the seller sends a new delivery for the same stage, which can be answered in turn.

Revisions are counted across the whole deal and compared with the signed version's revisionsIncluded. A request beyond that number is never refused: it is recorded as beyond the included revisions. The log entries (both by the buyer, with IP address and browser):

• MILESTONE_APPROVED: the delivery, version, stage and each delivered file's id and SHA-256.
• CHANGE_REQUESTED: the delivery, version, stage, the request, the revision number, the revisions included (or none when the agreement states no limit) and beyondIncluded.

When an approval leaves every payment stage of the signed version with an approved delivery, the deal's status becomes completed in the same transaction; the approvals are the evidence, so there is no separate entry. Invoices and deliveries still work on a completed deal.

Evidence completeness score: computed, not stored

The score (4h) has no table. It is worked out from ledger_entries and the signed (or newest) version in scope_versions each time the seller's page asks, so it always matches the log.

change_orders: changes to a signed agreement

Built in 4j (migration 0014). After the buyer has signed, the seller can propose a change order: a later version of the agreed work, stored in scope_versions like any other, that only adds to the signed one (lines with their marks, exclusions, buyer-provides items and payment stages after the signed ones, a new overall due date, more revisions when the agreement states a number). The buyer signs it as they signed the agreement (a new acceptances row for the new version), or declines it; the seller can withdraw it while it waits. At most one change waits per deal.

The log entries:

• CHANGE_ORDER_PROPOSED (seller): the change, both versions, the new content's fingerprint and total, how much was added, and the message.
• CHANGE_ORDER_ACCEPTED (buyer, with IP address and browser): what ACCEPTED records, plus the change and the version it changed. The receipt of the new version is emailed as after the first signature.
• CHANGE_ORDER_DECLINED (buyer, with IP address and browser): the change, the version and the reason, if any.
• CHANGE_ORDER_WITHDRAWN (seller): the change and the version.

The emails about a change (to the buyer when it is proposed, with a fresh private link; to the seller when it is answered, 4j-2) are notices and are not logged.

A stage is the same stage in every version, because a change order only adds. So a deal has at most one invoice per stage (milestones_one_per_stage), an invoice, payment, delivery or approval counts for its stage whatever version it happened under, and the deal is completed when every stage of the current signed version is approved. A completed deal that gains stages is active again. Once signed, the deal page shows the signed version as the agreement; a waiting or declined change is shown on its own.

buyer_questions: questions about the agreement before signing

Built in 4k (migration 0015). While the buyer is asked to sign, they can ask about the page they see. A model answers only from the agreement's numbered lines, and the answer is shown only when code finds every quote on its line; otherwise the question goes to the seller, who answers it. At most 20 per deal, and one being answered at a time.

The database refuses any other move, any change to what a step recorded, and any removal.

The log entries:

• BUYER_QUESTION (buyer, with IP address and browser): the question, the version and the page's fingerprint.
• AI_ANSWER_SHOWN (system): the question, the answer's fingerprint, the model, the prompt version and the cited line numbers. The answer's text stays in buyer_questions.
• QUESTION_FORWARDED (system, or the buyer with IP address and browser for "Ask the seller instead"): the question and the reason.
• QUESTION_ANSWERED (seller): the question and the seller's answer.

The emails about a question (to the seller when it is sent to them; to the buyer, with a fresh private link, when the seller answers, 4k-2) are notices and are not logged.

delivery_checks: the seller's pre-delivery checks

Built in 4l (migration 0016). Advice for the seller only, kept apart from the evidence log: nothing about a check is logged, and the buyer never sees it. Rows are never changed or removed. At most 20 per deal.

message_reviews: council reviews of the buyer's messages

Built in 4m (migration 0017). The seller pastes a new message from the buyer on a signed deal. The message is saved as a source file (artifacts, logged SOURCE_ADDED) and a council reviews it. The review is advice for the seller only, kept apart from the evidence log, and the buyer never sees it. A review moves once, from running to ready or failed, and is never removed. At most one runs per deal, and a deal has at most 30.

Chat screenshots (4o) are source files like any upload (SOURCE_ADDED). The text a model reads from them is not stored: it only fills the chat box, and what the seller checks and drafts from is saved as the chat file.

intake_keys: sellers' private keys for creating deals from other tools

Built in 4p (migration 0018). A tool posts text with a seller's key, and a draft deal is created for that seller with the text saved as a source file. DEAL_CREATED then also records via: "intake" and the key's last 4 characters.

Since 4p-2 (migration 0019) a row is one of two kinds: a key for other tools, or an address for forwarding emails to deals+<code>@in.pact-pal.app. A forwarded email from the seller's own address that passes SPF or DKIM becomes a draft deal the same way, with via: "email" and the address's last 4 characters. The Resend event is saved once in webhook_events (source resend).

A key keeps its owner, kind, hash and defaults, is turned off once, and is never removed.

agent_requests: what an agent asks the seller to let it do (8c)

Built in 0040, which also lets intake_keys.kind be agent (the key an MCP client sends) and notifications.kind be agent-request. One row per request; status moves waiting → approved or declined, then done, failed or expired.

Log entries: AGENT_REQUESTED (kind, key ending, body fingerprint), AGENT_REQUEST_ANSWERED (approved or declined), AGENT_ACTED (result); the action itself is logged by its own step (such as INVOICE_SENT). Deals an agent makes from text record via: "agent".

scope_drafts: AI drafts of the agreed work

A draft is a proposal made by the council from a chat saved as a text source file. It is not evidence and not an agreement, so it lives in its own table and is not append-only: a row starts as running and moves once to ready or failed. Only a ready draft is recorded in the ledger (SCOPE_DRAFTED, by fingerprint, never with text). Nothing becomes agreed work until the seller confirms it (3e).

Lines of the chat that look like orders to an AI are not stored anywhere; they are found again from the chat file whenever a finished draft is read (source.hiddenLines, line numbers only). A deal can have at most 10 drafts. A draft still running when the server restarts is marked failed. The chat quotes inside draft and council are personal data, so a finished draft is removed 60 days after it finished; its fingerprint stays in the log (9c).

Drafts made with drafting prompt version 3 (4n) are "format 3": each delivered line also has a suggested mark (objective, process, subjective or unsure) and the draft lists what the buyer provides (text, a date or none, citations). Older drafts stay "format 2" and are read as they are. When agreed work is saved from a draft, SCOPE_CONFIRMED also says for buyerProvides and deliverableMarks whether the seller kept the draft's suggestion.

disputes: PayPal disputes found by checking

Built in 5a (migration 0020). A Render Cron Job starts the Workflow task check-disputes every 5 minutes (also "Check now" and any PayPal dispute notification). It reads the seller's dispute list, reads in full each dispute that is new or changed, ties it to a paid stage and saves it here. A working copy of PayPal's latest answer, not evidence: it moves with PayPal, but once tied to a deal it stays tied, keeps the log entries that recorded its opening and decision, and is never removed.

The log entries (all by the system; ids and PayPal's words, never the buyer's messages):

• DISPUTE_OPENED: once, when the dispute is first tied to a deal: dispute id, reason, status, PayPal stage, amount, seller due date, payment stage, invoice id and how it was matched.
• DISPUTE_UPDATED: when the status, PayPal stage or seller due date changes, with before and after. A change only to what the seller may do is saved on the row, not logged.
• DISPUTE_RESOLVED: once, with PayPal's outcome and the final status.

dispute_checks: each check of the seller's disputes

Built in 5a (migration 0020). One row per check: source (schedule, button or notification), started_at, finished_at, the counts (listed, read_in_full, matched, unmatched, new_entries) or failure (PayPal's status only, never its text). The deal page shows the newest one as "last checked". Old rows can be removed later; nothing refers to them.

claim_analyses: council comparisons of a dispute claim with the record

Built in 5d (migration 0021). A draft for the seller only, kept apart from the evidence log. It moves once, from running to ready or failed, keeps what it recorded and is never removed. One runs per dispute at a time, at most 10 per dispute, and one still running after 15 minutes is marked failed ("did not finish in time").

CLAIM_ANALYZED (by the system) holds ids, fingerprints, prompt versions, model names, the winner, the number of statements and whether it needs review; no AI text.

Since 5f (migration 0023) the table also holds packet summaries: kind is claim (a comparison) or summary, and based_on names the comparison a summary was drafted from (set for summaries only). One runs per dispute per kind at a time, at most 10 per dispute per kind. For a summary, analysis holds the sentences with their log entries, the document picks and the draft note; claim_sha256 is the fingerprint of the comparison rows it read. A ready summary logs SUMMARY_DRAFTED (by the system): ids, basedOn, the fingerprints of the draft, of the comparison rows, record lines and document list it read, models, the winner and the number of sentences; no AI text.

Since 5h (migration 0025) kind may also be response: answer help, with no based_on. Its analysis holds the draft message, one note per option PayPal allowed (with record entries) and the offer note; a ready one logs RESPONSE_DRAFTED (by the system): ids, fingerprints, models, the winner and the number of options; no AI text.

Since 5i (migration 0026) kind may also be appeal: the appeal check. Its analysis holds a judgement per new item (whether it speaks to the claim, why, cited entries) and a short summary; a ready one logs APPEAL_CHECKED (by the system): ids, the fingerprint of the new-items list (itemsSha256) and of what the models read, models, the winner and how many items it judged as speaking to the claim (speaking); no AI text. Since 5i the dispute's stored details also hold decisionReasons (PayPal's decision reason codes) and sellerEvidence (evidence PayPal lists as sent by the seller: type and document names).

Since 5k-fix-1 the stored details also hold readVersion (how PactPal read the answer, now 2; a copy with another or no version is read again once), and the buyer's messages include what the buyer wrote in their own evidence entries (SUBMITTED_BY_BUYER notes).

Since 5i-2 (migration 0027) kind may also be statement: the appeal statement, based on a ready appeal check (based_on). Its analysis holds the sentences with their record entries and the note; a ready one logs APPEAL_DRAFTED (by the system): ids, basedOn, fingerprints, models, the winner and the number of sentences; no AI text.

Since 5d the dispute's stored details also hold requestedEvidence: the evidence types PayPal asks the seller for.

evidence_packets: built evidence packets

Built in 5e (migration 0022); append-only, at most 20 per dispute. One row per packet the seller builds for a dispute.

PACKET_BUILT (by the seller) holds the packet id, dispute id, the packet's fingerprint and size, each included exhibit's id and fingerprints, how many were left out, the total size and the seal, and since 5f the AI comparison and summary ids with the fingerprints of the two drafts when the packet carries them.

dispute_actions: what the seller sent PayPal for a dispute

Built in 5g (migration 0024). One row per escalation or evidence upload the seller confirmed. A row moves from sending to sent, refused or unknown; an unknown one may go back to sending to be sent again with the same request id. Nothing it recorded changes and nothing is removed. One sending row per dispute at a time; at most 10 evidence uploads per dispute, refused ones not counted.

Since 5h (migration 0025) a row may also be a message to the buyer, a refund offer or an accept of the claim. offer_type (REFUND), amount_minor and currency are set for an offer (the amount offered) and an accept (the disputed amount refunded), and kept as confirmed. Sent ones log DISPUTE_MESSAGE_SENT, OFFER_MADE (with the type and amount) or CLAIM_ACCEPTED (with the amount), by the seller.

Since 5i-2 (migration 0027) a row may also be an appeal: like evidence, with a packet, an evidence type and the files sent; a sent one logs APPEAL_SUBMITTED (by the seller) with the same fields as EVIDENCE_UPLOADED.

DISPUTE_ESCALATED and EVIDENCE_UPLOADED (by the seller) hold the action and dispute ids, the note's fingerprint, the transport and PayPal's debug id; an upload also holds the packet id, the evidence type, each file's exhibit number, name, size and fingerprint, and the total size. Never the note's words.

dispute_notices: emails sent to the seller about disputes

Built in 5j (migration 0028); append-only. One row per email key: a new dispute, a change, PayPal's decision or a deadline reminder. Notices, not evidence: they never go in the evidence log.

seller_connections: sellers connected to their own PayPal account

Built in 6c (migration 0029); own apps added in 6h-1 (migration 0030) and their alert address in 6h-4 (migration 0032). One row per attempt to connect through Partner Referrals ("Connect with PayPal"), or per link of a seller's own REST app. Not append-only, because the status changes, and not evidence. Ending a connection keeps the row, and reconnecting makes a new one, so it stays known which PayPal account past invoices came from. Sellers with no live connection use PactPal's own test seller app, as before. Nothing on the site writes rows yet: own apps from 6h-2, Partner Referrals from 6d.

The database refuses a connected row without an account or time, a pending row with either, and a disconnected row without its time. A Partner Referrals row needs its tracking id and holds no app keys; an own-app row needs its client id, is never pending, holds its sealed secret while connected, and no row holds a secret once ended. At most one connected row per user and one per PayPal account (partial unique indexes), so a dispute can never be shown to the wrong seller.

deal_messages: the deal's chat (7b)

Messages from the deal's seller and buyer, and PactPal's own cards in the chat. Append-only: a message is never edited or removed.

A deal holds at most 5,000 messages; a cancelled deal's chat is closed.

message_reads: how far each person has read (7c)

One row per deal and person: read_seq (the last message they have read; it only moves forward), logged_seq and logged_at (what was last written to the log). It changes as they read, so it is not append-only; the evidence is the MESSAGES_READ entry (upToSeq), written when the position has moved, at most once a minute per person, and always when their page closes.

notifications: what needs each person (7e)

Not evidence: the log records what happened. News (signed, step-news) is marked read when the person opens the tab it points at (7o); the other kinds ask them to act and stay until opened from the list. A person has at most one unread message notification per deal; later messages fold into it until they read the chat, which also marks it read. Each new notification is emailed (the buyer's with a fresh private link), except a message while the person has the deal open. Emails never quote a message.

retention_runs: each daily clean-up (9c)

One row per run of the retention-sweep Workflow task: when it ran, whether it was a dry run, its two cutoffs (deals_before, 210 days back; short_before, 60 days back) and counts, the number of rows removed per kind (deals, deals held by an open dispute, deals that failed, notifications, drafts, sessions, buyer links, unmatched disputes, file bytes). No personal data and no deal ids.

The guarded tables still refuse every UPDATE. Since migration 0041 each also has a <table>_no_delete guard that refuses every DELETE unless the transaction has set pactpal.retention_purge = 'on' (SET LOCAL). Only the clean-up sets it, and it removes a deal from every table in one transaction (purgeDeal), so a deal is never left in part. File bytes go when no file or packet uses them any more.

#Phase 7 (deal space)

Being built in 7b–7m; each table is described in full above once it exists.

#Planned