Files have hashes. Assets need identity.
Digital systems can tell, precisely, whether two files are exactly identical. The bigger question is a different one: how do you know whether two different files represent the same asset?
The same asset lives in many files, formats, systems and moments of its life. The content may still represent the same asset — but the file is no longer the same.
A contract exists as a PDF, an image and an XML.
A land registry record receives an annotation.
An invoice is reissued.
A document moves from one system to another.
Without a persistent identity for the asset, every new occurrence may be treated as a new object. The asset's history fragments across documents, databases, institutions and blockchains, with no common reference able to connect them. The result may be:
The problem is not storing documents. It is knowing which asset each document belongs to.
Two tools for two different questions. One does not replace the other.
Same content, different files, different hashes — and that is correct. If a single byte changes, the hash changes. It is excellent for proving binary integrity, but it was not built to recognize the asset behind the file.
The asset's permanent elements are organized by canonical rules and turned into a deterministic identifier. Same asset, same identity — in any format or source system.
The protocol does not depend on a prior list of every asset. It depends on the canonical rule of each asset class — the AC⚡Master Keys, which define what identifies a property, a vehicle, a receivable. The first occurrence establishes the identity; the following ones relate to it.
Recognizing the identity is the first step. The next question matters more:
How does this new occurrence relate to what is already registered?
The protocol answers with one of five codes. The answer also depends on the operation: register compares the new occurrence with the registry and may establish an identity; query reports the asset's current canonical state and never creates identity.
| Situation | Register | Query |
|---|---|---|
| Illegible document | AC⚡INL | AC⚡INL |
| Identity or occurrence not validated with certainty | AC⚡QTN | AC⚡QTN |
| Valid key, no existing identity | AC⚡UNIcreates the identity | AC⚡INLnot located |
| Same key, no documentary difference | AC⚡DUP | AC⚡UNIlocated and intact, unless an adverse state is already recorded |
| Same key, different documentary content | AC⚡PARthe protocol records what changed and under which authorization | AC⚡PARunless an adverse state is already recorded |
On parity, the protocol does not qualify the change: it records what changed and under which authorization — qualifying it is up to the institution. On query, once the identity is located, the result reflects the most critical signal already recorded for it, regardless of the occurrence queried.
AC⚡UNI on query means identity located, with no adverse state recorded. It is not an authorization to carry out a new operation on the asset.
When an asset's occurrences connect to the same canonical identity, its history comes to exist in a single place: what the asset was, what happened to it, what changed and what its current state is.
The timeline contains the events processed by the protocol. What happens outside it is not reconstructed by inference — which is why every change to the asset should go through the protocol.
“A traditional hash tells you whether two files are identical. AC⚡PROTOCOL Alternating⚡Current tells you whether they represent the same asset — and what happened to that asset over time.”
The file may change. The format may change.
The canonical identity remains.
Generates. Verifies. Preserves.