CodeSeal: give your source code a history you can actually inspect

I like shipping things. I also like being able to explain what I shipped six months later. Once an application contains handwritten code, generated code, reused libraries, and a few late-night fixes, that second part gets interesting pretty quickly. A Git commit helps, but the person receiving a package may not have your repository. They still need something concrete to inspect.

That is the problem behind CodeSeal, our ProgreTech application provenance registry. Quick disclosure: this is one of our products, so this is a first-party walkthrough. The useful promise is a signed record of observed source fingerprints and related history. It is not a magic badge that makes software trustworthy. If you build tools, ship client work, or maintain AI-assisted applications, here is where I would start.

First, prepare something you can share

Open the CodeSeal scanner. Its browser workflow accepts a ZIP or a supported GitHub repository. For a first try, use a small project you own and are comfortable submitting. Remove secrets, private customer material, generated dependencies, and anything you do not have permission to share. Public repository access and private connected-account access are different flows; private access depends on the configured integration and your authorization.

A scan fingerprints supported source without running your application. Source files are transient processing inputs, while durable registry information is evidence and metadata. That distinction matters: transient processing still means bytes reach a server. Do not confuse the absence of permanent source storage with a promise that source never leaves your machine. File paths and source labels also deserve a privacy check.

The source supports private-section markers, but filtering happens after upload or clone. If your goal is to prevent private bytes from leaving your device, remove them locally before submitting. After a scan, inspect which files were included, which were excluded, and whether the resulting scope matches the project you meant to describe. A beautifully signed record of the wrong scope is still the wrong record.

A scan and a registration are different actions

Use the scan result to inspect supported-file inventory and prior overlap. Register only when you want a durable observation and can make the required signer attestation. Keep the returned Application, Event, and Seal identifiers with the release notes. Save the signed evidence package somewhere appropriate for its contents; private evidence can contain identifying details and does not belong in public CI logs.

In the reviewed implementation, resubmitting an identical package can create a new event under the same Application ID. Changed package contents create a new Application ID, while overlap can connect related observations. Do not build your release process around the assumption that every revision will share one identifier. Record both the release version you use and the exact CodeSeal identifiers you receive.

Check the evidence, then read the interpretation

The live developer documentation explains the API. A harmless first request checks the public service status:

curl --fail --silent --show-error https://codeseal.progretech.com/api/v1/status

The browser scanner and the registry API serve different jobs. Do not invent a source-upload endpoint from the existence of /api/v1. Verification is also more than checking that a signature is mathematically valid: the implementation distinguishes signature integrity, known registry keys, exact recorded evidence, and current registry state. A revoked observation can retain a valid signature. Similar files can have legitimate shared origins. Neither observation proves independent authorship or legal ownership.

For an AI-assisted release, I would keep three neighboring records: the reviewed source commit, the test and build evidence, and the provenance evidence. The first identifies the change; the second explains the checks; the third gives recipients a signed historical observation. None should silently substitute for the others.

Try the smallest useful release

My suggestion is simple: start with one non-sensitive project, inspect its scan, and decide whether a permanent registration belongs in your workflow. Recheck the live terms, account requirements, and interface before submission; this walkthrough was reviewed on October 14, 2026. Then put the identifiers somewhere another developer can actually find them. Open CodeSeal, and give your next release a history that survives beyond a screenshot of a successful build.