Verified data has passed defined technical checks, such as signature validation, format validation, holder binding, expiry, and status checks.

Verifiable evidence goes further. It includes enough provenance, trust context, meaning, scope, and decision-time status to support a particular claim or assessment.

A defensible decision is the recorded outcome of applying an organisation’s accepted policy to that evidence in a specific context. The record should show what evidence was received, which checks were performed, which trust sources and policy version were used, what outcome was returned, and what action followed.

These are different levels of assurance. Data can be technically valid but irrelevant, out of scope, or insufficient for the requested action. Evidence can also be reliable without compelling one specific decision. A defensible decision therefore depends on both the quality of the evidence and the quality of the rule applied to it. It does not mean the decision is infallible. It means the organisation can reconstruct and justify how the decision was reached.

Cryptographic verification can establish important properties of a digital object. It can show that the content has not been altered, that it was signed using a particular key, and, where supported, that it was presented by the legitimate holder. Those checks do not determine whether the evidence is suitable for the decision.

An organisation must still establish whether the issuer is trusted for this type of claim, whether the evidence applies to the correct person, organisation, site, product, task, or jurisdiction, whether it is current, and whether it satisfies the applicable policy.

For example, an ISO certificate may be genuine and unexpired but cover a different legal entity or operational scope from the supplier participating in a tender. Cryptography protects the integrity and provenance of the statement. Governance and policy determine whether that statement is sufficient for the requested action.

A defensible business decision therefore requires technical verification, trust resolution, semantic interpretation, status checking, and policy evaluation.

No. A valid digital signature normally proves that the signed content has not changed since signing and that the signature was created using the private key corresponding to the identified public key. Additional trust mechanisms are needed to determine who controlled that key and whether the signer was authorised to make the claim.

Even then, the signature does not prove that the claim was factually correct when issued or that it remains correct now. An issuer can make a mistake, rely on incomplete information, exceed its authority, or issue a statement that later becomes outdated.

The relying organisation must therefore assess the issuer’s role, the evidence source, the scope of the assertion, its issue and expiry dates, its current status, and any supporting assurance framework. Digital signatures make assertions tamper-evident and attributable. They do not convert every signed assertion into objective truth.

Yes. A credential can be correctly signed, unaltered, unexpired, unrevoked, and presented by its legitimate holder while still being insufficient for the decision being made.

A contractor may, for example, present a genuine safety-training credential that applies to a different machine type, site, task, jurisdiction, or responsibility level. The issuer may also be trusted for general training but not recognised for the specific regulated activity.

Technical verification establishes properties of the evidence. It does not determine whether the evidence satisfies the organisation’s requirements. That requires a separate policy evaluation using the purpose of the transaction, the required assurance level, accepted issuers, applicable scope, current status, and any additional conditions.

Sphereon’s approach treats integrity verification, trust resolution, status checking, and policy evaluation as distinct steps so that the final record can show why the evidence was accepted or rejected for the requested action.

The required checks depend on the risk and purpose of the decision, but a complete evaluation normally covers several layers.

• Validate the evidence format and cryptographic integrity.
• Establish the identity and authority of the issuer.
• Verify any holder or subject binding.
• Check expiry, suspension, and revocation status.
• Confirm that the issuer is trusted for the relevant claim and context.
• Determine what the attributes mean and whether they concern the correct subject and scope.
• Assess freshness, missing evidence, and conflicting evidence.
• Apply the policy for the requested action.

The policy may include accepted issuers, assurance levels, thresholds, jurisdictions, roles, product categories, contractual conditions, or additional evidence requirements. The resulting record should capture the checks performed, the data actually used, the policy version, the outcome, the reason for that outcome, and any obligations or follow-up actions.

Not every transaction requires the same depth of checking. The controls should be proportionate to the consequence of a wrong decision.

Evidence, trust sources, and policies change over time. A certificate that is valid today may be suspended tomorrow. An issuer may lose an accreditation. A trust registry may be updated. A policy threshold may change. Looking at the current state later does not reliably show what was known or valid when the original decision was made.

A decision-time record should therefore capture a reliable timestamp, a reference or hash for the evidence, the verification and status results, the trust source used, the applicable policy identifier and version, the relevant transaction context, the outcome, and the action that followed. Where appropriate, it should also preserve a status response, checkpoint, or other historical proof that can be independently checked.

This does not require retaining every disclosed data value indefinitely. Data-minimising references, hashes, selective evidence, and controlled retention can be used. The purpose is to preserve enough context to reconstruct the basis of the decision without treating a later system state as proof of an earlier one.

A later expiry, suspension, or revocation does not automatically mean that an earlier decision was unjustified. The first question is whether the evidence was valid and sufficient under the applicable policy at the original decision time. The second question is whether continued validity was an ongoing condition.

For a one-time decision, such as accepting evidence during a completed onboarding step, a later change may have no retroactive effect. For an ongoing relationship, site access right, supplier qualification, professional authorisation, or safety permission, the change may trigger reassessment, suspension, notification, or termination.

Some revocation events may also indicate that the credential should never have been relied on, for example where it was issued fraudulently or revoked with an earlier effective date. The decision model must therefore separate historical justification from continuing eligibility.

A defensible record should show what was known at the original decision, when the later change was detected, which policy applied to that change, and what action the organisation took.

Periodic verification repeats a check at a scheduled interval, such as monthly, annually, or at contract renewal. Continuous assurance uses events, status changes, expiry windows, risk signals, or transaction triggers to determine when evidence or a decision should be evaluated again.

It can react to a credential being revoked, an issuer losing its trusted status, a mandate changing, or an operational context becoming higher risk. Continuous assurance does not necessarily mean that every source is polled constantly. It means that assurance is maintained according to the rate and consequence of change.

It is also important to distinguish credential status from the underlying real-world condition. A credential may remain technically valid even though the fact it represents has changed, unless the issuer updates or revokes it. High-risk decisions may therefore require revalidation against an authoritative source as well as credential-status monitoring.

The appropriate model depends on how quickly the relevant fact can change and how much harm an outdated decision could cause.

A useful decision record should contain enough information to identify, explain, and independently assess the decision without retaining unnecessary data. Typical elements include:

• A unique decision or trace identifier.
• A reliable timestamp.
• The requesting actor or system.
• The purpose and transaction context.
• References or hashes for the evidence.
• The verification results.
• The trust and status sources used.
• The interpreted claims or semantic definitions.
• The policy identifier, version, and relevant input values.
• The permit, deny, review, or conditional outcome.
• The reasons, obligations, or conditions attached to the outcome.
• The downstream action and any human override or exception.
• The integrity mechanism used to make later changes detectable.

For privacy-sensitive transactions, the record should avoid copying all presented personal data by default. It can retain only the attributes required for accountability, protected references to the original evidence, or a cryptographic commitment that allows later integrity verification. Retention periods and access controls should follow the purpose, legal basis, and risk of the decision.

Application logs and SIEM records are primarily designed for operations, debugging, threat detection, and incident response. They often contain technical events from many systems, use inconsistent structures, and may not preserve the evidence, policy context, and decision rationale needed to explain a business action. Their retention, access, ordering, and integrity controls may also be designed for security operations rather than evidentiary reconstruction.

A verifiable decision record is purpose-built around the decision. It links the request, evidence, trust checks, status checks, semantic interpretation, policy version, outcome, and resulting action through a stable identifier and timestamp. It should use a consistent structure and an integrity mechanism that makes unauthorised alteration detectable.

A SIEM can ingest these decision records and correlate them with broader operational events, but it does not automatically create them. The two systems are complementary. The decision record explains why an action was authorised or denied. The SIEM shows how that action fits into the wider technical and security environment.

It can be reconstructed reliably only when the required historical context has been preserved. That may include the presented evidence or a verifiable reference to it, the status information available at the time, the relevant trust-list or registry version, the semantic definitions used to interpret the claims, the policy version and input values, the decision-engine version or configuration, external data snapshots, and any human override.

There are two different goals. The first is to verify the historical record and confirm that it has not been changed. The second is to execute the old decision logic again and obtain the same result. Exact re-execution is more demanding because software versions, external dependencies, time calculations, and data sources may no longer be available.

In many cases, a complete, integrity-protected record is sufficient to reconstruct and assess the decision without rerunning the original system. Organisations should decide in advance which level of reproducibility is required for each class of decision and retain the corresponding evidence.

Not by itself. A verifiable decision record can provide strong evidence that a defined process occurred. It can show which evidence was received, which checks were performed, which policy version was evaluated, what outcome was returned, and what action followed. It can also make unauthorised changes to that record detectable.

Compliance is a broader legal and governance conclusion. The policy may have been incomplete, the control may have been poorly designed, the organisation may have selected an inappropriate trust source, or the applicable law may require additional human review, documentation, notification, or oversight.

Cryptography can help prove execution and record integrity. It cannot determine that the underlying policy was legally adequate or that every relevant obligation was satisfied. Sphereon can therefore support compliance evidence, continuous control monitoring, and auditability, while responsibility for the control framework and the final compliance assessment remains with the organisation and, where applicable, its auditors, regulators, or courts.