Change
A key, identity, device, authority, system or profile changes.
QVTM / How it works
Follow one trust relationship through real change.
QVTM does not ask an application to trust change blindly. It preserves evidence of continuity-relevant transitions, correlates that evidence across time and systems, and returns continuity context before the application makes its own policy decision.
Evidence
The transition emits immutable Continuity Evidence.
Package
Relevant evidence is preserved or transported in a CEP.
Correlate
Evidence is connected into a continuity path.
Evaluate
QVTM returns continuity context to the application.
Decide
Application policy authorizes, rejects or requests more proof.
The operating model
QVTM sits between a change and the decision that follows it.
Existing systems still authenticate identities, attest devices, protect keys and enforce authorization. When one of those systems changes something relevant to an established relationship, QVTM gives that transition durable protocol meaning.
The result is not a universal trust score. It is structured continuity context that a relying application can combine with its own risk, business and authorization policy.
A continuity-relevant event occurs
Key rotation, device replacement, recovery, service migration, authority succession or disconnected operation changes one part of the trusted state.
Evidence records the transition
Continuity Evidence preserves relevant facts and references without pretending the previous state never existed.
A CEP carries evidence
A Continuity Evidence Package provides a transportable boundary for evidence that needs to move between authorized systems.
History becomes a continuity path
Successive evidence can be correlated so a verifier can reason about how the present state relates to what was trusted before.
QVTM returns continuity context
Trust Evaluation exposes an observable protocol result while keeping internal evaluation mechanisms and application policy separate.
The application remains in control
The integrating system can authorize, reject, step up, retry or recover according to its own policy and domain semantics.
Worked example / device replacement
A lost device should not make its replacement a new trust origin by magic.
The application already knows the user and the old device. A recovery workflow validates a replacement. QVTM preserves the transition and lets the application evaluate whether the new state is a coherent continuation rather than an unrelated identity appearing with valid credentials.
Identity A + Device 1 + Key K1 participate in an established continuity history.
Device 1 is lost. Recovery validates Device 2 and new key material K2 under the deployment's recovery rules.
The recovery transition produces continuity evidence. The earlier evidence remains part of history rather than being rewritten.
The resulting evidence can be packaged and correlated with the existing continuity path.
Trust Evaluation returns continuity context about the resulting state.
Local policy decides whether Device 2 may proceed, requires step-up, or must be rejected.
What persists
Transient execution and durable continuity are different things.
Bounded execution
Negotiates and executes protocol operations, then closes. A session is not the long-term trust history.
Durable facts
Continuity-relevant protocol activity creates evidence that can remain useful after the session that produced it ends.
Portable boundary
Relevant evidence can be packaged for authorized exchange without collapsing the protocol into a central ledger.
Correlated history
Evidence is related across transitions so the present state can be evaluated in the context of its lineage.
Observable result
The SDK exposes continuity assessment as input to application policy—not as application authorization.
When connectivity breaks
Continuity does not require pretending the world is always online.
Deployment profiles can preserve continuity evidence through disconnected periods and synchronize it later across authorized boundaries. The important property is that the gap and its transitions remain explicit and inspectable.
When an operation fails
Failure should not manufacture a successful trust transition.
The public SDK guidance treats invalid or tampered evidence, expired context, incompatible capabilities and mandatory validation failures as trust-boundary failures. Previously valid continuity history remains distinct from the failed attempt.
Developer path
The SDK follows the same separation.
Choose a protected use case and deployment profile, define boundaries, configure the client, validate capabilities, open a bounded session, execute the operation, evaluate trust, apply local policy, preserve references and outcomes, then close the session. Recovery, synchronization, failure handling and diagnostics are explicit parts of the public workflow.
Open the SDK Reference →