info-tech-canon/infospace/models/evidence/InfoTechCanonEvidenceModel.md

---
id: itc-evid:EvidenceModel
title: InfoTechCanon Evidence Model
short_name: ITC-EVID
type: domain-model
standard_family: InfoTechCanon
repository_context: info-tech-canon
recommended_path: models/evidence/InfoTechCanonEvidenceModel.md
status: draft
version: 0.1.0
canonical_owner: InfoTechCanonEvidenceModel
namespace: itc-evid
classification: model
imports:
  - InfoTechCanonCore
owned_concepts:
  - Evidence
  - Evidence Source
  - Adjudication Outcome
  - Evidence strength
created_at: 2026-09-05
updated_at: 2026-09-05
---

# InfoTechCanon Evidence Model

**Short Name:** `ITC-EVID` · **Status:** Draft · **Version:** 0.1.0

## 1. Purpose and boundary

This model owns the general evidence/source pair, adjudication outcomes as a
specialization of evidence, and the general evidence-strength dimension, under
accepted CUST-ADR-006 R3/R5/R7. Governance, identity, and CommerceCanon consume
these semantics. Registration makes this draft retrievable; it does not claim
consumer adoption or promote the model to a stable standard.

[Governance](../governance/InfoTechCanonGovernanceModel.md) retains Policy,
Control, Decision, Assertion, AssuranceCase, AssuranceConclusion and Audit.
Its EvidenceBasis catalog remains the established quantity-origin application,
with its existing identifiers, tiers and rules. Identity owns Assurance Level;
CommerceCanon owns Counterparty Assurance Gradient. Neither is a synonym for
general evidence strength. Core retains provenance mechanisms; Information
Space retains SourceReference/Citation for document retrieval. This model does
not redefine those concepts or originate booked financial facts.

## 2. Owned concepts

### 2.1 Evidence Source

An **Evidence Source** is an addressable information container from which an
assertion can be drawn. It MUST have a URI identifying the source; where content
can change, the evidence record MUST also identify the relevant version or
capture. A URI need not be public or grant access. A source may be a document,
an artifact, or a captured record of an event or observation. An issuer or
verification process alone is not the container: identify the resulting record.

Sources may contain multiple assertions. They may carry commentary, context,
version information and integrity metadata. Identifying a source does not
establish its authenticity, completeness, or the truth of its contents.

### 2.2 Evidence

**Evidence** is a distinct assertion drawn from one or more identified Evidence
Sources for an explicit interest or question. The source and the assertion have
separate identities. Evidence MUST state the assertion, identify its sources,
and record the interest being served. It SHOULD locate the supporting passage,
field, or fragment and record who or what captured it and when. Evidence may
carry commentary, including interpretation, uncertainty and disagreement.

The same source can yield different evidence for different interests. Capturing
an invoice's issuer, amount and due date yields three assertions; it need not
extract every statement in the document. Evidence is not guaranteed truth.
Conflicting assertions remain separately attributable rather than being erased
by choosing one source as authoritative for every purpose.

### 2.3 Adjudication Outcome

An **Adjudication Outcome** is Evidence asserting the outcome of an adjudication
or formal dispute/enforcement determination, drawn from the corresponding
judgment, award or determination record. The judgment document is the Evidence
Source; the outcome assertion is not that document. Record the deciding body,
parties or subject, determination, scope and relevant status/time as supported
by the source. Do not infer finality, enforceability or broader applicability
that the source does not establish. A filing alone does not assert a judgment.

An outcome may support a downstream commercial lifecycle decision. That decision
and its authorization remain with their owning models; evidence does not itself
grant access, settle a ledger, or execute a commitment transition.

### 2.4 Evidence strength

**Evidence strength** is the assessed degree of support an evidence assertion
provides for a stated interest in context. A strength assessment MUST identify
its assessment scheme, rationale and scope; absence of assessment is unknown,
not an implicit strongest or weakest value. A scheme may use ordered tiers or
multiple dimensions; this model imposes no universal numeric score or ordering.

Consider source authenticity and integrity, relevance to the question, method
of capture, corroboration, freshness and unresolved contradictions. These are
assessment considerations, not a closed mandatory scoring formula. An unchanged
signed source can still contain a false statement. A well-supported assertion
about one question need not be strong support for another.

EvidenceBasis describes how a quantity was obtained and its existing propagation
rules; it does not exhaust general strength. Counterparty Assurance Gradient is
a named commercial application. Its opinion/observed/committed/adjudicated tiers
are not imposed on all evidence. Identity Assurance Level and governance
AssuranceConclusion remain separately owned concepts.

## 3. Relationships and capture rules

```text
Evidence --drawn_from--> Evidence Source
Evidence Source --contains--> information supporting zero or more Evidence assertions
Adjudication Outcome --specializes--> Evidence
Evidence --assessed_for--> interest using a named strength scheme
```

Containment identifies where supporting information resides; derivation records
which assertion was drawn from it and how. A computed assertion MUST retain its
input evidence and transformation, so it can be traced to the original sources.
No extraction is presumed complete or uniquely correct. Commentary on a source
and commentary on an assertion stay distinguishable.

## 4. Worked examples

### 4.1 Invoice and embedded extraction

This is an illustrative data model, not an invoicing-format requirement or legal
claim. Let `urn:example:invoice:42:revision:1` identify a PDF source. For payment
preparation, capture separate Evidence assertions:

| Evidence ID | Assertion | Source location |
| --- | --- | --- |
| invoice-42-issuer | The invoice names Example Supplier as issuer. | Issuer field |
| invoice-42-amount | The invoice states a total of 120 EUR. | Total field |
| invoice-42-due | The invoice states a due date of 2026-10-01. | Due-date field |

Those assertions concern what the invoice states. They do not assert that money
was paid, that the supplier is authenticated, or that a booked financial fact
exists. A dispute reviewer may capture different assertions from the same PDF.

In a signed-PDF-with-embedded-XML example, the XML carries a structured extraction
of invoice fields. Record the enclosing PDF URI/version, XML fragment or embedded
artifact locator, and the binding to the signed content. Where signature
verification confirms that the relevant PDF content and XML embedding are
covered, modification is detectable relative to that verified signed revision.
Record the verification result and covered revision; embedding XML alone does
not make it tamper-evident. Later changes outside that verified coverage must not
inherit the earlier integrity claim. Signature coverage proves no automatic
semantic agreement between rendered fields and XML; compare them and retain any
disagreement as evidence. No real signature verification is performed by this
illustration.

### 4.2 Adjudication

`urn:example:award:7:revision:1` identifies an award document. An outcome assertion
states that the named tribunal determined a particular dispute as recorded in a
specified paragraph. The source may also contain background assertions that are
not determinations. Capture those separately. A downstream commercial model may
use the outcome while retaining the source's scope and recorded status.

## 5. Conformance cases

| Case | Expected result |
| --- | --- |
| Three invoice assertions reference one versioned source, each with an interest and field locator | Accept the pair separation. |
| A PDF is labelled Evidence with no distinct assertion | Reject: identify the source and capture the assertion. |
| An issuer name is the sole Evidence Source | Reject: identify an addressable information container. |
| XML is embedded but signature coverage is unverified | Do not assert a verified integrity binding. |
| Rendered invoice and embedded XML disagree | Preserve both assertions and record the discrepancy. |
| An award document is equated with an outcome assertion | Reject: separate source from outcome evidence. |
| A strength value has no scheme or assessment scope | Reject the strength assessment as uninterpretable. |
| A source is authentic but unrelated to the question | Do not infer strong support for that question. |

## 6. Provenance and continuation

The [project ledger](../../../../prj-canon-federation/ledger/README.md) pins the
identity-canon donor at `4bb474970b73d500da03b6482e84e6c256146b79` and assigns
these concepts under accepted ADR-006. This model replaces the donor glossary's
source-subtype treatment of Adjudication Outcome with an assertion/source pair.
The governance seed's original broad Evidence definition remains in seeds/ as
historical provenance; the live governance section now imports this model.

Native INFO-WP-0020 implements CFED-WP-0001-T11. CFED T05/T06 own identity and
commerce imports; T07 owns corpus disposition; T08 owns reciprocal interface
cards. The original donor corpus and finished native workplans remain unchanged.