Proof record

What a Cenelira proof export contains.

Every schedule selected by the export range becomes a proof record. The record is bundled into a signed PDF for people and a CSV twin for systems. This page describes exactly what is in the export, how the PDF is signed, how a third party verifies it, and what the record does not claim.

The description here is drawn from the schema the product ships. No separate marketing copy is allowed to drift from the code.

Definition

What is a proof export?

A Cenelira proof export is a signed PDF and CSV record set for schedules selected by a workspace export range.

Mechanism

What does it record?

It records approval, target account, platform, publish outcome, exception, recovery, and delivery-set fields from typed server state.

Limit

What does it avoid claiming?

It does not claim audience, reach, or authenticated identity for external reviewers.

Schema v1

Every proof record carries the same 17 fields.

One record per schedule, ordered by publish timestamp. Fields with no data render as a neutral placeholder. No value is inferred, no value is rewritten.

scheduleIdThe stable identifier of the schedule this record describes.

versionFingerprintFingerprint of the approved schedule version. Ties approval to the exact content that was published.

targetAccountServer-resolved label of the destination account (for example, the connected brand handle).

platformPlatform identifier such as instagram, x, linkedin, tiktok, youtube, pinterest, facebook, threads.

publishAtISOScheduled publish instant in UTC.

approverIdentityThe approver recorded against this schedule. Marked (self-declared) when the approval came via an external review link.

approverSourceEnum value: "internal" for a workspace user, "external_self_declared" for an external review link.

approvalTimestampWhen the approval event was recorded, in UTC.

invalidationReasonIf an approval link was invalidated before publish, the typed reason: expired or superseded.

publishOutcomeTerminal outcome: 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 native post id when a post was published.

exceptionCauseTyped cause code from the reliability surface when the schedule ended in an exception state.

recoveryActionTyped next action from the reliability surface for schedules still in an exception state.

recoveryActorNamed owner of the recovery, or "system" when the task is unowned.

deliverySetIdGroup identifier when the schedule belongs to a multi-target delivery set.

deliverySetMemberCountCount of schedules in the same delivery set.

Two formats

PDF for people. CSV for systems.

Both formats carry the same 17 columns and the same record count for a given date range. The PDF is the readable artifact for clients and auditors. The CSV is for machine processing and long-term storage.

Signed PDF

A legal-brief styled PDF 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 artifact is tamper-evident: any edit to a field, a timestamp, or a signature value breaks the signature at verification time.

CSV twin

A flat CSV with the same 17 columns in a stable order, packaged alongside a JSON manifest that names the export id, workspace id, date range, generated timestamp, and record count. The CSV is deterministic: the same inputs produce the same bytes.

How it is signed

HMAC-SHA256 over a tagged canonical payload.

The signature lives on the PDF verification page. The canonical payload printed there includes the signed manifest fields. Nothing secret is embedded in the artifact. The key id is a deterministic fingerprint of the signing secret; when the secret rotates, the key id rotates.

AlgorithmHMAC-SHA256 (one algorithm, no runtime choice).
Canonical payloadA tagged envelope joining the schema version, the signed timestamp, the canonicalized manifest JSON, and the SHA-256 digest of the CSV record bytes. The exact text is printed on the verification page.
Key identityA non-sensitive fingerprint derived from the signing secret. The secret itself is never written into the artifact.
Secret distributionThe workspace shares the signing secret with any external verifier out of band. The PDF alone is not enough to produce a forgery.
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. 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. Line breaks and byte ordering are preserved.
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 the artifact was produced by the party holding the secret.

Reviewer identity

Internal approvals are authenticated. External approvals are self-declared.

The record tags every approver. There is no ambiguity about how a given approval was captured.

Internal

An approver from inside the workspace. The identity is tied to a workspace user account at the moment of approval. The record stores that identity, the timestamp, and the approved version fingerprint.

External (self-declared)

An approver who used a review link. Cenelira does not authenticate external reviewers. The name and email the reviewer typed are stored on the record and clearly labeled (self-declared) on the PDF. Only internal approvals are cryptographically tied to a Cenelira account.

What the proof does not claim

Honest limits, stated on the artifact.

A proof export is a record of what happened inside Cenelira. Some claims belong to the signer, the reviewer, or the platform, and the artifact is explicit about where each line of evidence comes from.

External reviewer identity is self-declared. The reviewer is not authenticated by Cenelira and the artifact says so on the cover.
The signing secret is not embedded in the artifact. A verifier needs the shared secret to reproduce the HMAC.
The record reflects the publish pipeline and the platform response. It is not a claim about audience, delivery, or reach.
Only schedules owned by the exporting workspace are included. The record does not span other workspaces or other accounts.
Every field is produced from typed server state. No narrative is written for the buyer. 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 workflow state and platform response. It does not claim audience, delivery, or reach.

Are external reviewers authenticated?

No. External reviewer identity is self-declared. 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.