Evaluation ≠ authorization
Trust Evaluation informs policy. The relying application still decides whether to authorize, deny, retry, recover or escalate.
QVTM / Security
Security starts with an explicit boundary.
QVTM is designed to make continuity-relevant change inspectable and evaluable. It does not turn continuity evidence into universal authorization, replace the controls around an application, or claim that one protocol makes an entire deployment secure.
Security model
Preserve history. Validate transitions. Fail closed at trust boundaries.
The public protocol and SDK contracts separate evidence, transport, evaluation and application decision. That separation matters: a valid credential or successful operation is not automatically proof that every surrounding relationship remained continuous.
QVTM gives verifiers continuity context while keeping domain policy, business authorization and deployment-specific controls where they belong.
History is not rewritten
Recovery and later transitions extend continuity history; they do not make earlier states disappear to manufacture a cleaner present.
Invalid input fails closed
Malformed or tampered continuity material and mandatory validation failures are rejection conditions rather than opportunities to advance trust state.
Retries are not new events
The public SDK contract requires idempotent handling so repeated logical requests do not create duplicate Continuity Evidence.
Cryptography can evolve
Protocol semantics are separated from one algorithm generation; concrete algorithms and capabilities remain constrained by conformance and deployment profiles.
Existing controls stay in place
IAM, PKI, attestation, KMS/HSM, network controls, provenance systems and domain authorization remain complementary controls.
Threat / response map
What the protocol boundary is trying to prevent.
ConditionQVTM boundaryWhy it matters
Tampered or invalid CEP/evidence
Verify before accepting it as continuity input; reject invalid material.
A transportable package must not become an independent source of truth merely because it is present.
Duplicate / replayed logical operation
Use request identity and replay/idempotency semantics so a retry does not manufacture another accepted transition.
Continuity history must describe events, not network retry behavior.
Expired or incompatible context
Fail closed when mandatory freshness, capability or validation requirements are not met.
Compatibility failure should not silently become trust acceptance.
Recovery after loss or compromise
Extend existing history with explicit recovery evidence rather than silently replacing the previous lineage.
Restoring operation and proving continuity are related but distinct concerns.
Cryptographic transition
Represent key/profile changes as continuity-relevant transitions under explicit deployment/conformance rules.
Moving to newer cryptography should not erase the lineage connecting old and new trust states.
Recovery boundary
Recovery restores capability by extending continuity—not by rewriting it.
A successful recovery can create a new or restored operational context and new recovery evidence. The prior history remains part of what later evaluation can inspect.
BeforeEstablished continuity
→DisruptionLoss / compromise / unavailable state
→RecoveryValidated transition + new evidence
→AfterContinuity can be evaluated again
Claims we deliberately do not make
Security credibility also depends on saying what QVTM is not.
QVTM does not decide your business permissions or replace local policy.
Those systems continue to establish identity, access and resource policy.
Continuity evidence and synchronization do not require a universal consensus network.
PQC support and migration semantics do not make every surrounding implementation layer post-quantum secure.
Attestation, endpoint security and custody controls remain separate inputs and responsibilities.
Protocol conformance and evidence do not substitute for external security assessment or regulatory certification.
Public security material
Inspect the contracts, not just the claims.
The Protocol Specification, Formal Foundations, Cryptographic Conformance Note and SDK Reference document the public semantics, boundaries and integration contract behind these statements.
Read the public specifications →