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

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

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 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.