Binding Continuity

When does a software-identity binding remain the same?

Software changes. Keys rotate. Builds are replaced. Configurations evolve. Execution moves between environments. Authority expands, narrows, expires, or is renewed. Evidence is refreshed.

Yet systems often need to decide whether the software-identity binding before and after such a change should still be treated as the same binding.

That question is binding continuity.

Identity can persist while representation changes

An identity names an actor. A binding establishes what that actor currently is for a defined operational purpose.

Earlier state                 Later state
Identity: service-7821        Identity: service-7821
Key: K1                       Key: K2
Build: B4                     Build: B5
Runtime: R1                   Runtime: R2
Authority: A1                 Authority: A1

The actor may still be recognized by the same identity. But several facts behind that identity have changed.

The question is not merely What changed? It is: Did the binding survive the change?

A SIBUID identifies a policy-delimited binding

A SIBUID does not identify an abstract relationship with unlimited persistence.

A SIBUID identifies a binding as delimited by a continuity policy.

The continuity policy defines which transitions remain inside that binding and which establish a different binding.

• If policy treats the transition as continuity-preserving, the existing SIBUID may persist.
• If policy treats the transition as continuity-breaking, a new SIBUID may be assigned.

SIBUID names the binding. Continuity policy defines its boundary.

Change and replacement are not the same thing

Continuity is a decision

Previous binding state
        │
        │ transition
        ▼
Current binding state
        │
        ├── CONTINUITY PRESERVED
        ├── CONTINUITY UNCERTAIN
        └── CONTINUITY BROKEN

A decision can depend on which property changed, who authorized it, whether the change was expected, whether cryptographic continuity exists, whether evidence remains valid, whether authority stayed within permitted bounds, and whether the actor itself remains meaningfully the same.

There is no universal continuity rule implied by the term SIBUID.

The SIBUID question

Should the existing SIBUID persist, or should a new SIBUID be assigned?

This reference does not answer that question universally. It names it.

Continuity is not immutability

A persistent binding identifier does not mean the binding never changes. Persistence and immutability are different.

An immutable snapshot says: this exact recorded state will not change.

A continuity relationship says: these different states are treated as successive states of the same binding.

SIBUID: binding-42
│
├── Snapshot A
├── Snapshot B
├── Snapshot C
└── Snapshot D

Each snapshot may have a different digest. The SIBUID may remain the same if policy treats the transitions as continuous.

A binding may have generations

A useful conceptual model treats each accepted state as a generation.

Binding
│
├── Generation 1
├── Generation 2
├── Generation 3
└── Generation 4

A generation is not required by the SIBUID definition. It is a convenient way to reason about change.

Drift

Real systems often encounter uncertainty rather than clean binary transitions.

Drift describes a condition in which a binding has changed but available evidence is insufficient to establish either accepted continuity or confirmed replacement.

Known state
   ↓
unexpected change
   ↓
insufficient evidence
   ↓
DRIFT

The continuity boundary

Every continuity policy implicitly defines a boundary.

Inside the boundary, changes are accepted as evolution of the same binding. Across the boundary, the previous binding identity no longer applies.

The boundary depends on what the binding is intended to mean. A service may tolerate runtime migration. A hardware-bound system may not. A development workload may tolerate frequent software updates. A safety-critical system may treat the same update as identity-significant.

A device, container, service, scheduled function, workload, or AI agent can use the same conceptual vocabulary while applying different continuity rules.

What happens when continuity is left implicit?

When a system changes binding state without defining continuity rules, two parties can observe the same transition and disagree about whether they are still referring to the same operational relationship.

A mature continuity policy should be able to answer:

1. Which properties are continuity-relevant?
2. Which transitions may change them?
3. Who may authorize those transitions?
4. Which evidence is required?
5. When is continuity preserved?
6. When is continuity broken?
7. When is the result uncertain?
8. When must a new SIBUID be assigned?

The answers may differ. The questions endure.

Continuity and history

A binding history can organize accepted states around a stable reference point. The identifier alone does not provide that history. It provides the stable point around which the history can be organized.