Normative Text

Specification

This document defines the normative requirements of the Veriscopic Evidence Standard (VES) v1.1. The key words MUST, SHALL, SHOULD, MAY, and SHOULD NOT are to be interpreted in accordance with RFC 2119.

VES defines the requirements of a scrutiny-ready evidence record. It does not mandate a single product, vendor, or software architecture.

Normative Principle

A decision is only defensible if the full decision-state can be independently verified to have existed and held at the moment it crossed the execution boundary.

All representations derived after this moment are considered reconstruction and are subordinate to point-in-time evidence.

Status of this standard

This document defines Version 1.1 of the Veriscopic Evidence Standard (VES). It is published as a stable reference specification. Future revisions, if any, will be versioned and published separately.

1. Scope

VES applies to the capture, preservation, sealing, and later verification of evidence relating to consequential human, organisational, or system-assisted judgement.

It is intended for situations in which a decision, approval, rejection, escalation, delegation, acceptance of risk, or permission to proceed may later require review under scrutiny.

2. Definitions

  • Decision-state — the complete set of inputs, authority, constraints, system outputs, and contextual conditions that existed and were actively relied upon at the moment a consequential judgement was exercised. A decision-state is only valid if it enables independent verification of whether the decision would hold or fail under scrutiny.
  • Evidence Pack — a structured, integrity-bound record capturing the decision-state at a specific point in time, designed to enable independent verification and reconstruction under scrutiny.
  • Execution boundary — the point at which a judgement, recommendation, or assessment becomes a committed organisational act and exposure attaches.
  • Point-in-time — the moment at which the decision-state is recorded, before hindsight, reinterpretation, or post-event reconstruction intervene.
  • Verifier — a party capable of independently assessing the integrity, timing, and completeness of an Evidence Pack without reliance on internal system assertions.

3. Minimum evidence pack requirements

An Evidence Pack MUST include, at minimum:

  • a point-in-time timestamp or equivalent temporal anchor
  • a description of the judgement, act, or outcome being evidenced
  • identification of the accountable role, actor, or authority context
  • the material context or conditions under which the judgement was made
  • the relevant inputs, artefacts, or system outputs relied upon
  • an integrity mechanism enabling later verification

Evidence Packs MUST include sufficient information to determine:

  • whether the acting authority was valid at the moment of execution
  • whether governing constraints and controls were active and effective
  • whether the decision-state was complete and materially sufficient

Omission of material elements that prevent independent reconstruction SHALL constitute non-conformance.

3.1 Held Conditions

Evidence Packs MUST enable verification that all governing authority, constraints, and control conditions were not only defined, but actively held at the moment of execution.

Assertions of policy, control, or enforcement without evidence of active application at the execution boundary SHALL NOT be considered sufficient.

4. Integrity and sealing

Evidence Packs MUST be protected against undetected modification. A cryptographic hash, seal, or equivalent integrity mechanism SHALL be generated at the time of capture or immediately adjacent to it.

The integrity mechanism MUST be sufficiently stable and reproducible to allow later verification of whether the evidence record has been materially altered.

5. Timestamping

Timestamps MUST be generated at, or immediately adjacent to, the point at which the relevant decision-state is captured. They SHALL NOT be retroactively rewritten as if they reflected the original moment of judgement.

6. Verification

An Evidence Pack MUST be independently verifiable. Verification SHALL make it possible to assess:

  • whether the evidence record existed at the claimed time
  • whether it has remained materially unaltered
  • whether the decision-state was complete and sufficient
  • whether authority, constraints, and governing conditions can be verified as having held at execution

Verification SHALL NOT rely solely on internal system assertions or reconstructed records.

7. Implementation neutrality

VES is implementation-neutral. Conformance to the standard MAY be achieved through different software systems, operating models, storage approaches, or delivery architectures, provided the normative requirements of this specification are met.

8. Version pinning

Where evidence is created, cited, assessed, or challenged over time, references to VES SHOULD specify the applicable version of the standard.

9. Defensibility failure

A defensibility failure occurs when a decision cannot be supported by independently verifiable evidence of its decision-state at the execution boundary.

In such cases, evidence collapses into reconstruction, interpretation, or assertion, and the decision is exposed under scrutiny.

Defensibility failure SHALL be considered non-conformance with this standard.

10. Reconstruction limitation

Evidence derived solely from logs, telemetry, documentation, or system traces after the execution boundary SHALL NOT be considered sufficient to establish decision-state.

Where decision-state cannot be demonstrated from point-in-time evidence, reconstruction SHALL be treated as incomplete and non-authoritative.

Reference: RFC 2119 — Key words for use in RFCs to Indicate Requirement Levels.