When an AI-assisted asset is ready to leave one team and move to another, the source record is only part of the story. The next reviewer may need to understand which source was used, what was edited, which copy was delivered, what was eventually published, and whether that asset was reused later. Asset Profile keeps the registered history around the asset inspectable. Verify Engine lets someone check the file in front of them and repeat the verification independently. Together, they make the handoff easier to understand: what is this file, what is it connected to, and what can we actually verify about it? That last question matters. A similar match can help recover a relationship to a known source, but it should not be presented as proof that two files are identical. Good provenance does not hide that uncertainty. It makes it visible before the asset moves again. A handoff record has done its job when the next reviewer can understand the evidence without asking the person who created it to reconstruct the whole workflow. Inspect a file: verify.numbersprotocol.io/

Having the file is not the same as having permission to reuse it. An image can pass from creator to agency to publisher to platform and still look perfectly usable. After the first transfer, the receiver may know where it came from but not what they are allowed to do with it. Origin and permission answer different questions. The source record establishes what the asset is. The license reference and recorded action explain how this version was meant to be used. Before the asset moves again, keep its intended use, license reference, and destination connected to the record the next team will inspect. The goal is not a longer terms document. It is a handoff where the receiver can distinguish "we have the file" from "we may use the file this way."

A reuse record should survive outside the system that created it. A platform log can show that a job ran or a field changed. It cannot tell the recipient which source was licensed, which action produced this version, where it was intended to appear, or which license reference travelled with it. That is why action and permission belong with the asset record, not only in the application log. The next team should be able to inspect the source identity, the resulting version, the recorded action, the license reference, and the intended destination without rebuilding the story from chat messages. Operational logs explain what the machine did. Portable provenance explains what the recipient can verify about the asset and its reuse context. A reusable asset needs both.

Sofia's Weekly Summary. Numbers' Commit API can record an asset's license and use; Verify Engine can check the copy a reviewer actually receives. Similarity helps recover a relationship, but is not proof of identity. Read the letter: docs.numbersprotocol.io/intr…

Publishing moves an asset into someone else's workflow. The marketer sees a campaign file. The newsroom sees a visual to clear. The platform sees an upload to transform. Each recipient inherits a different decision, but the final URL carries almost none of the context behind it. It does not explain which source was approved, what changed before release, or whether reuse was permitted. That is why publication should be treated as the start of the next handoff, not the end of the current task. Keep the source connection and permitted use close enough to the asset that the next person can act without rebuilding its history from chat messages.

An agent licenses an image, adapts it for a campaign, and hands it to a publisher. The final URL can show where the asset appeared, but it cannot explain which permission travelled with it or which workflow action produced the published version. Numbers' Commit API gives builders a way to store that context with the asset record. Fields such as `action`, `licenseName`, `licenseDocument`, plus custom metadata like `usedBy` can make the reuse path readable by another system or reviewer. This does not automate the legal or editorial decision. It preserves the facts that decision depends on, so permission is less likely to disappear between tools. If the next team will reuse the asset, record the handoff before the current team closes the job. Explore the workflow: numbersprotocol.io/eu-ai-act…

Numbers Protocol is partnering with @EchobitExchange to explore how provenance can support trust in digital content shared across crypto communities. Echobit provides digital asset services to users worldwide. Numbers Protocol builds infrastructure for recording and verifying the origin and history of digital content. Our collaboration will focus on provenance and verifiable records. More details to follow.

A handoff can preserve the source and still lose the path between versions. By the time an image reaches publication, it may have been cropped by a designer, resized by a publishing system, given new context by an editor, and recompressed by a platform. To the audience, it can still look like “the same image.” For provenance, it may now be several different files. A folder full of versions proves those files existed. It does not explain how one became the next. Numbers gives each registered asset a persistent Numbers ID. A meaningful edit can be recorded as a derivative, keeping its relationship to the source visible in Asset Profile. Verify Engine can then inspect the file a reviewer actually receives and, where supported, search for an exact or similar registered asset. Similarity can help recover a relationship. It does not prove two files are identical. At closeout, preserve the source identity, the relationships between meaningful versions, the copy that was published, and the permission attached to its use. That turns ordinary editing into an inspectable lifecycle.

Close the asset loop before the file leaves your system. Once an asset moves to another person, platform, or workflow, the context around it starts to fragment. The file may survive perfectly well while the reason it was used, what happened to it, and who approved the result become much harder to recover. A complete record should connect the whole path: source → permission → action → destination → output → decision. The value is not in having every field filled at all costs. If a step is unknown, record it as unknown. If an output was never registered, say so. If a review never happened, do not let the absence quietly become an approval. That makes the record useful beyond the person who created it. Someone receiving the asset later should be able to understand what entered the workflow, what was allowed, what happened next, what came out, and which decisions were actually made. Evidence becomes reusable when it no longer depends on the memory of the original operator. The goal is not a perfect story. It is an honest, traceable one.

“Approved source” only tells you what was allowed into the workflow. It does not tell you what happened next. What was done with the asset? Where did it go? What came out of the process? Who reviewed the result? Those details belong with the source record too. The useful unit is not just the input. It is the full path from source → use → output → review.

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…