I've been sitting with something uncomfortable about Sign's architecture for a few days and I can't quite shake it.
The hook runs once. That's it. Input comes in, hook logic evaluates whatever conditions the schema author wired in, and one of two things happens.
The input becomes an attestation or it disappears. There's no middle state. No visible record of the attempt. No trace of what got close but didn't make it. The protocol just moves on looking spotless.
And I get why that's designed that way. Clean evidence surfaces are the whole point. You don't want half-formed rejected claims cluttering up SignScan alongside valid attestations. Makes sense technically.
What bothers me is what that design does to the people reading the output later.
When I look at a resolved attestation on Sign, I'm seeing the thing that survived. I'm not seeing the three inputs that ran before it and failed.
I'm not seeing whether the hook that passed this one was unusually permissive that day, or whether a configuration change shifted the admissibility threshold between yesterday's batch and today's. The attestation looks exactly the same regardless of all that context.
The hook is written by the schema author, not Sign. So when something gets rejected and disappears, the protocol is genuinely clean.
Sign didn't make a mistake. The schema author's hook made a decision and that decision happened somewhere the attestation layer never touches.
Which means if I'm downstream and I'm trying to understand whether this approval means what I think it means, I'm reading the output of a gate I can't see, written by a party I might not fully understand, that ran once and left no visible record of what it considered.
Then there's the extraData situation. This is the part I keep returning to. The fields that carry policy context, the program era this attestation belongs to, the specific conditions that made this claim valid under this particular schema version, those travel with the attestation technically. They're there.
But most downstream systems, TokenTable, partner integrations, eligibility filters, they check schema match and attestation validity and then move. Nobody opens extraData. It's too much work for a binary yes-no gate.
So the attestation travels. It's portable. It crosses chains, gets consumed by different systems, shows up in distributions six months later.
And it's carrying the full context of when and why it was valid inside a field that the systems acting on it never read.
I don't think this is Sign failing. I think it's the honest cost of making evidence portable at scale. You can't make every downstream system rebuild the full decision context every time it touches a record. That would break everything.
But it does mean the attestation layer is doing less work than it looks like it's doing. The real decision happened at the hook. The hook ran once invisibly.
The record that came out the other side looks authoritative and settled and complete.
And it travels that way forever whether the conditions that made it valid still apply or not. @SignOfficial $SIGN
