How a generated asset stays tied to the data it came from
Pull-quote: “An unsigned manifest tells you what an asset says about itself. It does not prove who made it, and the difference is worth stating out loud.”
Generated asset provenance breaks at the moment of download, which is exactly when it starts to matter. A model produces a chart from a governed table, someone exports it, and the image travels into a deck, then an email, then a board pack that gets forwarded outside the company. The table is still governed. The picture of the table is now a picture, carrying numbers whose origin nobody in the thread can reconstruct.
This post is for anyone shipping AI-generated artefacts out of a governed data environment: analytics engineers, platform teams, and the people who have to answer for a figure in a slide six months later. It walks through one working implementation, the Bind, Analyze, Design, Transmute, Verify, Seal pipeline in AlchemyLake, which turns governed lakehouse data into reports, decks, infographics, video, podcast, and music at app.alchemylake.com.
It also states a limit plainly, because the limit is the most interesting part. The manifest described here is C2PA-aligned and unsigned. That makes it tamper-evident rather than tamper-proof, and the distinction changes what you are allowed to conclude from it.
What you will be able to do
- Name the six stages between a governed table and a sealed output file.
- List what a bind record captures, and say why each field is in it.
- Explain why a content hash is computed over canonical JSON with stable key order.
- Say what a deterministic numeric verifier checks that a model self-assessment cannot.
- Locate the embedded seal in a JPEG, an MP3, an MP4, and a PDF.
- State precisely what an unsigned C2PA-aligned manifest proves, and what it does not.
Why does a generated asset normally lose its source?
Because provenance is normally stored next to the asset rather than inside it, and downloading separates the two. The database row that says “this chart came from that query” stays behind on a server the recipient cannot reach, while the file goes on travelling.
Every link in the chain is reasonable on its own. The warehouse has lineage. The notebook has a commit. The dashboard has a query history. Then someone right-clicks and saves the image, and every one of those systems loses sight of the artefact at once. What arrives in the board pack is a rectangle of pixels containing three numbers and a title.
The cost is not felt immediately. It is felt at the moment somebody asks whether the figure is current, or whether it matched the definition of revenue the finance team uses, or whether it was generated before or after the restatement. Those questions have answers. The answers are just no longer attached to the thing being questioned.
What are the six stages between governed data and a sealed file?
The pipeline is Bind, Analyze, Design, Transmute, Verify, Seal, and each stage exists so that the last one has something true to record. Bind attaches specific governed sources to the job and writes down a reference to each. Analyze computes the facts from that bound data. Design settles the structure of the output. Transmute generates the asset in its target medium. Verify checks the numeric claims in the generated asset against the computed facts. Seal embeds the resulting record into the output file.
The ordering matters more than the names. Verification comes after generation and before sealing, so the seal carries a verification result rather than an intention. Binding comes first, so the facts are computed from a fixed set of sources rather than from whatever the model retrieved along the way.
What does the bind record capture?
A bind record captures seven fields per source: source_id, name, origin, row_count, columns, data_sha256, and bound_at. Together they answer which data, how much of it, in what shape, and as of when.
source_id and name identify the source inside the job. origin records where it came from. row_count and columns describe the extent and shape of what was bound, which is what lets a reader tell whether the asset was built on the full table or a filtered slice. bound_at is the timestamp, and it is the field that answers the stale-figure question without anyone having to reconstruct a timeline.
data_sha256 is the one doing the real work. It is a SHA256 hash over the canonical JSON representation of the bound columns and rows, with stable key order and no whitespace.
Why is the hash taken over canonical JSON rather than over a file?
Because the same data has to produce the same hash every time, and file serialisation does not offer that guarantee. Two exports of an identical result set can differ in column order, quoting, line endings, float formatting, or trailing newline, and every one of those differences produces a different file hash while the data is unchanged.
Canonicalising first removes the variability. Serialise the bound columns and rows to JSON with keys in a fixed order and no insignificant whitespace, then hash that string. The output is a fingerprint of the data itself rather than of one rendering of it.
That determinism is what makes the hash useful later. Given the source and the recorded hash, you can recompute and compare. A match says the underlying data is byte-identical to what the asset was built from. A mismatch says the source has moved since, which is a genuinely useful thing to learn about a figure that has been circulating for two quarters. Neither answer requires trusting the file’s own description of itself.
What does the numbers-fidelity verifier do that asking a model cannot?
The Numbers-Fidelity Verifier extracts every numeric claim from the generated asset and checks each one against the computed facts, returning a structured result: {checked, verified, score, mismatches, method}, where method is "deterministic-v1". The score then travels with the seal, so the verification result ships inside the artefact rather than living in a log.
The word deterministic is the whole argument. Asking a language model whether its own output is correct produces a second generation, correlated with the first, that is not reproducible and cannot be audited. Run it twice, get two answers. It has no access to ground truth beyond what is in its context, and it is agreeable by construction. A model-graded check is useful for tone or completeness. For arithmetic it is theatre.
A deterministic check compares extracted values against computed values with fixed rules. The same asset and the same facts return the same verdict every time, and a mismatch names the specific claim that failed rather than expressing a general reservation. checked tells you how many numeric claims were found, verified how many matched, score gives the ratio, and mismatches lists what did not agree. Reading the mismatch list is the point, because a high score with one wrong headline figure is worse than an average score with three cosmetic differences.
How is the seal embedded, format by format?
The seal is written into the output file itself, using the place each format reserves for data a decoder can ignore. That is what lets provenance survive download and forwarding, because the record travels with the bytes rather than sitting in a database the recipient cannot reach.
| Format | Where the seal lives |
|---|---|
| JPEG images and infographics | A JPEG comment marker |
| MP3 audio | An ID3 TXXX frame named ALCHEMYLAKE_PROVENANCE |
| MP4 video | An appended free box |
| PDF documents | A trailing %%ALCHEMYLAKE-PROVENANCE block |
Each of these is a documented container for bytes that a player or viewer skips. A JPEG with a comment marker renders identically. An MP3 with an extra TXXX frame plays identically. The seal is a passenger, not a modification to the content.
The manifest inside uses the context https://alchemylake.com/provenance/v1 and carries claim: "c2pa.created", a generator string, a generation id, the asset kind, the model used, a timestamp, ai_generated: true, and the list of bound sources. For sources bound from a Databricks Genie answer, the seal additionally carries the reasoning, a truncated form of the SQL, and the conversation identifiers, so the question behind the number is recoverable and not just the number.
What does C2PA-aligned and unsigned actually mean?
It means the manifest follows the shape of a C2PA content credential and carries no cryptographic signature, so it is a tamper-evident claim rather than a tamper-proof one. Read plainly: the seal tells you what the asset says about itself. It does not prove who made the asset.
C2PA, the Coalition for Content Provenance and Authenticity, is an open standard for attaching provenance metadata to media. A fully signed C2PA manifest is signed by a certificate holder, which lets standard validation tooling establish two things: that the manifest has not been altered since signing, and which entity asserted it. An unsigned manifest establishes neither. Anyone who can write to the file can rewrite the manifest, and nothing inside the file will contradict them. Standard C2PA tooling will not validate it as a signed credential, and describing it as signed would be false. Cryptographic C2PA signing is on the roadmap here, and until it ships, this is the accurate description.
What remains is still worth having, because most provenance failures are accidental rather than adversarial. A figure goes stale. A deck gets reused next quarter with last year’s chart still in it. Someone three forwards down the chain asks where a number came from and nobody can say. An unsigned manifest answers all of those, and the data_sha256 gives you an independent check against the source that does not depend on the manifest being honest. What it cannot do is defend against a motivated forger, and any vendor telling you otherwise about an unsigned manifest is describing a signature they have not implemented.
Where this goes wrong
Reading the seal as proof of authorship. The symptom is someone citing the manifest as evidence that a specific team produced an asset. The cause is treating an unsigned claim as an attestation. State the distinction in the same breath as the feature, every time, until signing ships.
Re-encoding the file. The symptom is a seal that was present on export and absent on receipt. The cause is an intermediate tool that re-saved the image or transcoded the video, discarding metadata it did not recognise. Provenance survives download and forwarding; it does not survive arbitrary third-party re-encoding or editing. Distribute the original file where the record has to hold.
Trusting the score and skipping the mismatches. The symptom is a verified asset containing one badly wrong headline number. The cause is reading score as a pass mark rather than reading mismatches as a list. A single failed claim in the title of a chart outweighs a good ratio.
Binding a source, then changing the table. The symptom is a recomputed hash that no longer matches data_sha256. That is the mechanism working as designed. The asset is not corrupt, the world moved, and the correct response is to regenerate rather than to reconcile by hand.
Assuming the recipient can read the seal. The symptom is a stakeholder who does not know the provenance exists. The cause is that a JPEG comment is invisible in a normal viewer. Say in the surrounding message that the file carries an embedded provenance record, and say how to read it.
Common questions
Is this the same thing as C2PA content credentials?
It is aligned with the C2PA manifest shape and it is not a signed C2PA credential. The manifest uses a c2pa.created claim and the field structure the standard describes, so it is legible to anyone who knows the format, but it carries no certificate-backed signature and will not validate as a signed credential in standard tooling.
Can someone remove the seal?
Yes. Anyone able to edit the file can strip or rewrite the embedded record, which is exactly why an unsigned manifest is tamper-evident rather than tamper-proof. The independent check is the content hash: recompute it against the source you were told the asset came from and see whether it matches.
What happens to the seal if the file is re-encoded?
It is usually lost. Re-encoding rebuilds the container, and metadata blocks that the encoding tool does not recognise are commonly dropped. The seal survives download, copying, and forwarding of the original file, which covers the ordinary path an asset takes. It does not survive a round trip through an editor that rewrites the file.
Does the seal let me reproduce the numbers myself?
It gets you most of the way. You get the source references, the row count, the columns, the bind timestamp, and the content hash, and for a Genie-bound source you also get a truncated form of the SQL and the conversation identifiers. Reproduction still requires access to the underlying governed data, which is the correct boundary: provenance should tell you where to look without becoming a copy of the data.
What changes when cryptographic signing ships?
Verification stops depending on trusting the file. A signed manifest lets a validator confirm both that the record has not been altered since signing and which entity asserted it, which turns a claim into an attestation. Everything described above stays in place, and the signature is added on top of it.
Next steps
Take one AI-generated artefact your organisation circulated in the last quarter and try to answer three questions from the file alone: which data it came from, when that data was read, and whether the numbers in it were ever checked against a computed source. If the file cannot answer, the provenance you thought you had was in a system, not in the artefact.
For where this sits in a wider governed workflow, AlchemyLake at launch covers what the platform produces and the rule that a model never authors a number, and installing AlchemyLake into a Databricks workspace covers the lakehouse-native path where the studio runs beside the governed data. If your interest is the audit-record side rather than the media side, governance records produced once makes the same argument about evidence that gets generated as a by-product of the work instead of assembled afterwards.
The verifier, the bind record, and the embedded seal run in production behind AlchemyLake, which is also where the unsigned-manifest limit is stated on the product surface rather than buried. More engineering writing sits in the Signals index.