Introduce shared evidence model and governance imports
Assistant: codex Assistant-Model: gpt-6-astra Assistant-Session: 01a070b5-4994-7271-bd8b-7c3dbcedec4b
This commit is contained in:
parent
305a4d6bd8
commit
a2b254786e
54 changed files with 854 additions and 177 deletions
|
|
@ -142,12 +142,13 @@ Decision
|
|||
Approval
|
||||
Exception
|
||||
Risk
|
||||
Evidence
|
||||
Review
|
||||
Audit
|
||||
ComplianceRequirement
|
||||
```
|
||||
|
||||
Evidence and Evidence Source are imported from ITC-EVID.
|
||||
|
||||
The Access Control Model uses governance concepts for:
|
||||
|
||||
```text
|
||||
|
|
|
|||
|
|
@ -22,6 +22,7 @@ imports:
|
|||
- InfoTechCanonCore
|
||||
- InfoTechCanonLandscapeModel
|
||||
- InfoTechCanonGovernanceModel
|
||||
- InfoTechCanonEvidenceModel
|
||||
- InfoTechCanonPurposeDemandExtension
|
||||
- InfoTechCanonObservabilityModel
|
||||
related:
|
||||
|
|
@ -113,7 +114,8 @@ Resource classes → native units ← classification owned here
|
|||
## 2.2 Out of Scope
|
||||
|
||||
- landscape entities, services, technologies, and runtime resources — ITC-LAND;
|
||||
- policy, control, and evidence semantics — ITC-GOV;
|
||||
- policy and control semantics — ITC-GOV;
|
||||
- general evidence and source semantics — ITC-EVID;
|
||||
- permission, grant, and authorization-decision semantics — ITC-ACCESS;
|
||||
- telemetry, SLO measurement, and health — ITC-OBS;
|
||||
- delivery pipeline semantics — ITC-DEVSECOPS;
|
||||
|
|
|
|||
|
|
@ -138,12 +138,13 @@ Obligation
|
|||
Control
|
||||
Risk
|
||||
Exception
|
||||
Evidence
|
||||
Review
|
||||
Approval
|
||||
ComplianceRequirement
|
||||
```
|
||||
|
||||
Evidence and Evidence Source are imported from ITC-EVID.
|
||||
|
||||
The Data Model owns data-specific structures that are governed:
|
||||
|
||||
```text
|
||||
|
|
|
|||
|
|
@ -181,12 +181,13 @@ Control
|
|||
Decision
|
||||
Approval
|
||||
Exception
|
||||
Evidence
|
||||
Assurance
|
||||
Review
|
||||
RiskAcceptance
|
||||
```
|
||||
|
||||
Evidence and Evidence Source are imported from ITC-EVID.
|
||||
|
||||
The DevSecOps Model references governance when delivery activity is governed.
|
||||
|
||||
Examples:
|
||||
|
|
|
|||
187
infospace/models/evidence/InfoTechCanonEvidenceModel.md
Normal file
187
infospace/models/evidence/InfoTechCanonEvidenceModel.md
Normal file
|
|
@ -0,0 +1,187 @@
|
|||
---
|
||||
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.
|
||||
|
|
@ -4,6 +4,7 @@
|
|||
**Document Status:** Seed Standard Release Candidate 1
|
||||
**Version:** RC1-seed
|
||||
**Date:** 2026-05-22
|
||||
**Boundary updated:** 2026-09-05 — Evidence imported from ITC-EVID (INFO-WP-0020).
|
||||
**Repository Context:** `info-tech-canon`
|
||||
**Document Type:** InfoTechCanon Domain Standard
|
||||
**Intended Audience:** Governance designers, enterprise architects, service owners, platform owners, risk managers, compliance reviewers, security architects, quality managers, auditors, product owners, DevSecOps teams, organization designers, knowledge-system builders, standards authors, and agentic tooling.
|
||||
|
|
@ -29,7 +30,7 @@ It provides the canonical vocabulary for:
|
|||
- issues,
|
||||
- exceptions,
|
||||
- waivers,
|
||||
- evidence,
|
||||
- governance uses of imported evidence,
|
||||
- assurance,
|
||||
- audits,
|
||||
- reviews,
|
||||
|
|
@ -120,7 +121,6 @@ Risk
|
|||
Issue
|
||||
Exception
|
||||
Waiver
|
||||
Evidence
|
||||
Assurance
|
||||
Audit
|
||||
Review
|
||||
|
|
@ -189,7 +189,6 @@ Control
|
|||
ControlObjective
|
||||
Policy
|
||||
Exception
|
||||
Evidence
|
||||
Assurance
|
||||
ComplianceRequirement
|
||||
```
|
||||
|
|
@ -220,6 +219,16 @@ AccessException as an exception
|
|||
|
||||
---
|
||||
|
||||
## 3.5 Boundary with Evidence
|
||||
|
||||
ITC-EVID owns Evidence, Evidence Source, Adjudication Outcome and general evidence
|
||||
strength under CUST-ADR-006 R3/R5/R7. Governance imports the pair for control,
|
||||
policy, decision and assurance reasoning. AssuranceCase, AssuranceConclusion,
|
||||
Audit and the existing EvidenceBasis quantity-origin application remain here.
|
||||
EvidenceBasis is not a competing definition of general evidence strength.
|
||||
|
||||
---
|
||||
|
||||
# 4. Research Basis and External Alignment
|
||||
|
||||
This seed standard draws on multiple bodies of governance knowledge.
|
||||
|
|
@ -258,7 +267,7 @@ NIST CSF 2.0 introduced `Govern` as one of its top-level functions alongside Ide
|
|||
|
||||
## 4.7 ISO 9001 Roles, Responsibilities, and Authorities
|
||||
|
||||
Quality management practice emphasizes that responsibilities and authorities must be assigned, communicated, and understood. In InfoTechCanon, Organization owns the actor/role structure, while Governance owns the rules and evidence that ensure responsibilities and authorities are directed and reviewed.
|
||||
Quality management practice emphasizes that responsibilities and authorities must be assigned, communicated, and understood. In InfoTechCanon, Organization owns the actor/role structure, while Governance owns the rules and imports evidence that ensures responsibilities and authorities are directed and reviewed.
|
||||
|
||||
## 4.8 Audit, Assurance, and Compliance Practice
|
||||
|
||||
|
|
@ -499,7 +508,6 @@ GovernanceEntity
|
|||
│ ├── CompensatingControl
|
||||
│ └── ExpiryCondition
|
||||
├── EvidenceEntity
|
||||
│ ├── Evidence
|
||||
│ ├── Attestation
|
||||
│ ├── Assertion
|
||||
│ ├── Finding
|
||||
|
|
@ -1048,26 +1056,15 @@ A **CompensatingControl** is a control used to reduce risk when the primary expe
|
|||
|
||||
## 11.34 Evidence
|
||||
|
||||
**Evidence** is information used to support a claim, decision, control result, compliance status, risk assessment, audit conclusion, or assurance case.
|
||||
Evidence and Evidence Source are imported from
|
||||
[ITC-EVID](../evidence/InfoTechCanonEvidenceModel.md), which owns their definitions.
|
||||
A governance evidence record identifies a distinct assertion, its addressable
|
||||
source/version and the interest it supports. Logs, tickets, screenshots and audit
|
||||
reports are possible sources; a claim drawn from one is the evidence assertion.
|
||||
This section retains its locator for existing consumers, not concept ownership.
|
||||
|
||||
Examples:
|
||||
|
||||
```text
|
||||
log extract
|
||||
signed attestation
|
||||
ticket
|
||||
screenshot
|
||||
scan result
|
||||
configuration file
|
||||
test result
|
||||
deployment record
|
||||
policy document
|
||||
meeting decision
|
||||
audit sample
|
||||
```
|
||||
|
||||
A quantity offered as evidence MUST declare an **EvidenceBasis** (§11.34a)
|
||||
so a decision can be graded by the weakest thing it actually rests on.
|
||||
A quantity offered as governance evidence MUST declare an **EvidenceBasis**
|
||||
(§11.34a) under the existing quantity-origin application rules.
|
||||
|
||||
---
|
||||
|
||||
|
|
@ -1403,7 +1400,7 @@ Policy
|
|||
-> Control
|
||||
-> ControlImplementation
|
||||
-> ControlActivity / ControlTest
|
||||
-> Evidence
|
||||
-> itc-evid:Evidence (assertion drawn_from itc-evid:Evidence Source)
|
||||
-> AssuranceConclusion
|
||||
```
|
||||
|
||||
|
|
@ -1856,6 +1853,9 @@ risk-driven work
|
|||
exception remediation
|
||||
```
|
||||
|
||||
Evidence consumers import the general pair directly from ITC-EVID; the following
|
||||
lists contain only governance-owned concepts.
|
||||
|
||||
## 18.4 Tagging Standard
|
||||
|
||||
Tagging imports governance concepts for:
|
||||
|
|
@ -1868,7 +1868,6 @@ compliance
|
|||
exception
|
||||
review
|
||||
approval
|
||||
evidence
|
||||
audit
|
||||
```
|
||||
|
||||
|
|
@ -1884,7 +1883,6 @@ access review
|
|||
exception
|
||||
waiver
|
||||
control objective
|
||||
evidence
|
||||
```
|
||||
|
||||
## 18.6 Security Model
|
||||
|
|
@ -1897,7 +1895,6 @@ security control objective
|
|||
risk
|
||||
exception
|
||||
finding
|
||||
evidence
|
||||
assurance
|
||||
compliance requirement
|
||||
```
|
||||
|
|
@ -1914,6 +1911,7 @@ Example:
|
|||
subsystem: governance-policy-registry
|
||||
implements:
|
||||
- InfoTechCanonGovernanceModel
|
||||
- InfoTechCanonEvidenceModel
|
||||
- SmallSaaSGovernanceProfile
|
||||
produces:
|
||||
- Policy
|
||||
|
|
@ -2138,7 +2136,7 @@ standards/governance/agent-brief.md
|
|||
standards/governance/concepts/policy.md
|
||||
standards/governance/concepts/control.md
|
||||
standards/governance/concepts/risk.md
|
||||
standards/governance/concepts/evidence.md
|
||||
models/evidence/InfoTechCanonEvidenceModel.md
|
||||
standards/governance/concepts/exception.md
|
||||
standards/governance/concepts/decision.md
|
||||
standards/governance/patterns/policy-control-evidence-chain.md
|
||||
|
|
|
|||
|
|
@ -130,7 +130,7 @@ A corpus of Markdown files may be treated as data by the Data Model, but the inf
|
|||
|
||||
## 3.4 Boundary with Governance
|
||||
|
||||
Governance owns policies, controls, decisions, exceptions, evidence, and assurance.
|
||||
Governance owns policies, controls, decisions, exceptions, and assurance. Evidence and Evidence Source are imported from ITC-EVID.
|
||||
|
||||
The Information Space Model owns how governance documents, evidence references, citations, and versioned documentation artifacts are structured and retrieved.
|
||||
|
||||
|
|
|
|||
|
|
@ -185,7 +185,7 @@ Network determines what traffic the firewall rule permits or denies.
|
|||
|
||||
## 3.4 Boundary with Governance
|
||||
|
||||
Governance owns policies, controls, exceptions, evidence, and reviews.
|
||||
Governance owns policies, controls, exceptions, and reviews. Evidence and Evidence Source are imported from ITC-EVID.
|
||||
|
||||
Network owns network policy as technical traffic-control semantics while referencing governance policies as sources or constraints.
|
||||
|
||||
|
|
|
|||
|
|
@ -152,7 +152,7 @@ SecurityIncident may reference Alert, Trace, LogRecord, or Event.
|
|||
|
||||
## 3.3 Boundary with Governance
|
||||
|
||||
Governance owns policies, controls, evidence, reviews, assurance, and compliance claims.
|
||||
Governance owns policies, controls, reviews, assurance, and compliance claims. Evidence and Evidence Source are imported from ITC-EVID.
|
||||
|
||||
Observability provides evidence and indicators.
|
||||
|
||||
|
|
|
|||
|
|
@ -1698,7 +1698,8 @@ standards/organization/mappings/raci.yaml
|
|||
## Phase 3: Governance Boundary
|
||||
|
||||
- Create or align with `InfoTechCanonGovernanceModel`.
|
||||
- Move policies, controls, risks, obligations, evidence, and decision governance to Governance.
|
||||
- Move policies, controls, risks, obligations, and decision governance to Governance.
|
||||
- Import general Evidence and Evidence Source from ITC-EVID.
|
||||
- Keep actor, authority, accountability, and responsibility concepts here.
|
||||
|
||||
## Phase 4: First Assimilations
|
||||
|
|
|
|||
|
|
@ -82,7 +82,6 @@ ControlObjective
|
|||
Control
|
||||
Risk
|
||||
Exception
|
||||
Evidence
|
||||
Audit
|
||||
Assurance
|
||||
ComplianceRequirement
|
||||
|
|
@ -91,6 +90,8 @@ Approval
|
|||
Review
|
||||
```
|
||||
|
||||
Evidence and Evidence Source are imported from ITC-EVID.
|
||||
|
||||
The Security Model owns:
|
||||
|
||||
```text
|
||||
|
|
|
|||
|
|
@ -129,11 +129,12 @@ Review
|
|||
Risk
|
||||
Control
|
||||
Exception
|
||||
Evidence
|
||||
Obligation
|
||||
Requirement
|
||||
```
|
||||
|
||||
Evidence and Evidence Source are imported from ITC-EVID.
|
||||
|
||||
The Task Model may reference these when work is created by or constrained by governance.
|
||||
|
||||
Examples:
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue