8. Extended Taxonomy Controls

These cards apply when governed meaning, classification, labels, identifiers, semantic grain, or physical semantic anchoring materially affect the decision path.

ET-001: Taxonomy Scope and Purpose Are Declared

Prerequisites	Pass required: CORE-004.
Specification requirement	Each Extended Taxonomy evaluation shall declare the taxonomy scope and purpose for the stated decision scope.
Why this control exists	Classification cannot be tested if its scope and purpose are not declared.
When this applies	When an Extended Taxonomy is used for the decision scope and the boundary or purpose of that taxonomy must be explicit.
Evidence to inspect	Taxonomy scope record, purpose statement, owner, version, applicable decision-scope mapping, and excluded meanings.
Evidence sufficiency	The taxonomy-scope evidence must define what the Extended Taxonomy covers for this decision scope, why it is being used, who owns it, which version applies, and which meanings are explicitly outside the declared boundary. Insufficient: An enterprise-wide glossary or taxonomy reference is not sufficient when the decision-specific purpose, boundary, excluded meanings, owner, or applicable version cannot be determined.
Assessment procedure	1. Inspect the taxonomy scope record and verify purpose, owner, version, applicable decision scope, and excluded meanings are explicit. 2. Confirm the declared taxonomy boundary is adequate for the material concepts in the scope.
Control-result determination	Pass: The record identifies the taxonomy scope, purpose, owner, version, applicable decision scope, and excluded meanings. Fail: Taxonomy scope or purpose is missing, ambiguous, or not linked to the decision scope.
Common failure modes	• Taxonomy scope is enterprise-wide but the decision use is unclear. • Excluded meanings are not stated. • Purpose is generic documentation rather than the decision scope. • Owner or version is missing.
Remediation procedure	Pattern references: R-02 - Ambiguous meaning; R-04 - Missing authority; R-01 - Missing evidence If the taxonomy is enterprise-wide but its decision use is unclear: define the taxonomy boundary that is relevant to the stated decision scope If excluded meanings are not stated: record the meanings, classifications, or domains that are outside the taxonomy scope for this use If the stated purpose is generic documentation rather than the decision use: state why the taxonomy is needed for this decision scope If the owner or applicable version is missing: record the accountable taxonomy owner and the version used by the decision scope
Repeatable fix	Taxonomy scope records use a standard scope-and-purpose template tied to the decision scope and version.
Controlled disposition	Disposition reference: D-02, Unresolved governed evidence. Use this reference when the taxonomy scope or purpose is not yet sufficiently defined for the decision scope.
Example	The taxonomy covers subscription-customer status terms for internal operating review and explicitly excludes regulatory classifications.
Non-example	A company-wide glossary is cited without identifying which part or purpose governs the decision scope.
Authority and execution	Authority: Taxonomy owner defines scope and purpose for the decision use.
Retest	Reinspect the taxonomy-scope record. Confirm that scope, purpose, owner, version, decision-scope applicability, and excluded meanings are explicit and consistent.

ET-002: Ownership and Stewardship Are Recorded

Prerequisites	Pass required: ET-001.
Specification requirement	Each material taxonomy node shall record business ownership or stewardship authority.
Why this control exists	Accountability requires a recorded authority.
When this applies	When a material taxonomy node requires accountable business ownership, stewardship, approval, change authority, or dispute resolution.
Evidence to inspect	Owner or steward record, authority scope, approval responsibility, and review condition.
Evidence sufficiency	The ownership evidence must identify the accountable owner or steward for each material taxonomy node and define that role's authority for approval, change, dispute resolution, and review. Insufficient: A team name, technical custodian, system owner, or contact person is not sufficient when that party has not been given the business authority needed to approve or resolve the governed meaning.
Assessment procedure	1. Inspect each material taxonomy node for a named owner or steward, authority scope, approval responsibility, and review condition. 2. Verify the named authority can resolve meaning, change, and dispute decisions.
Control-result determination	Pass: Owner or steward, authority scope, approval responsibility, and review condition are recorded. Fail: A material concept or classification lacks authority for approval, change, or dispute resolution.
Common failure modes	• Technical owner is assumed to have business authority. • Ownership is listed but authority scope is missing. • No one is empowered to resolve disputes. • Review condition is absent after organizational change.
Remediation procedure	Pattern reference: R-04 - Missing authority If a technical owner is being treated as the business authority: assign the business owner or steward who has authority over meaning and use If an owner is named but the authority scope is missing: record the decisions that the owner or steward is permitted to make If no one is empowered to resolve disputes: assign a dispute-resolution authority or escalation path If organizational change made the ownership record outdated: review and update the owner, authority scope, and review condition
Repeatable fix	Governed nodes require an accountable role and authority source before approval or change.
Controlled disposition	Disposition reference: D-02, Unresolved governed evidence. Use this reference when a material taxonomy node lacks the business ownership or stewardship authority required to govern it.
Example	Finance owns Revenue Recognition Status; the steward may approve labels but not policy meaning.
Non-example	A taxonomy term is “owned by the data team” with no named business authority or dispute process.
Authority and execution	Authority: Business governance authority assigns ownership or stewardship and its decision rights.
Retest	Reinspect each affected taxonomy node. Confirm that a business owner or steward with the required authority scope, approval responsibility, dispute authority, and review condition is recorded.

ET-003: Taxonomy Node Type Is Declared

Prerequisites	Pass required: ET-002.
Specification requirement	Each material taxonomy node shall declare its node type.
Why this control exists	Node type controls how the node may be interpreted and used.
When this applies	When a material taxonomy node is used and its node type affects how the node may be interpreted, governed, or applied.
Evidence to inspect	Taxonomy node record, node type list, approval record.
Evidence sufficiency	The taxonomy-node evidence must assign every material node an approved node type and make the type explicit enough to govern how the node may be interpreted and used. Insufficient: A naming convention, folder location, visual shape, or reader assumption is not sufficient to establish whether a node is a concept, category, classification, alias, code set, identifier concept, deprecated term, or another approved type.
Assessment procedure	1. Inspect every material taxonomy node used by the scope, or an approved complete extract. 2. Verify each has an approved node type and that the type governs how the node may be interpreted.
Control-result determination	Pass: Each node is identified as concept, category, domain, subdomain, classification, label, alias, deprecated term, code set, identifier concept, or other approved node type. Fail: A material node lacks a declared type or uses an unapproved type.
Common failure modes	• Node type is inferred from naming convention. • Aliases and concepts are stored as the same type. • Local custom types have no approval. • Node type changed without review of downstream use.
Remediation procedure	Pattern references: R-02 - Ambiguous meaning; R-01 - Missing evidence If node type is inferred from naming convention: assign an approved node type explicitly If aliases, concepts, categories, or other node classes are stored as though they are the same type: reclassify the affected nodes using the approved node-type model If a locally invented node type has no approval: map it to an approved type or obtain taxonomy-authority approval before governed use If a node type changed without reviewing downstream use: identify affected decision scopes and reassess the uses that depend on the prior type
Repeatable fix	The taxonomy service or stewardship process enforces an approved node-type list and records changes.
Controlled disposition	Disposition reference: D-02, Unresolved governed evidence. Use this reference when a material taxonomy node lacks an approved node type.
Example	“Active Customer” is typed as a classification and “Customer” as a concept.
Non-example	Nodes are stored as unlabeled terms, so a category and an identifier concept are indistinguishable.
Authority and execution	Authority: Taxonomy steward or governing semantic authority approves node types.
Retest	Reinspect each affected material taxonomy node. Confirm that every node now has an approved node type that is explicit and governs interpretation and use.

ET-004: Business Meaning Is Recorded

Prerequisites	Pass required: ET-003.
Specification requirement	Each material taxonomy node shall have recorded business meaning.
Why this control exists	Labels alone do not establish governed business meaning or readiness for decision use.
When this applies	When a material taxonomy node contributes business meaning to the decision path.
Evidence to inspect	Definition record, semantic boundary, owner/steward approval, version, decision-scope mapping.
Evidence sufficiency	The business-meaning evidence must provide an approved definition, semantic boundary, accountable owner, applicable version, and decision-scope applicability for each material taxonomy node. Insufficient: A technical expression, circular definition, local shorthand, label alone, or undocumented team understanding is not sufficient when it does not establish the approved business meaning and boundary for the decision scope.
Assessment procedure	1. Inspect each material taxonomy node. 2. Verify approved definition, semantic boundary, owner, version, and decision-scope applicability are recorded and that the definition is business-meaningful rather than only technical or local.
Control-result determination	Pass: The record includes approved definition, semantic boundary, owner, version, and decision-scope applicability. Fail: Meaning is missing, ambiguous, only technical, only local, or not approved for the decision scope.
Common failure modes	• Definition is technical or circular. • Business boundary is absent. • Local meaning is mistaken for enterprise-approved meaning. • Definition has no accountable owner or effective version.
Remediation procedure	Pattern references: R-02 - Ambiguous meaning; R-04 - Missing authority If the definition is technical, circular, or otherwise fails to express business meaning: replace it with an approved business definition that states what the concept means If the business boundary is missing: record the relevant inclusions, exclusions, or boundary conditions If a local meaning is being treated as the approved business meaning: resolve the meaning with the accountable semantic authority and record the approved version If the definition has no accountable owner or effective version: assign the owner and record the applicable version or effective period
Repeatable fix	Material nodes cannot reach ready-for-use status without governed meaning and versioned ownership.
Controlled disposition	Disposition reference: D-02, Unresolved governed evidence. Use this reference when the approved business meaning or semantic boundary of a material taxonomy node is unresolved.
Example	Active Customer defines included and excluded account conditions and names Customer Operations as owner.
Non-example	The only definition is a SQL expression with no approved business meaning.
Authority and execution	Authority: Business concept owner or steward approves meaning and boundary.
Retest	Reinspect each affected material taxonomy node. Confirm that approved business meaning, semantic boundary, owner, version, and decision-scope applicability are now recorded.

ET-005: Controlled Label and Language Evidence Are Recorded

Prerequisites	Pass required: ET-004.
Specification requirement	Each material concept or classification shall record authoritative labels and non-authoritative variants.
Why this control exists	Controlled language reduces semantic ambiguity across systems and decision paths.
When this applies	When labels, aliases, synonyms, deprecated terms, local variants, or prohibited terms can affect interpretation of a material concept or classification.
Evidence to inspect	Preferred-label record; permitted synonyms, aliases, deprecated terms, and local variants, including explicit no-entry statements where appropriate; prohibited labels where applicable; and approval record.
Evidence sufficiency	The record distinguishes the preferred label from permitted synonyms, aliases, deprecated terms, and local variants. Empty required categories are recorded explicitly. Prohibited labels are recorded where applicable. Insufficient: A word list without authority, variant status, or an explanation for empty required categories does not establish governed language.
Assessment procedure	1. Inspect the controlled-language record for every material concept or classification. 2. Verify preferred label, permitted synonyms, aliases, deprecated terms, and local variants. Where a required category is empty, verify an explicit no-entry statement. 3. Verify prohibited labels where applicable and trace approval and concept mapping.
Control-result determination	Pass: The record identifies the preferred label and records permitted synonyms, aliases, deprecated terms, and local variants. Record prohibited labels where applicable. If a required category has no entries, record that fact rather than inventing a label or leaving an unexplained gap. Fail: The decision path depends on labels that are unapproved, ambiguous, deprecated, or not linked to an approved concept.
Common failure modes	• Synonyms are treated as exact equivalents without approval. • Deprecated labels remain active. • Local variants are undocumented. • Prohibited labels are known socially but not recorded.
Remediation procedure	Pattern reference: R-02 - Ambiguous meaning If synonyms or aliases are treated as exact equivalents without approval: classify the preferred label, permitted synonyms, aliases, and local variants under the approved concept If deprecated labels remain active in material use: mark them as deprecated and prevent them from being treated as current approved language If local variants are undocumented: record the local variants and their governed mapping to the approved concept If prohibited labels are known only through informal practice: record the prohibited labels and the rule that prevents their approved use
Repeatable fix	A controlled-label register is versioned and checked when terms enter a material decision path.
Controlled disposition	Disposition reference: D-02, Unresolved governed evidence. Use this reference when material labels or language variants are not yet governed well enough for the decision scope.
Example	“Acct” is recorded as a permitted local alias for Account; an obsolete label is marked deprecated.
Non-example	Two teams use “active” for different meanings and both labels are accepted without distinction.
Authority and execution	Authority: Terminology or taxonomy authority approves preferred, permitted, deprecated, and prohibited labels.
Retest	Reinspect each required label category and its approval. Confirm authoritative and non-authoritative variants are distinguished, empty required categories are recorded, and prohibited labels are identified where applicable.

ET-006: Semantic Domain and Boundary Are Declared

Prerequisites	Pass required: ET-004.
Specification requirement	Each material concept or classification shall declare its semantic domain and boundary.
Why this control exists	The enterprise must know where one meaning ends and another begins.
When this applies	When a material concept or classification can be confused with adjacent, overlapping, broader, narrower, or excluded meanings.
Evidence to inspect	Semantic domain, included and excluded meanings, boundary rules, and material overlap/disjointness rules with decision-scope mapping.
Evidence sufficiency	The semantic-boundary evidence must state the domain of the concept or classification, what meanings are included, what meanings are excluded, and any material overlap or disjointness rules that affect decision use. Insufficient: A definition is not sufficient when a reviewer cannot determine where the concept stops, what nearby meanings are excluded, or how overlapping concepts are handled for the stated decision scope.
Assessment procedure	1. Inspect domain and boundary rules for each material concept or classification. 2. Verify included meanings, excluded meanings, and overlap or disjointness rules are explicit where they affect decision use.
Control-result determination	Pass: The record states domain, boundary rules, included meanings, excluded meanings, and overlap/disjointness rules where material. Fail: Domain or boundary is missing where the distinction affects decision use.
Common failure modes	• Included and excluded meanings overlap. • Two concepts share a label but differ in domain. • Disjointness assumptions are undocumented. • Boundary rules exist but do not cover the decision use.
Remediation procedure	Pattern references: R-02 - Ambiguous meaning; R-05 - Conflicting evidence If included and excluded meanings overlap without a rule: define the boundary and the approved overlap or disjointness rule If two concepts share a label but belong to different semantic domains: separate or qualify the concepts so their domain-specific meanings cannot be confused If disjointness or overlap is assumed but not recorded: document the applicable relationship between the semantic domains If existing boundary rules do not cover the stated decision use: extend the boundary rule or narrow the decision use until the semantic boundary is explicit
Repeatable fix	Boundary criteria are recorded as reusable rules tied to the concept and decision scope.
Controlled disposition	Disposition reference: D-02, Unresolved governed evidence. Use this reference when a material semantic domain or boundary is missing or unresolved.
Example	Customer Account excludes prospects and defines how reseller-held accounts are treated.
Non-example	A term is defined broadly enough that customer, prospect, and billing contact can all qualify depending on the user.
Authority and execution	Authority: Semantic domain owner or steward approves boundary, inclusion, exclusion, and overlap rules.
Retest	Reinspect the semantic-domain and boundary rules. Confirm that included meanings, excluded meanings, and material overlap or disjointness rules are now explicit for the decision scope.

ET-007: Semantic Grain Is Declared Where Material

Prerequisites	Pass required: ET-006.
Specification requirement	Each material concept, identifier, classification, count, integration point, aggregation, or transformation shall declare semantic grain at each point in the decision path where grain affects interpretation or use. Each material transition between grains shall declare the source grain, transformation or aggregation rule, and resulting grain.
Why this control exists	Same names do not guarantee the same grain or meaning. A decision path may legitimately use multiple grains, but every material grain and transition must be explicit and reconstructable.
When this applies	When grain affects how a material concept, identifier, classification, count, or integration point is compared, counted, joined, or interpreted.
Evidence to inspect	Semantic grain records by point of use, decision-scope mapping, source-grain and resulting-grain records, transformation or aggregation rule for each material grain transition, and Equivalence Rule where distinct grains are treated as comparable.
Evidence sufficiency	Grain is recorded wherever it affects interpretation or use. Every material transition identifies the source grain, governing transformation or aggregation rule, and resulting grain. An approved Equivalence Rule supports any treatment of distinct grains as comparable. Insufficient: Naming a source grain or recording equivalence alone does not explain an implicit material grain transition.
Assessment procedure	1. Trace each material concept, identifier, classification, count, integration point, aggregation, or transformation through its points of use. 2. Verify the grain at each relevant point. 3. Inspect source grain, governing transformation or aggregation rule, and resulting grain for every material transition. 4. Test any cross-grain comparability against the recorded Equivalence Rule.
Control-result determination	Pass: The record states the business level at which each material concept, identifier, classification, or count is unique, meaningful, counted, integrated, aggregated, or compared at its point of use, and every material grain transition is explicitly recorded with its governing transformation or aggregation rule. Fail: Different grains are treated as equivalent without a declared and approved transformation or equivalence rule, a material grain transition is implicit, or the grain at a point of consumption cannot be reconstructed.
Common failure modes	• Counts at different grains are compared directly. • Identifier grain is assumed from column name. • Aggregation changes the business meaning. • Equivalence between grains is used without an approved rule.
Remediation procedure	Pattern references: R-03 - Unstable identity or grain; R-02 - Ambiguous meaning If counts, concepts, or identifiers at different grains are compared directly: align them to a common governed grain or use an approved cross-grain rule If identifier grain is inferred from a field or column name: declare the business grain explicitly If aggregation changes the business meaning: record the aggregation grain and the rule that preserves or changes meaning If equivalence between grains is used without approval: establish the governed equivalence rule before relying on the cross-grain comparison
Repeatable fix	Material taxonomy mappings include semantic grain and approved equivalence rules where cross-grain use is necessary.
Controlled disposition	Disposition reference: D-02, Unresolved governed evidence. Use this reference when semantic grain is missing, incompatible, or unsupported by an approved equivalence rule.
Example	Revenue is distinguished at contract, account, and consolidated-customer grain before comparison.
Non-example	Account counts from one source are compared to household counts from another as if the measures share grain.
Authority and execution	Authority: Concept owner and identity or measurement authority approve semantic grain where it affects use.
Retest	Trace every affected point of use and material grain transition. Confirm explicit grain, source-to-result rules, scope mapping, and any approved cross-grain equivalence.

ET-008: Provenance Is Recorded

Prerequisites	Pass required: ET-002.
Specification requirement	Each material taxonomy assertion shall record provenance.
Why this control exists	Decision readiness depends on knowing where meaning came from and when it was valid.
When this applies	When a material semantic assertion must be traced to its source, approval, version, and effective period.
Evidence to inspect	Provenance record, responsible authority or approved rule reference, version, effective date or timestamp.
Evidence sufficiency	The provenance evidence must identify the source of each material semantic assertion, the approving authority or rule, the applicable version, the timestamp or effective period, and the decision scope to which the assertion applies. Insufficient: A definition, label, classification, identifier rule, or boundary is not sufficient when its origin, approval, version, or effective period cannot be established.
Assessment procedure	1. Inspect provenance for each material taxonomy assertion. 2. Verify assertion source, approving authority or rule, version, effective date or timestamp, and decision-scope applicability can be reconstructed.
Control-result determination	Pass: The record identifies the source of the assertion, approving authority or approved rule reference, version, timestamp or effective period, and decision-scope applicability. Fail: Material meaning, label, classification, identifier, or boundary evidence lacks provenance.
Common failure modes	• Meaning is approved but the source of the assertion is unknown. • Effective date is missing. • Imported reference data loses its authority source. • Provenance is retained for data values but not semantic assertions.
Remediation procedure	Pattern reference: R-01 - Missing evidence If the origin of a material semantic assertion is unknown: record the source from which the meaning, label, classification, identifier, or boundary assertion came If the effective date or period is missing: record when the assertion became valid and, where applicable, when it stopped being valid If imported reference data has lost its authority source: preserve the external or internal authority associated with the imported assertion If provenance is kept for data values but not for semantic assertions: add provenance records for the semantic evidence itself
Repeatable fix	Taxonomy changes and assertions are versioned with provenance automatically or through a controlled stewardship record.
Controlled disposition	Disposition reference: D-02, Unresolved governed evidence. Use this reference when material semantic provenance is incomplete or cannot be reconstructed.
Example	A definition shows who approved it, the source policy, version, and effective date.
Non-example	A definition exists, but its origin and approval history are unknown.
Authority and execution	Authority: Semantic steward preserves provenance; the approving authority or rule must be identifiable from the record.
Retest	Reconstruct provenance for each affected semantic assertion. Confirm that source, approving authority or rule, version, effective time, and decision-scope applicability are now retrievable.

ET-009: Physical Semantic Anchors Are Recorded Where Required

Prerequisites	Pass required: CORE-005, ET-007, ET-008.
Specification requirement	Each material concept or classification shall record physical semantic anchors when physical representation affects the decision scope.
Why this control exists	The Extended Taxonomy closes the gap between governed meaning and real-world data.
When this applies	When a governed concept or classification must be tied to its physical representation in source data for the decision scope.
Evidence to inspect	Source-system reference, physical attribute/object reference, data asset reference, code-set or reference-data evidence where applicable.
Evidence sufficiency	The physical-semantic-anchor evidence must identify the source systems and physical representations needed to show how each material governed concept or classification appears in the data used by the decision scope. Insufficient: A governed definition is not sufficient when the reviewer cannot locate the tables, fields, files, messages, events, APIs, documents, code sets, or equivalent source representations that implement the concept for this scope.
Assessment procedure	1. Trace each material concept or classification to the physical representations needed by the decision scope. 2. Verify source systems and relevant tables, fields, files, messages, events, APIs, documents, code sets, or equivalent anchors are recorded.
Control-result determination	Pass: The record identifies source systems and physical representations such as tables, fields, files, messages, events, APIs, documents, code sets, or equivalent evidence objects required by the scope. Fail: A material concept is treated as ready for decision use without required physical representation evidence.
Common failure modes	• Governed concepts have definitions but no physical anchors. • Mappings stop at dataset level when fields or codes are material. • Source changes leave anchors out of date. • Physical representations are recorded without decision-scope relevance.
Remediation procedure	Pattern reference: R-01 - Missing evidence If a governed concept has no physical semantic anchor: record the source systems and physical representations that implement the concept for the decision scope If the mapping stops at dataset level when fields, codes, or other details are material: extend the anchor to the physical elements needed to test the concept If source changes have made the recorded anchors outdated: update the anchors, record the effective version, and reassess affected scopes If physical representations are recorded without showing why they matter to the decision scope: remove irrelevant anchors or bind the material representations explicitly to the stated decision use
Repeatable fix	Approved concepts maintain versioned physical anchors for the sources used by each decision scope.
Controlled disposition	Disposition reference: D-02, Unresolved governed evidence. Use this reference when a governed concept or classification lacks the physical semantic anchors required by the scope.
Example	Active Status maps to Billing.Status_Code and CRM.Account_State for the stated scope.
Non-example	A concept is approved in a glossary, but no one can identify which source fields implement it.
Authority and execution	Authority: Semantic steward owns the concept-to-physical binding; source owners confirm physical representation.
Retest	Trace the affected governed concepts or classifications to their physical source representations again. Confirm that all material physical anchors required by the scope are now recorded and locatable.

ET-010: Source-System Representation Is Recorded Where Required

Prerequisites	Pass required: ET-009.
Specification requirement	Each material concept shall identify source-system representations required for the decision scope.
Why this control exists	A single governed concept may be represented differently across source systems.
When this applies	When the same governed concept is represented in one or more source systems that contribute to the decision path.
Evidence to inspect	Source-system mapping, local term/attribute mapping, source representation notes, decision-scope mapping.
Evidence sufficiency	The source-representation evidence must identify how the governed concept is represented in every contributing source that matters to the decision scope, including material local terms, attributes, codes, and known representation differences. Insufficient: A standardized or enterprise representation is not sufficient when local source representations that affect interpretation, transformation, or testing are missing from the governed mapping.
Assessment procedure	1. For each material concept, inspect source-system mappings. 2. Verify required local terms, attributes, codes, and representation differences are recorded for every source that contributes to the decision path.
Control-result determination	Pass: The record identifies source systems, local terms, local attributes, local codes, and representation differences required to test the decision scope. Fail: The concept is treated as ready for stated use without the source-system representation needed to support the decision path.
Common failure modes	• Only the standardized representation is recorded. • Local codes or terms that drive transformation are omitted. • Source-system differences are normalized without preserving evidence. • New source representations enter the path without mapping.
Remediation procedure	Pattern references: R-01 - Missing evidence; R-08 - Material change or drift If only the standardized representation is recorded: add the source-system representations that materially contribute to the decision path If local codes or terms that drive transformation are omitted: record those local values and their mapping to the governed concept If normalization removes evidence of source-system differences: preserve the source mapping or provenance needed to reconstruct the original representation If a new source representation entered the path without mapping: map and govern the representation before stated use or keep it Quarantined
Repeatable fix	Source onboarding and change processes maintain concept-to-source mappings as versioned evidence.
Controlled disposition	Disposition reference: D-02, Unresolved governed evidence. Use this reference when a material source-system representation is missing from the governed concept mapping.
Example	The concept record shows how Active Status is represented differently in CRM and Billing and which codes map to the governed meaning.
Non-example	A concept is assumed to be implemented identically in every source because the field names look similar.
Authority and execution	Authority: Semantic steward owns the governed mapping; source-system owner confirms local terms, codes, and representations.
Retest	Recheck every contributing source representation for the affected concept. Confirm that material local terms, attributes, codes, and representation differences are now recorded.

ET-011: Business Identifier or Key Evidence Is Recorded Where Applicable

Prerequisites	Pass required: ET-007, ET-008.
Specification requirement	Where a concept is represented by identifiers or keys, the Extended Taxonomy shall record identifier meaning and approved key evidence for the decision scope.
Why this control exists	Business keys often differ by system even when they appear semantically similar.
When this applies	When identifiers or keys represent a material governed concept and equivalence, meaning, grain, or resolution matters to the decision path.
Evidence to inspect	Identifier record, source-key mapping, semantic grain record, material value-format exception where present, and authority or resolution rule.
Evidence sufficiency	The identifier evidence must establish the business meaning, semantic grain, source-system representation, material value-format expectations, and governing authority or resolution rule for each identifier or key used in the decision path. Insufficient: Similar column names, matching formats, or technically joinable values are not sufficient to prove that two identifiers represent the same business identity or grain.
Assessment procedure	1. Inspect material identifiers and keys used to represent governed concepts. 2. Verify business meaning, semantic grain, source representation, material value-format expectations, and authority or resolution rule are recorded before equivalence is asserted.
Control-result determination	Pass: Each material identifier records business meaning, semantic grain, source-system representation, value-format expectation where material, and authority or resolution rule. Fail: Identifier fields or keys are treated as equivalent by name alone or without required evidence.
Common failure modes	• Identifiers with similar names are treated as equivalent. • Key meaning is undocumented. • Source keys represent different grains. • Format or authority changes are ignored. • No resolution rule exists for competing identifiers.
Remediation procedure	Pattern references: R-03 - Unstable identity or grain; R-05 - Conflicting evidence If identifiers with similar names are being treated as equivalent: prove equivalence through governed meaning, grain, source representation, and an approved crosswalk or resolution rule If the business meaning of a key is undocumented: record what business instance the identifier represents If source keys operate at different semantic grains: separate the identifiers by grain or establish an approved cross-grain resolution rule If identifier format or authority changed without review: version the change and reassess the affected identifier mapping If competing identifiers have no resolution rule: define the precedence, crosswalk, or identity-resolution rule and its accountable authority
Repeatable fix	Identifier mappings use governed records that distinguish local keys, business identifiers, crosswalks, and resolution authority.
Controlled disposition	Disposition reference: D-02, Unresolved governed evidence. Use this reference when identifier meaning, grain, source representation, or resolution authority remains unresolved.
Example	Billing Customer Number and CRM Account ID are linked through an approved crosswalk at account grain.
Non-example	Two columns called customer_id are joined directly without proving they identify the same business instance.
Authority and execution	Authority: Identity or identifier authority approves key meaning and resolution; source owners confirm source representation.
Retest	Reinspect each affected identifier or key. Confirm that business meaning, semantic grain, source representation, material format expectations, and authority or resolution rule are now recorded before equivalence is asserted.

ET-012: Resolution or Mastering Rule Is Recorded Where Applicable

Prerequisites	Pass required: ET-011.
Specification requirement	Where multiple source representations or identifiers must be treated as the same concept or instance, the resolution or mastering rule shall be recorded.
Why this control exists	Integration requires tested equivalence, not assumed equivalence.
When this applies	When multiple source representations or identifiers are merged, mastered, counted, or treated as the same concept or business instance.
Evidence to inspect	The resolution or mastering rule used, authority record, threshold record where applicable, exception-handling rule, and exception record when an exception exists.
Evidence sufficiency	The resolution or mastering evidence must state the approved rule used to treat multiple source representations or identifiers as the same concept or instance, including authority, thresholds where applicable, scope, and exception handling. Insufficient: Similar values, analyst judgment, embedded code logic, or system precedence are not sufficient when no approved and reviewable rule explains why the representations may be merged, mastered, counted, or treated as equivalent.
Assessment procedure	1. Identify cases where multiple source representations or identifiers are merged, mastered, counted, or treated as equivalent. 2. Verify an approved resolution or mastering rule, authority, threshold where applicable, exception handling, and scope applicability exist.
Control-result determination	Pass: The record includes approved rule, authority, threshold where applicable, exception handling, and decision-scope applicability. Fail: Source representations are merged, counted, mastered, or treated as equivalent without an approved rule.
Common failure modes	• Records are merged because values are similar. • Mastering precedence is embedded in code without governing authority. • Thresholds change without prospective versioning. • Unresolved cases are silently forced into a match.
Remediation procedure	Pattern references: R-03 - Unstable identity or grain; R-06 - Threshold or rule failure; R-11 - Human adjudication If records are merged only because values appear similar: define the approved resolution or mastering rule that establishes equivalence If mastering precedence exists only inside implementation code: record and govern the precedence rule outside the code as inspectable evidence If thresholds change without versioning: version the threshold and reassess uses affected by the change If unresolved cases are forced into a match: preserve a governed unresolved or exception outcome instead of manufacturing equivalence
Repeatable fix	A versioned mastering or resolution rule is invoked consistently, with exceptions captured as evidence.
Controlled disposition	Disposition reference: D-02, Unresolved governed evidence. Use this reference when multiple representations are being merged, mastered, counted, or treated as equivalent without an approved resolution rule.
Example	Duplicate accounts are merged only when the approved identity rule and tie-break criteria are met.
Non-example	Analysts manually merge records case by case with no documented authority or reproducible rule.
Authority and execution	Authority: Mastering or identity authority approves resolution rules, thresholds, precedence, and exception handling.
Retest	Reapply the approved resolution or mastering rule to the affected cases. Confirm that the rule, authority, thresholds where applicable, exception handling, and scope applicability are recorded and produce the governed result.

ET-013: Governance Constraints, Jurisdiction, and Usage Boundaries Are Recorded

Prerequisites	Pass required: ET-004.
Specification requirement	Each governed taxonomy scope shall record applicable usage boundaries, policy constraints, and jurisdictional authorities. When two applicable authoritative constraints conflict, a recorded precedence or adjudication rule shall resolve the conflict before material use.
Why this control exists	Conflicting authority cannot be converted into permission by assessor judgment. An unresolved legal or policy conflict is a control failure and normally requires a Stop Gate state.
When this applies	When permitted, prohibited, constrained, policy, privacy, security, purpose, or other usage boundaries affect a material taxonomy node.
Evidence to inspect	Applicable constraint/policy records, jurisdiction and authority references, version/effective period, permitted/prohibited use, and any required precedence/adjudication rule. Include conflict and competent-authority resolution records when a conflict exists.
Evidence sufficiency	The governance-constraint evidence must state the permitted, prohibited, and constrained uses that matter to the decision scope and include applicable policy, privacy, security, purpose, or other governance limits. Insufficient: A correct definition is not sufficient when the evidence does not also show where, why, or under what constraints the concept or classification may be used.
Assessment procedure	1. Identify applicable constraints and jurisdictions for the governed taxonomy scope. 2. Verify each constraint’s authority, scope, version/effective period, and permitted/prohibited use. 3. Identify actual conflicts and inspect the pre-recorded precedence/adjudication rule or competent-authority decision resolving each one. 4. If no valid resolution exists, record Fail and apply the Gate disposition before material use.
Control-result determination	Pass: Applicable constraints and jurisdictions are identified; each constraint has authority, scope, version/effective period, and permitted/prohibited use; and each conflict is resolved by a pre-recorded jurisdictional precedence/adjudication rule or explicit competent-authority decision. If no valid resolution exists, the control does not Pass. Fail: Constraints conflict without a valid precedence/adjudication rule, authority is unclear, or material use proceeds despite unresolved mutually exclusive requirements.
Common failure modes	• A valid concept is reused outside its approved purpose. • Privacy or policy constraints are documented elsewhere but not applied to the node. • Prohibited use is not machine- or process-visible. • Scope-specific restrictions are lost downstream.
Remediation procedure	Pattern references: R-10 - Prohibited or out-of-scope use; R-04 - Missing authority If a valid concept is being reused outside its approved purpose: constrain the use to the approved purpose or obtain the required authority for the new use If privacy, policy, security, or other constraints exist elsewhere but are not applied to the node: bind the applicable constraints to the taxonomy evidence used by the decision scope If prohibited use is not visible to the process or system that evaluates the evidence: record the prohibition in a form the Gate or governing process can inspect If scope-specific restrictions are lost downstream: preserve and enforce those restrictions wherever the taxonomy evidence is reused in the material decision path
Repeatable fix	Usage-boundary metadata is reusable and checked whenever the concept is proposed for a new decision scope.
Controlled disposition	Disposition reference: D-05, Threshold, constraint, or conflict. Unresolved mutually exclusive authoritative constraints cause Fail and normally require Stop. Caution is possible only after an explicit competent authority records a bounded resolution/exception that actually permits the stated use.
Example	A customer classification may be used for internal retention analysis but not for adverse eligibility decisions.
Non-example	A governed label is treated as universally usable because its definition is correct.
Authority and execution	Authority: Applicable business, governance, privacy, security, policy, or risk authority approves usage constraints.
Retest	Reinspect applicable constraints, jurisdictions, authority, scope, and effective versions. Confirm actual conflicts are resolved under recorded competent authority before use; containment or an unsupported exception alone does not establish Pass.

ET-014: Semantic Risk Is Recorded Where Present

Prerequisites	Recorded result required: ET-004, ET-013.
Specification requirement	Semantic risk shall be recorded when ambiguity, conflict, overlap, deprecated meaning, local variation, or known misuse may affect the decision scope.
Why this control exists	Unrecorded semantic risk can become hidden decision risk.
When this applies	When known ambiguity, conflict, overlap, deprecated meaning, local variation, or misuse may affect the decision scope.
Evidence to inspect	Semantic risk record, owner, readiness disposition, remediation or exception record.
Evidence sufficiency	The semantic-risk evidence must describe each known material semantic risk, identify the affected decision scope, assign an owner, state the readiness disposition, and link the remediation or approved exception. Insufficient: A known ambiguity, conflict, overlap, deprecated meaning, local variation, or misuse is not sufficiently governed when it exists only in discussion, meeting notes, or undocumented institutional knowledge and has no recorded owner or disposition.
Assessment procedure	1. Review known ambiguity, conflict, overlap, deprecated meaning, local variation, and known misuse for the material concepts. 2. Verify each material semantic risk has an affected scope, owner, readiness disposition, and remediation or exception record.
Control-result determination	Pass: Each material semantic risk has a risk description, affected scope, readiness disposition, owner, and remediation or exception record. Fail: Known semantic risk affects the decision scope and is not recorded.
Common failure modes	• Known ambiguity is discussed but not recorded. • Risk has no owner. • Deprecated meaning continues without disposition. • Overlap or misuse is known but does not affect readiness state or remediation backlog.
Remediation procedure	Pattern references: R-01 - Missing evidence; R-02 - Ambiguous meaning; R-04 - Missing authority If known ambiguity, conflict, overlap, deprecated meaning, local variation, or misuse is only discussed informally: create a semantic-risk record that describes the issue and affected decision scope If the semantic risk has no owner: assign the accountable owner for remediation, constraint, or escalation If deprecated meaning continues without a disposition: remove, constrain, replace, or explicitly disposition the deprecated meaning If known overlap or misuse does not affect readiness or remediation tracking: connect the risk to the appropriate readiness state and remediation or exception record
Repeatable fix	Known ambiguity, overlap, deprecated meaning, and misuse are captured in a repeatable semantic-risk record reviewed at Gates.
Controlled disposition	Disposition reference: D-05, Threshold, constraint, or conflict. Use this reference when a known semantic risk has not yet been resolved, constrained, or given an approved disposition.
Example	“Active” has two legacy interpretations; the risk is recorded, the affected reports are identified, and remediation is assigned.
Non-example	Everyone knows the term is ambiguous, but the issue remains only in meeting notes and undocumented institutional knowledge.
Authority and execution	Authority: Concept owner or semantic risk owner accepts, remediates, constrains, or escalates recorded semantic risk.
Retest	Reinspect each affected semantic-risk record. Confirm that the risk description, affected scope, owner, readiness disposition, and remediation or exception evidence are now recorded.

ET-015: Relationship Seeds Are Not Treated as Decision-Ready Relationships

Prerequisites	Recorded result required: ET-004, ET-008, ET-013.
Specification requirement	Each relationship seed discovered during taxonomy work shall be preserved in a Relationship Candidate Record. Material use shall follow the applicable recorded Gate disposition and its authority and constraints.
Why this control exists	Taxonomy can expose possible relationships; ontology controls determine whether relationship use is defensible.
When this applies	When taxonomy work discovers, suggests, or exposes a relationship candidate that could become material to the decision path.
Evidence to inspect	Relationship Candidate Record, stable relationship-candidate identifier, source/provenance, discovery method, decision-scope reference, readiness state, Extended Ontology review reference when required, Gate Record, and exception record where applicable.
Evidence sufficiency	The Relationship Candidate Record preserves the stable identifier, source/provenance, discovery method, scope, and readiness state. Required ontology review preserves the same identifier. Actual use follows the recorded Gate authority and constraints. Insufficient: A plausible relationship or completed workshop does not establish ready-for-use status. Candidate containment, review, and authorized constrained use remain distinct from a full relationship-control Pass.
Assessment procedure	1. Retrieve each taxonomy-origin Relationship Candidate Record. 2. Verify stable identifier, source/provenance, discovery method, scope, and recorded readiness. 3. Where the Materiality Rule requires ontology review, trace the same candidate identifier into the review record. 4. Compare actual holding or use with the recorded Gate, authority, and any valid constrained-use exception.
Control-result determination	Pass: Each relationship seed has a stable relationship-candidate identifier, source and provenance, discovery method, decision-scope reference, current readiness state, and, when the Materiality Rule requires ontology review, an Extended Ontology review reference that preserves the same candidate identifier. Fail: A relationship seed is relied on as a ready relationship before required Extended Ontology evaluation, or a required seed-to-ontology evidence link cannot be traced by the same relationship-candidate identifier.
Common failure modes	• A likely relationship discovered during taxonomy work is published as approved. • Relationship seeds bypass ontology review. • Candidate status is lost when evidence is exported or reused.
Remediation procedure	Pattern reference: R-07 - Unsupported discovery If a relationship discovered during taxonomy work was published as approved: return it to candidate or Quarantined status until the applicable Extended Ontology controls are completed If a relationship seed bypassed ontology review: route the material relationship to the Extended Ontology assessment path If candidate status is lost when evidence is exported or reused: preserve the candidate or Quarantined state and its review requirement with the exported or reused evidence
Repeatable fix	Taxonomy workflows hand off relationship candidates through a defined ontology review queue with Quarantined state until resolved.
Controlled disposition	Disposition reference: D-03, Ungoverned candidate evidence. Use this reference for relationship seeds discovered during taxonomy work until Extended Ontology review establishes their governed status.
Example	A taxonomy workshop identifies that Account “belongs to” Region; the relationship is logged as a candidate for ontology review.
Non-example	The relationship is added to an approved decision path because it appeared during taxonomy analysis.
Authority and execution	Authority: Taxonomy steward identifies the relationship seed; ontology authority determines whether it becomes an approved relationship.
Retest	Verify each required candidate field and identifier continuity into ontology review where required. Confirm actual handling follows the recorded Gate disposition and any authorized constrained-use bounds.

ET-016: Readiness State Is Declared

Prerequisites	Recorded result required: ET-013, ET-014, ET-015.
Specification requirement	Each material taxonomy node used in a decision path shall have a recorded readiness state for the decision scope.
Why this control exists	Governed meaning must have a decision-scope disposition.
When this applies	When a material taxonomy node is used in the decision path and therefore requires a scope-bound readiness disposition.
Evidence to inspect	Readiness state record, Gate Record, reason, responsible authority or approved rule reference, timestamp, review condition.
Evidence sufficiency	The readiness evidence must show the formal readiness state assigned to each material taxonomy node for the stated decision scope and the supporting reason, authority or rule, timestamp, and review condition where required. Insufficient: Catalog presence, publication status, prior approval, or use in another scope is not sufficient to establish Proceed, Caution, Stop, or Quarantined for the decision scope being assessed.
Assessment procedure	1. Inspect every material taxonomy node used in the decision path. 2. Verify a formal readiness state is supported by Gate evidence, reason, authority or rule, timestamp, and review condition where required.
Control-result determination	Pass: The node is assigned Proceed, Caution, Stop, or Quarantined with reason, responsible authority or approved rule reference, timestamp, and review condition where required. Fail: A material node is used without a readiness state or the state is unsupported by evidence.
Common failure modes	• A readiness state is copied from another scope. • Proceed is inferred from catalog presence. • Reason or authority is absent. • Review date has expired. • Readiness is not updated after material change.
Remediation procedure	Pattern references: R-01 - Missing evidence; R-08 - Material change or drift If a readiness state was copied from another decision scope: evaluate the taxonomy node for the current decision scope and assign a new scope-bound state If Proceed is inferred merely because the node exists in a governed catalog: run the applicable Gate evaluation and record the resulting readiness state If the reason or authority supporting the state is missing: record the basis and responsible authority or rule If the review condition has expired: reassess the node and issue a current readiness state If material change occurred but the readiness state was not updated: rerun the affected evaluation and record a new linked state before further stated use
Repeatable fix	Readiness is derived from Gate evaluation and stored with the taxonomy node for the decision scope.
Controlled disposition	Disposition reference: D-02, Unresolved governed evidence. Use this reference when a material taxonomy node lacks a supported readiness state for the decision scope.
Example	A disputed classification is Caution with an approved internal-use constraint and review date.
Non-example	A node is marked Proceed because it is in the catalog, although required evidence was never evaluated.
Authority and execution	Authority: The responsible decision-scope authority approves the readiness state based on Gate evidence. An approved rule may execute or record the evaluation; the taxonomy owner or steward remains accountable for the underlying semantic condition.
Retest	Reinspect the readiness record for each affected material taxonomy node. Confirm that the formal readiness state is supported by reason, authority or rule, timestamp, Gate evidence, and review condition where required.

ET-017: Taxonomy Change Triggers Reassessment

Prerequisites	Pass required: CORE-023, ET-002. Recorded result required: ET-016.
Specification requirement	Each material Extended Taxonomy change shall trigger impact assessment for active or prospective decision scopes that rely on the changed artifact. Historical Gate and Conformance Records remain fixed to the taxonomy version that governed them.
Why this control exists	Meaning changes can invalidate evidence previously ready for stated use.
When this applies	When a material taxonomy definition, label, boundary, grain, identifier, source representation, ownership, constraint, or readiness state changes.
Evidence to inspect	Taxonomy change/version record, impact rule, affected-scope list, readiness invalidation/reassessment record, new Gate/Conformance Record where required, and immutable historical references.
Evidence sufficiency	The change evidence must show which taxonomy changes are material, which decision scopes are affected, and that those scopes receive the required impact review or Gate reassessment before prior readiness or conformance determination is relied upon. Insufficient: A taxonomy version or change log is not sufficient when a change to meaning, label, boundary, grain, identifier, representation, ownership, constraint, or readiness can occur without reassessing affected decision scopes previously allowed for stated use.
Assessment procedure	1. Inspect taxonomy change rules and a recent or test change to meaning, label, boundary, grain, identifier, representation, ownership, constraint, or readiness state. 2. Verify affected decision scopes are identified and reassessed.
Control-result determination	Pass: A material taxonomy change is versioned, affected active/prospective scopes are identified, prior readiness for new reliance is invalidated or reassessed as defined, and any new Gate/Conformance Record is linked to the prior record without rewriting it. Fail: Future reliance continues under a materially changed taxonomy without reassessment, or historical records are retroactively recalculated or overwritten merely because the taxonomy changed.
Common failure modes	• Taxonomy version changes but affected scopes are not identified. • Label changes are treated as harmless despite semantic impact. • Source representation changes bypass reassessment. • Readiness remains out of date after material taxonomy change.
Remediation procedure	Apply forward-only impact assessment: identify active/prospective scopes, invalidate readiness for new reliance as defined, reassess, and preserve historical records unchanged.
Repeatable fix	Change management connects taxonomy version events to a scope-impact register and reassessment workflow.
Controlled disposition	Disposition reference: D-04, Change or reassessment. Use this reference after a material taxonomy change until affected decision scopes have been identified and reassessed.
Example	Changing the boundary of Active Customer triggers reassessment of every metric previously allowed for stated use using that concept.
Non-example	A definition changes but prior readiness or conformance determinations continue indefinitely with no impact review.
Authority and execution	Authority: Taxonomy owner governs the change; affected decision-scope owners authorize reassessment and resulting disposition. Execution: A material taxonomy change must identify affected decision scopes and route them to impact review or Gate reassessment.
Retest	Apply or inspect a representative material taxonomy change. Confirm that affected decision scopes are identified and the required impact review, Gate reassessment, and linked replacement Conformance Records are created.