An exported file can keep its pixels and lose its proof. For a newsroom or an agent pipeline, the useful check is not only whether the source carried a C2PA credential. It is whether the file that reaches the next system can still be tied to that source. ProofSnap and Capture register the original with a NID. Verify Engine can validate C2PA and search for exact or similar registered assets where the format is supported. Similarity helps locate a related asset. It is not a verdict that the received file is unchanged. That distinction matters after resize, compression, screenshot, or repost. The proof object has to travel with the file or be checked again. Labels help. Receipts finish the job. Check the received copy in Verify Engine: docs.numbersprotocol.io/appl…

A handoff can lose the story even when the file stays the same. One person knows where it came from, what permission covered it, what was done to it, and who approved the result. Then the asset moves to someone else, and all they get is the file. That is where accountability starts disappearing. A good handoff should carry enough context for the next person to understand the source, the permission, what happened to it, and what was approved. Nobody should have to search old chats just to figure out why an asset was used.

Tammy's Weekly Summary. Permission is not proof of use. September traced licensed source to action, output, and delivery, with Numbers records keeping each handoff inspectable. Read the letter: docs.numbersprotocol.io/intr…

A new AI-generated asset should not arrive with no memory of what created it. If a licensed image went into the workflow, the output should still carry a path back to that source. Not just the license. The actual chain: source asset → permitted use → action performed → output asset That gives the next reviewer something concrete to inspect. Which source was used? What permission covered it? What was done to it? Where did the result go? Which new asset came out? Numbers’ Commit API can record those actions, license details, and custom metadata against the source asset. If the output is registered too, its NID gives the result its own persistent reference, while Asset Profile keeps both histories inspectable. The useful record is not just “this source was licensed.” It is how that source became this output. Build the record: docs.numbersprotocol.io/deve…

A licensed image enters an AI workflow, gets transformed, and comes out as something new. Somewhere along the way, the clean connection between “we were allowed to use this” and “this is what we made with it” can disappear. That is the part provenance should preserve. Not just the license. The actual path: which asset went in, what happened to it, where the result went, and what came out the other side. Because six months later, nobody wants to dig through Slack, API logs, and old folders just to answer a basic question: How did this output get here? The license gives the source permission to enter. Provenance keeps it from vanishing from the story.

Permission is not proof of use. A license can tell you what someone was allowed to do with an image. It does not necessarily tell you whether the image was actually used, where it went, or what came out of that use. That matters when licensed content enters an AI or publishing workflow. A useful record should connect the source asset to the action that followed: which license applied, what was done with the asset, where it was used, whether a new output was created, and who reviewed the result. In Numbers, that history can stay attached to the asset itself. NID gives the source a persistent reference. The Commit API can append actions, license information, and custom metadata such as usedBy. If the workflow creates a new registered asset, its output NID can be linked back into the same history. Asset Profile then makes that trail inspectable later. The distinction is simple: A license records what is permitted. A provenance record shows what actually happened. That becomes increasingly important when one asset can move through multiple AI tools, publishing systems, and downstream users. Record the use: docs.numbersprotocol.io/deve…

Numbers Protocol is partnering with @AstarterDefiHub. Astarter is building infrastructure for the autonomous AI economy. ABox nodes provide compute and execution environments for AI agents, while its on-chain layer supports agent operations and settlement across trading, prediction, and other economic activity. Numbers provides provenance infrastructure for digital assets and agent activity, making origin, usage, and changes easier to inspect. As the collaboration develops, we will share concrete updates on how verifiable records can support AI agents moving between compute, execution, and content workflows.

A screenshot of the source record is not a receipt for the published copy. A useful publication packet keeps the delivered file, the check that was run, and a plain-language result sentence together. If the copy changed, record the change. If the result is only similar, do not rewrite it as exact proof.

The file you approved is not always the file your audience received. Keep the delivered copy beside the source record. Check identity, inspect the verification result, and write down the exact boundary between what the record proves and what it does not. That small habit makes publication evidence easier to reuse.

An asset can keep its pixels and lose its proof. This week, Numbers focused on checking the source, export, and received copy separately. Read the Weekly Summary: docs.numbersprotocol.io/intr… Keep the delivered file, the check, and the result together.

The file that leaves an editor is not the file that entered the workflow. A builder shipping an AI report, an editor exporting a cut, or a newsroom receiving a rendition needs three objects: the source asset, the changed copy, and the copy that arrived. Each one needs its own check. NID makes the source identity persistent. Asset Profile keeps the provenance record readable. Verify Engine can return exact or similar registered-asset evidence where support exists. Similar search can help recover a relationship after a transformation. It cannot silently turn a related file into an exact match. The useful handoff pattern is simple: check the source, check the export, record the result, and show the exception when the evidence does not survive. A receipt is more useful than a promise. Read the Verify Engine asset-search workflow: docs.numbersprotocol.io/deve…

A file can leave the creator with a clear record behind it and arrive somewhere else with part of that context missing. It may have been resized, compressed, downloaded, edited, or reposted along the way. To the eye, it can look exactly the same. But the information that helped explain where it came from may no longer be there. That is why the receiving side should check the copy it actually gets, not assume everything attached to the original came with it. Keep three things together: the file that was received, the result of the check on that file, and a simple explanation of what is still known or uncertain. Proof is most useful when it still makes sense after the file changes hands. The goal is not just to preserve the evidence. It is to preserve enough context for the next person to understand it.

Numbers Protocol is partnering with BASIS. At Numbers, we build infrastructure that makes digital content's origin and history verifiable. Our focus is on giving people evidence they can inspect and trust. BASIS develops crypto arbitrage and staking infrastructure, supported by execution research, systems modeling, and risk design from Base58 Labs. As the collaboration develops, we'll share what it means for Numbers and our community, with concrete updates on the work ahead.

A similarity score means nothing to the person who has to sign off. Reviewers do not need the distance. They need the sentence. Exact match. Same image, modified. No match. Not supported by this check. Same underlying data. One version can be pasted into an email and defended. The other needs the engineer who ran it. If your verification output requires an interpreter, it is not finished.

The person who needs the answer is rarely the person who can create it. The receiver wants to know what they were sent. The sender is the only one who can make that knowable, and they have to do it before the file leaves. So verification bought by the receiving side alone does very little. The registry has to be filled upstream. Provenance is not a product one party installs. It is an agreement between two.

We registered an image, then shrank and recompressed it until the metadata was gone. The way an ordinary platform upload does it. Then we submitted only the thumbnail. Byte-for-byte matching returned nothing. Correct answer. It was a different file. Visual matching returned the original. That is the useful half. When the mark does not survive the trip, the file can still be recognised, provided someone registered the source before it left. One test is not a guarantee. We have not mapped where recovery stops.

A similarity score is not a verdict. Verify Engine, edit receipts, and KaratDAO all point to one need: connect changed files to inspectable sources. Read: docs.numbersprotocol.io/intr… What survives your next edit?

An edit is not a footnote. It is a new file with a new proof question. A newsroom receives a crop, then exports a smaller JPEG. The reviewer should not ask only, “Is this authentic?” Keep an edit receipt: source Numbers ID delivered file ID operation: crop, resize, compression, or overlay receiver and timestamp verification result: exact, modified, similar, or no supported match Verify Engine can compare the delivered file against Numbers-registered assets. The result is a signal, not a legal verdict. The receipt is what lets a reviewer say what changed without pretending a similarity score proves identical files. Register before the handoff. Compare the delivered file. Write the verdict in words. verify.numbersprotocol.io/

Upload an image to Verify Engine and it searches Numbers-registered assets for an exact result or visually similar candidates. For similar results, the API returns a distance score. A score of 0.08 does not mean “8% different” or “92% confidence.” It is the model’s measure of how close two images look. Lower means closer. The API lets developers set a threshold to filter similar results. Numbers’ documentation uses 0.12 as a general guide: below it, two images are considered very similar and are likely to be the same asset with a small modification. So 0.08 falls below that similarity guide. It is strong evidence of a relationship, but it does not prove that the files are identical. A reviewer needs that result in plain language: exact registered match, likely the same image modified, or no useful match. Verify Engine finds the relationship. Numbers ID gives the registered source a persistent reference. Asset Profile makes its provenance history inspectable. Similarity can reveal a relationship. Provenance helps explain what that relationship means. Try Verify Engine: verify.numbersprotocol.io/

We’re partnering with @KaratDAO 🤝 KaratAI is building around decentralized identity and user-controlled data, connecting Web2 and Web3 through privacy-focused infrastructure. Numbers Protocol brings the content proof layer to that picture. Numbers ID gives each registered asset a persistent reference. Asset Profile keeps its provenance history inspectable. Capture SDK lets builders add content registration to apps and agent workflows. Verify Engine checks supported C2PA records and searches for exact or similar registered assets. Together, we want to explore how people and agents can carry identity, data, and verifiable content history across platforms without giving up control. More to come.