@SignOfficial #SignDigitalSovereignInfra $SIGN

What kept bothering me this time was not Sign's issuer authority. Not revocation lag either. Worse, actually. More boring. Which usually means worse.

Schema drift.

Not the lazy "versioning is hard" line people throw around when they want partial credit for noticing systems have versions. I mean the Sign version of it. One schema stays live long enough that downstream systems start treating it like stable policy. Then the institution changes what the approval is supposed to mean. New review criteria. New fields. New threshold. Maybe a second approver. Maybe a sanctions or residency check that used to live offchain and get waved through and now suddenly matters because someone senior got nervous after phase one. Fine. They update the schema. Or deploy a new one because the old one is already too live to touch without breaking things.

So now both truths are in the system.

Old schema still resolves. New schema starts issuing. SignScan shows both. Great.

Now what is the downstream system supposed to do with that. Treat them as equivalent. Sequential. Superseded. Based on which boundary, exactly.

And yes, half the time they kept the same label. Of course they did. Renaming things would force them to admit the workflow changed more than they wanted.

Sign, doing its job, makes both versions look clean enough to trust.

I keep picturing a pretty normal institutional mess. Grant program, public benefits pilot, university certification flow, token unlock with compliance gating, pick your flavor. Phase one launches fast because it always launches fast. Schema carries a narrow enough meaning then. Eligible, approved, certified, whatever. A few fields. Enough to issue attestations and get the workflow moving. Then somebody notices the first version was too forgiving, or too local, or too dependent on one team’s interpretation. So phase two tightens. New schema. New rules. Same conceptual label sometimes, which is where things start getting stupid.

The old approval meant reviewed under the initial process. The new approval means reviewed under the revised process plus additional controls. On paper that should be enough. In a live workflow, not really. Both can still look like the same kind of claim if you are in a hurry and reading for operational effect instead of administrative history.

Which, to be fair, is exactly how most downstream systems read.

TokenTable wants a yes or no. Claimable or not. It does not care that the institution changed its mind in quarter two. A partner platform checking access does not want to reconstruct which review era a credential came from. Reporting does not want narrative. It wants rows.

That is the trap.

Once multiple schema generations are live, the pressure moves from attestation issuance to interpretation hygiene. Sounds boring. Still wrong. Not boring once money or access is attached.

What exactly is a downstream filter supposed to do with two sets of attestations that are both valid, both queryable, both signed, both coming from legitimate issuers, but not actually grounded in the same rulebook anymore. Treat them as equivalent. Sequential. Ignore the old one. Keep both. Great. Based on what.

Sign protocol gives the institution a clean evidence surface. Useful. Also exactly why this gets messy later. Evidence survives policy edits much better than institutions survive their own policy edits. The record keeps its shape. The workflow that gave it meaning does not.

Schema IDs are supposed to solve this.

They do not. Not in practice.

Yes, technically, different schema means different meaning. Fine. Great.

That only helps if the downstream system actually behaves like schema versioning matters. A lot of them do not. Or not enough. Most failures here are not because the identifier was hidden. They happen because somebody decided the identifier mattered less than keeping the flow simple.

Simple is where this starts going bad.

Maybe “drift” sounds too soft. No, it is drift. Just dressed up as versioning.

And once that starts, you get weird half-failures. Not exploits. Not obvious fraud. More humiliating than that. Claim sets generated off attestations issued under criteria that no one at the institution would still defend if asked live. Internal dashboards showing one coherent approval population when it is really two or three administrative populations stacked on top of each other. Audit trails that are technically excellent and still not enough to answer the annoying question, which is not did this attestation verify, but under which version of the workflow was this person cleared, and is the downstream system pretending those versions are equivalent because it was easier.

That last part is usually the answer, by the way.

Easier.

Sign infrastructure is not confused. The people around it are. Or they decide the distinction is somebody else’s problem until review starts yelling. The records are there. Schema references are there. Issuer trails are there. SignScan is showing you what actually happened. The confusion enters when institutions want continuity more than they want clean separation. So they keep the labels similar. Or they let internal tooling treat old and new schemas as basically the same program. Or they promise themselves they will phase out the old attestations soon and then distribution logic keeps reading both because nobody wanted to break production over what looked like a documentation problem.

Documentation problem. Right.

Then treasury or compliance gets dragged in later and suddenly it is not documentation anymore. It is a claims population produced under mixed eligibility logic.

Which is a very polite way of saying the system kept carrying old judgment forward because nobody wanted to slow anything down.

And it gets uglier in very normal ways. Someone exports an approval set for distribution using claim presence plus one loose program tag because that was good enough in phase one. The migration memo said old-schema attestations were valid only for approvals issued before a cutoff date, but the cutoff never made it into the filter logic. So the batch goes out with a mixed population. Old approvals, new approvals, same label, same dashboard bucket, same report upstairs. Later someone notices a wallet cleared under criteria the institution already tightened six weeks ago. The attestation still verifies. The schema reference is real. The problem is the relying layer flattened time because adding era-sensitivity would have made the rollout slower.

And Sign, because it is doing its actual job, keeps making those judgments portable enough for the next system to act on them. The better it works as evidence infrastructure, the less friction there is to accidentally carry old policy forward.

More than people want to admit.

I keep thinking about migration windows too. Those are bad. Really bad. Institution says old schema remains valid for previously approved subjects, new schema applies only going forward. Sounds reasonable. Often is reasonable. Until some relying system forgets that “previously approved” is a temporal condition tied to issuance context and not some permanent property of the claim type. Then an attestation minted under the old rules keeps doing future work in places where the institution thought the new rules had already taken over.

Same record. Different era. Still live.

Still live for what, exactly. Access. Distribution. Reporting. Somebody needed to decide that earlier.

And because everything verifies, people waste time arguing about authenticity when the actual wound is continuity. The old attestation is authentic. That was never the interesting part. The interesting part is whether downstream systems have any discipline about historical meaning once the institution has moved on. Some do. Plenty do not. They just keep reading.

Schema drift gets worse because it can look like maturity. Look, the program evolved. Look, the schema got refined. Look, the protocol captured both states. True. All true. Still not enough if the relying layer acts like versioned evidence is interchangeable evidence.

A wallet gets included in a distribution set because an old attestation still passed the filters. An access right stays open because the relying system checked for claim presence, not claim generation. A report goes upstairs showing one approval population without admitting half of it came from a looser schema the institution already stopped standing behind months ago. Then someone says the records were valid.

Fine. Great. That was the easy part.

The hard part was whether validity from one schema era was ever supposed to authorize action in another.

And if the answer is “well, it depends,” then that dependence needed to be somewhere the workflow could actually enforce before the next system started reading from Sign like history and policy were the same thing. Fine. The old attestation was valid. The institution had already moved on. Useful distinction to discover after the next system already treated both as the same program.