How It Works
A linear technical reference for the Universal Manifest handshake: the receiver mechanic, the evaluation pipeline, the four pillars, the receipt, and the receiver-behavior promise. For scenario walkthroughs, see the Use Cases page.
The handshake mechanic
A receiver runs the same pipeline, in this order, every time.
A manifest arrives. Its envelope is opened. The signature is checked first; nothing else proceeds until that resolves. The receiver then evaluates which parts of the manifest it understands, which it doesn't, and which it sees but cannot read. It checks consent and revocation against its own policy: freshness, scope, expiry. Finally, it composes a result and writes a structured receipt naming exactly what it did. Both sides can run this loop in parallel. Asymmetric outcomes are normal: the same handshake can be accepted in one direction and refused in the other. That's not a bug; it's the system being honest.
the receiver pipeline, end to end
Manifest arrives
Envelope, structure, identifiers visible.
Structure + signature checked
Forged manifests stop here.
Profiles + projection evaluated
Supported, unsupported, opaque.
Consent + revocation checked
Freshness, scope, expiry.
Result composed
Accepted, warnings, partial acceptance, or rejection.
Receipt written
Checked, skipped, accepted, refused, unsupported, or opaque.
How the four pillars appear in every exchange.
The walkthroughs show the same four mechanics at work in every scenario. They are not a separate framework. They are what happened in the pipeline.
01
Projection
Only the subset relevant to the receiver's purpose travels.
In each walkthrough, the receiver got only the subset relevant to that interaction. The bouncer got age proof; the hospital got allergies and medications; the game platform got your loadout and friends list. The rest of the manifest was never transmitted.
Projection is not post-hoc filtering. The fields the receiver did not ask for were never sent.
A projection is produced before release. Data that does not belong in the context never crosses the boundary.
03
Opacity
Unreadable is not the same as absent.
In the portaling walkthrough, the new platform encountered encrypted records it could not read. It did not pretend they were absent. It recorded them as present and opaque.
A receipt that claims "I checked everything" while unable to read half the manifest would be dishonest. Opacity keeps the receipt accurate.
receiver view
04
Authenticity
Claims are checked before they can drive behavior.
In the agent walkthrough, both sides verified signatures, checked revocation status, confirmed freshness. If a credential was missing, expired, or revoked, the transaction would not proceed, and the receipt would say why.
No silent acceptance of unverified claims.
The receiver-behavior promise
Every handshake leaves a receipt. The system has to be honest about its work.
"What was checked, what wasn't, what was accepted, what was refused, what was treated as opaque. The system has to be honest about its work, and you can verify it was."
The receipt is not a thank-you page. It is a machine-readable account of receiver behavior: the checks that ran, the checks that did not run, and the policy result the receiver is willing to stand behind.
Export the referenceReference boundary
The promise is receiver behavior, not universal acceptance.
Universal Manifest does not require every receiver to understand every field, support every profile, or accept every claim. It requires receivers to evaluate honestly and record honestly. Unsupported fields can be unsupported. Encrypted facets can remain opaque. Denied consent can stop an exchange. The contract is that the receiver cannot silently pretend otherwise.
See scenario walkthroughs