The binder migration — bringing existing paper consents into Ansikt

Mette took over the comms role on Tuesday. The previous volunteer left her two things she did not expect: a binder of signed paper consents from past seasons, and a folder of scanned PDFs on the shared drive. Before she touches the photo archive — let alone publishes anything new — she needs the consents on file.

Setup is done. Library affirmed, the five club Purposes defined, the Channels listed. Now she runs the consent migrator to bring the paper trail in.

Mette drops her stack of paper consents and PDFs into the migrator. Ansikt extracts only the identifiers it needs to bind the document to a subject — name, email, signed date, expiry date. The consent text itself is not parsed. Per file, she gets a row in a queue.

She walks the rows one at a time. On the left, the source PDF rendered readable so she can see the document in context. In the middle, the extracted identifiers with two affordances per row: edit inline, or flag wrong. On the right, three blocks: match the person to an existing Library record or create a new one; pick which of the Campaign's Purposes the original consent granted — Mette attests, per document, that the Campaign's Purposes match what was granted; and pick how to record the consent.

The subject already consented — on paper, in a PDF, on a form Mette has in front of her. She is not taking new consent; she is linking consent that was already given into Ansikt's record. She confirms, per document, that the Purposes she is linking match what was originally granted. The audit log records her confirmation. The subject does not receive a fresh notification because no new decision is being taken on their behalf. Provenance lives in the audit row forever — subject · portal-confirmed, operator · notified-and-asserted, or operator · confirmed.

One row in the queue shows the misclassification path. The extractor grabbed 2018-08-12 for the signed date — but that timestamp is the document-creation footer at the bottom of the PDF, not the signature line. Mette flags it; the value is rejected, the field opens for manual entry, and the PDF preview's highlight turns red-dashed. Without that affordance she would have imported a wrong date sourced from a footer.

The migrator gave Mette a roster of imported people, each with a consent on file. None of those records carry a reference photo — the PDFs do not have one. She opens the photo library and runs roster labelling: one tap per imported person on a clear face. The recogniser clusters the rest of that person's appearances across the archive on its own.

Same Day-0 onboarding beat the rest of the site describes — cleanup mode, applied to a backlog instead of a fresh roster.

Every imported consent now lives in the consent ledger. Each row carries its provenance label — subject · portal-confirmed, operator · notified-and-asserted, or operator · attested — alongside the standard signed date, scope and Purposes. The Article 15 export distinguishes them. A DPO or external auditor can tell at a glance which decisions came from the subject and which were recorded on their behalf based on a paper form.

Honest by structure. Asserted consents are not dressed up as subject grants.

Six months later, a parent of a former youth player writes in: please remove every photo of my son. The portal opens for them on a fresh magic link, or Mette updates on their request. The cascade is the same — proxy-blur where a channel serves through Ansikt, manual takedown where it does not.

Operator-asserted consents revoke as cleanly as subject-granted ones. The audit trail captures the withdrawal alongside the import — both the moment of consent (whoever asserted it) and the moment of revocation are on the same row.