1. VES Decision Envelope
A VES Decision Envelope MUST identify one consequential organisational commitment and bind the evidence relevant to understanding it at a declared point in time.
Decision identity
The decision type, opaque subject reference, outcome and execution time.
Decision context
The material facts and source evidence considered in relation to the decision, with their declared relationship—for example, available, relied upon, excluded or superseded.
Governing conditions
The policy, wording, rules, requirements or instructions applicable at the time.
Business authority
The role, delegated authority, limits and approval state at execution.
System contribution
Rules, models, workflows or external systems that materially influenced the decision.
Human judgement
Review, intervention, approval, override or rationale where applicable.
Commitment
The organisational outcome, including financial, contractual or customer consequence.
Evidence integrity
References, hashes, signatures and declared provenance for Evidence Objects, where available.
Verification
The profile used, checks performed, result status and visible limitations.
Required top-level fields
| Field | Type | Semantics |
|---|---|---|
| ves_version | string | Pinned standard version. |
| decision_id | UUID | Opaque decision identifier. |
| decision_type | string | Namespaced decision classification. |
| decision_timestamp | date-time | Organisational commitment time. |
| decision_subject | object | Opaque reference; no personal data required. |
| outcome | object | Declared outcome and commitment. |
| profile | string | Profile against which the package is assessed. |
| evidence | array | Wrapped native Evidence Objects. |
| verification | object | Declared checks, status and limitations. |
| extensions | object | Namespaced implementation extensions. |
2. External Evidence Object
Each input is wrapped with sufficient information to understand what it is, where it came from, when it applies, how integrity may be checked, and how it relates to the decision. The wrapper does not replace or reinterpret the native evidence format.
Runtime-control receipts, model-gateway logs, signed action records and policy-enforcement records may form part of a VES Decision Envelope. They do not, by themselves, establish the full business decision-state unless linked to applicable evidence, business authority, human judgement and organisational commitment.
Governance evidence may be represented as an Evidence Object, but it does not by itself establish the basis of a specific consequential decision.
{
"evidence_id": "018f0d4e-7b3a-7c11-a75f-3d13ec33a001",
"type": "runtime_receipt",
"source": { "system": "example-workflow", "standard": "external.runtime.receipt", "standard_version": "1.1", "issuer": "issuer.example" },
"captured_at": "2026-09-18T10:15:30Z",
"applicability": { "from": "2026-09-18T00:00:00Z", "to": null },
"integrity": { "algorithm": "sha-256", "digest": "sha256:REDACTED" },
"decision_relation": "produced_by",
"limitations": ["Does not establish business authority"]
}3. Decision-evidence semantics
A conforming profile MUST preserve or explicitly qualify the decision relationships needed for later review. The public exchange surface makes the following semantics visible without prescribing proprietary capture or scoring methods.
| Semantic | Public representation |
|---|---|
| Business authority at execution | Role, delegated authority, limits and approval state applicable when the organisation committed. |
| Evidence relationship | Available, relied upon, excluded or superseded, alongside other declared decision relations. |
| Governing conditions | Policy, wording, rules, requirements or instructions in force at the decision time. |
| Human judgement | Review, override, approval, intervention or rationale where applicable. |
| System contribution | Rules, models, workflows and external systems that materially influenced the decision. |
| Organisational commitment | The outcome and any financial, contractual or customer consequence. |
| Reconstruction gap | Known difference between the decision-state available at execution and what the submitted package can later establish. |
| Replay path | References and retained artefacts needed to review the declared decision-state later. |
| Verification limitations | Facts not established, evidence not retrieved and boundaries of the assessment. |
| VES version applied | The pinned VES version and profile used to structure and assess the package. |
4. Verification dimensions
Source conformance
Conformance to the object’s declared source format or profile.
Integrity and provenance
Whether the object is intact and attributable to its declared issuer or source.
Temporal applicability
Whether validity and point-in-time applicability are declared for the decision.
Business authority
Whether the package evidences the authority asserted at execution.
Structural completeness
Whether required evidence classes are present for the selected VES profile.
Replayability
Whether sufficient references and artefacts are retained for later review.
5. Result statuses
Statuses assess a submitted package against its stated profile. They are not ratings of an insurer, product, person, vendor or decision outcome.
Verified
All required checks for the stated profile passed.
Qualified
The package is useful and intact, but declared limitations or non-required gaps apply.
Incomplete
One or more required evidence classes are absent.
Indeterminate
Verification could not establish a required fact.
Failed
An integrity or conformance check failed.
6. Versioning and extensions
Implementations MUST pin the applicable VES version. Extension keys MUST use a controlled namespace such as org.example.claims. Extensions MUST NOT alter the meaning of normative VES fields or be required to interpret the base envelope.