What is a proof export?
A Cenelira proof export is a signed PDF, or an unsigned CSV record set, for schedules selected by a workspace export range.
Proof record
What a Cenelira proof export contains.
Every schedule in the export's date range becomes a proof record. The records are exported as a signed PDF for people or as an unsigned CSV file for systems. This page describes what the export contains, how the PDF is signed, how someone else verifies it, and what the record does not claim.
The description here is taken from the schema the product ships, so it stays in step with the code.
What does it record?
It records approval, target account, platform, publish outcome, exception, recovery and delivery-set fields, all taken from typed server state.
What does it avoid claiming?
It makes no claim about audience or reach, and it does not treat external reviewers as authenticated.
Schema v1
Every proof record carries the same 17 fields
There is one record for each schedule, in order of publish time. A field with no data shows a neutral placeholder, and no value is inferred or rewritten.
scheduleIdThe stable identifier of the schedule this record describes.
versionFingerprintThe fingerprint of the approved version of the schedule, which ties the approval to the exact content that was published.
targetAccountThe label of the destination account as the server resolved it, for example the connected brand handle.
platformThe platform identifier, such as instagram, x, linkedin, tiktok, youtube, pinterest, facebook or threads.
publishAtISOThe scheduled publish time, in UTC.
approverIdentityThe approver recorded for this schedule, with a tag saying how the approval was captured: (internal), (self-declared), (client contact, personal link) or (recorded by the team for the client).
approverSourceOne of four values: "internal" for a workspace user, "external_self_declared" for a name and email typed on a shared review link, "client_contact" for a saved client contact using their personal link, and "team_on_behalf_of_client" when a workspace owner or admin recorded that the client approved.
approvalTimestampWhen the approval was recorded, in UTC.
invalidationReasonIf an approval link stopped being valid before publish, the reason, which is expired or superseded.
publishOutcomeThe final outcome, which is one of these values:
queued, posting, published, publish_failed, handoff_pending, handoff_completed or canceled.publishedAtISOWhen the post was recorded as posted on the platform, in UTC.
platformPostIdThe platform’s own post id when a post was published.
exceptionCauseThe cause code from the reliability records when the schedule ended in an exception state.
recoveryActionThe next action from the reliability records for a schedule that is still in an exception state.
recoveryActorThe named owner of the recovery, or "system" when nobody owns the task.
deliverySetIdThe group identifier when the schedule belongs to a delivery set with several targets.
deliverySetMemberCountThe number of schedules in the same delivery set.
Two formats
A PDF for people and a CSV file for systems
Both formats carry the same 17 columns and the same number of records for a given date range. The PDF is the readable file for clients and auditors, and the CSV file is for machine processing and long-term storage.
Signed PDF
A PDF laid out like a legal brief, with one receipt block per schedule, a schema reference page and a verification page that carries the HMAC-SHA256 signature of the canonical payload. The PDF is tamper-evident: an edit to any field, timestamp or signature value makes verification fail.
Unsigned CSV
A flat CSV file with the same 17 columns in a fixed order, packaged with a JSON manifest that names the export id, workspace id, date range, generation time and record count. The same inputs always produce the same bytes.
How it is signed
The PDF is signed with HMAC-SHA256 over a tagged canonical payload
The signature is printed on the PDF's verification page, together with the canonical payload, which includes the signed manifest fields. Nothing secret is written into the file. The key id is a fixed fingerprint of the signing secret, so when the secret changes, the key id changes with it.
- AlgorithmHMAC-SHA256, the only algorithm, with no choice at run time.
- Canonical payloadA tagged envelope joining the schema version, the signed timestamp, the canonicalised manifest JSON, and the SHA-256 digest of the CSV record bytes. The exact text is printed on the verification page.
- Key identityA fingerprint derived from the signing secret that reveals nothing about it. The secret itself is never written into the file.
- Secret distributionThe workspace gives the signing secret to an external verifier by a separate channel. The PDF on its own is not enough to forge a signature.
- DeterminismGiven the same records, the same manifest, and the same secret, the canonical payload, the digest, and the HMAC are byte-for-byte identical.
How to verify
Anyone with the secret can verify the PDF in three steps
The verification page of every signed PDF prints the exact canonical payload text, the SHA-256 digest of that payload and the HMAC, and verification reproduces each value.
- Copy the canonical payload block.The verification page of the PDF prints the exact UTF-8 text that was hashed and signed, with its line breaks and byte order kept.
- SHA-256 the canonical payload and compare the digest.The page prints the expected canonical payload SHA-256. Any byte change in the payload changes the digest.
- HMAC-SHA256 the canonical payload with the shared secret and compare the signature.A constant-time comparison against the printed HMAC confirms that the file was produced by whoever holds the secret.
Reviewer identity
The record says how each approval was captured
The record tags every approver, so it is always clear how an approval was captured.
Internal
This approver is inside the workspace, and their identity is tied to a workspace user account at the moment of approval. The record stores that identity, the timestamp and the fingerprint of the approved version.
External (self-declared)
This approver used a shared review link, and Cenelira does not authenticate external reviewers. The name and email the reviewer typed are stored on the record and labelled (self-declared) on the PDF. Only internal approvals are cryptographically tied to a Cenelira account.
Client contact (personal link)
This approver is a client contact the workspace saved, using the personal link issued to that contact. Nothing is typed, so the record carries the saved contact's name and no email address, and no name at all once that contact's data has been erased.Cenelira does not sign the contact in: holding the link is what identifies them.
Recorded by the team for the client
A signed-in workspace owner or admin recorded that the client approved another way, for example by phone. The approver named on the record is that team member, and the tag says the approval was recorded for the client. The client did not act in Cenelira.
What the proof does not claim
The limits of the record, stated in the file itself
A proof export is a record of what happened inside Cenelira. Some claims belong to the signer, the reviewer or the platform, and the file says where each piece of evidence comes from.
- A reviewer on a shared review link types their own name and email, and Cenelira does not authenticate them. A client contact on a personal link is identified only by holding that link. The PDF cover says which of these applies to its records.
- The signing secret is not written into the file, so a verifier needs the shared secret to reproduce the HMAC.
- The record reflects the publishing workflow and what the platform answered. It makes no claim about audience, delivery or reach.
- Only schedules owned by the exporting workspace are included, and the record never covers other workspaces or other accounts.
- Every field comes from typed server state. Nothing is written up for the buyer, and no value is inferred.
FAQ
Short answers for proof review
What does the proof export contain?
Each selected schedule becomes one proof record with 17 fields, including approval, target account, platform, publish outcome, exception, recovery and delivery-set fields.
Does the PDF cover audience or reach?
No. The proof export records the state of the workflow and what the platform answered, and it makes no claim about audience, delivery or reach.
Are external reviewers authenticated?
No. A reviewer on a shared review link types their own name and email, so that identity is self-declared. A saved client contact using a personal link types nothing and is identified only by holding that link. Internal approvals are tied to workspace user accounts.
How is the PDF verified?
A verifier copies the canonical payload, checks its SHA-256 digest, then computes HMAC-SHA256 with the shared signing secret and compares the printed signature.
Get notified when proof-led checklists ship.
A short checklist on how to run proof-led publishing without breaking it. Leave an email and we will send it when the checklist is ready.