9. Extended Ontology Controls

These cards apply when material relationships or relationship paths affect the decision path. Discovery remains permitted; relationship use for the stated decision scope requires the applicable controls to pass.

EO-001: Relationship Candidate Is Not Treated as Decision-Ready

Prerequisites	Recorded result required: ET-015 (when the candidate originated in taxonomy work).
Specification requirement	A relationship candidate shall remain excluded from material reliance unless the applicable recorded Gate disposition explicitly permits its stated use.
Why this control exists	Discovery is valuable, but discovery does not establish readiness for stated use.
When this applies	When a relationship is declared, discovered, inferred, imported, derived, or otherwise introduced as candidate evidence.
Evidence to inspect	Relationship Candidate Record, stable relationship-candidate identifier, source/provenance, readiness state, Extended Ontology review evidence, Gate Record, and exception record where applicable.
Evidence sufficiency	The relationship-candidate evidence must preserve candidate status and show that each material declared, discovered, inferred, imported, or derived relationship is reviewed, constrained, rejected, Quarantined, or approved through the applicable Gate process before stated use. Insufficient: A relationship is not sufficient to establish readiness for stated use merely because it exists in a graph, was imported from an approved or governed system, was inferred with high confidence, or was accepted by an analyst.
Assessment procedure	1. Retrieve the Relationship Candidate Record, readiness state, and applicable review or Gate evidence. 2. Verify no material reliance occurs without a Gate that permits the stated use. 3. For taxonomy-origin candidates, trace the same candidate identifier and source/provenance through ontology review. 4. Verify any constrained use has an authorizing exception and remains within its bounds.
Control-result determination	Pass: The relationship candidate is recorded in a Relationship Candidate Record and has a recorded readiness state and Gate evidence before material use. If it originated in taxonomy work, the same relationship-candidate identifier and source/provenance are preserved through Extended Ontology review. Fail: A candidate relationship is relied on for stated use without the applicable Gate evaluation and readiness state, or a taxonomy-origin candidate loses its identifier or provenance during ontology review.
Common failure modes	• Inferred or discovered relationships are promoted directly into analytics. • Imported graph edges are assumed ready for stated use. • Candidate status is lost. • Constrained use is not recorded before material use.
Remediation procedure	Pattern reference: R-07 - Unsupported discovery If an inferred, discovered, or derived relationship was promoted directly into analytics: return it to candidate or Quarantined status until the applicable Extended Ontology controls pass If an imported graph edge is assumed ready for stated use because it already exists in another system: treat the imported relationship as candidate evidence and evaluate it for the stated decision scope If candidate status was lost: restore the candidate or Quarantined designation and the required review path If constrained use occurs without a recorded exception: record the authorized exception before material use or Stop the use
Repeatable fix	Relationship discovery pipelines separate candidate assertions from governed relationships and route them to review.
Controlled disposition	Disposition reference: D-03, Ungoverned candidate evidence. Use this reference for relationship candidates that have not yet passed the applicable Extended Ontology controls or received an approved constrained-use exception.
Example	A graph-discovered supplier dependency is retained for analysis but cannot drive a sourcing decision until reviewed.
Non-example	An inferred relationship is immediately treated as ready for stated use because the model confidence is high.
Authority and execution	Authority: Relationship discovery may be performed by people or systems. The responsible ontology or decision-scope authority controls promotion toward stated use.
Retest	Verify the candidate record, Gate evidence before material use, and actual handling. For taxonomy-origin candidates, confirm identifier and provenance continuity. Review alone does not establish permission to rely.

EO-002: Relationship Type Is Governed

Prerequisites	Recorded result required: EO-001.
Specification requirement	Each material relationship shall map to an approved relationship type for the decision scope.
Why this control exists	A relationship cannot be tested if its type is not governed.
When this applies	When a material relationship is used and the relationship type determines its governed meaning for the decision scope.
Evidence to inspect	Relationship type record, owner, version, approval record, decision-scope mapping.
Evidence sufficiency	The relationship-type evidence must map each material relationship to a defined, owned, versioned, and approved relationship type for the stated decision scope. Insufficient: A free-text label, local relationship name, graph edge type, or technically valid association is not sufficient when the governed relationship type and its approved business meaning cannot be established.
Assessment procedure	1. Inspect each material relationship used by the decision scope. 2. Verify that each material relationship maps to a defined, owned, versioned, and approved relationship type for that decision scope.
Control-result determination	Pass: The relationship type is defined, owned, versioned, and approved for the stated scope. Fail: The relationship uses an undefined, ambiguous, prohibited, or unapproved type.
Common failure modes	• Relationship labels are locally invented. • One label hides multiple business meanings. • Type owner or version is missing. • Relationship type is technically present but not approved for the scope.
Remediation procedure	Pattern references: R-02 - Ambiguous meaning; R-04 - Missing authority If relationship labels are locally invented: map the relationship to an approved relationship type or govern a new type before use If one relationship label hides more than one business meaning: split the meanings into distinct governed relationship types or define explicit boundaries If the relationship type has no owner or version: assign ownership and record the applicable version If the type exists technically but is not approved for the decision scope: obtain scope approval or keep the relationship out of stated use
Repeatable fix	Relationship-type governance maintains an approved vocabulary and change process.
Controlled disposition	Disposition reference: D-02, Unresolved governed evidence. Use this reference when a material relationship does not yet map to an approved relationship type.
Example	“Account is billed through Billing Customer” uses an approved relationship type for the scope.
Non-example	A relationship labeled “related to” is used without defining what the relationship means.
Authority and execution	Authority: Relationship or ontology authority approves type definition, ownership, and scope use.
Retest	Reinspect each affected material relationship. Confirm that it now maps to a defined, owned, versioned, and approved relationship type for the stated decision scope.

EO-003: Relationship Orientation Is Declared

Prerequisites	Pass required: EO-002.
Specification requirement	Each material relationship shall declare orientation.
Why this control exists	Many failures occur when association is mistaken for authority, sequence is mistaken for cause, or a one-way relationship is treated as symmetrical.
When this applies	When direction, authority, sequence, dependency, ownership, lineage, hierarchy, flow, support, inclusion, identification, reconciliation, constraint, or causality affects use of a material relationship.
Evidence to inspect	Orientation record, orientation type, approval record, decision-scope mapping.
Evidence sufficiency	The orientation evidence must explicitly state the applicable direction or other approved orientation for each material relationship and support the way the relationship is traversed or interpreted in the decision scope. Insufficient: A relationship name alone is not sufficient when the decision depends on direction, authority, sequence, dependency, ownership, lineage, hierarchy, flow, support, inclusion, identification, reconciliation, constraint, or causality.
Assessment procedure	1. Inspect each material relationship for orientation. 2. Verify direction, authority, sequence, dependency, ownership, lineage, hierarchy, flow, support, inclusion, identification, reconciliation, constraint, causality where separately established, or another approved orientation is explicitly recorded.
Control-result determination	Pass: Orientation is recorded as direction, authority, sequence, dependency, ownership, lineage, hierarchy, flow, support, inclusion, identification, reconciliation, constraint, causality where separately established, or another approved orientation. Fail: Orientation is missing or an oriented relationship is used as symmetrical without approval.
Common failure modes	• Direction is omitted. • A one-way relationship is treated as symmetrical. • Sequence is interpreted as causality. • Dependency is treated as ownership. • Authority direction is reversed.
Remediation procedure	Pattern references: R-02 - Ambiguous meaning; R-06 - Threshold or rule failure If relationship direction is omitted: record the approved orientation and allowed direction of use If a one-way relationship is treated as symmetrical: restrict traversal to the approved direction unless symmetrical use is separately approved If sequence is being interpreted as causality: record the relationship as sequence unless separate causal evidence establishes causality If dependency is being treated as ownership: correct the relationship meaning and orientation to the approved type If authority direction is reversed: correct the orientation and reassess any decision path that used the reversed relationship
Repeatable fix	Relationship records require orientation from an approved set and Gate checks validate traversal against it.
Controlled disposition	Disposition reference: D-02, Unresolved governed evidence. Use this reference when the required orientation of a material relationship is missing, ambiguous, or being used incorrectly.
Example	Contract governs Account is directional and cannot be traversed as if Account governs Contract.
Non-example	A correlation discovered in time sequence is labeled causal without separate causal evidence.
Authority and execution	Authority: Relationship or ontology authority approves orientation and any directional semantics.
Retest	Reinspect each affected material relationship and any traversal that uses it. Confirm that the approved orientation is explicit and that the relationship is not used with an unapproved symmetry, direction, or causal interpretation.

EO-004: Relationship Assertion Provenance Is Recorded

Prerequisites	Recorded result required: EO-001, EO-002.
Specification requirement	Each material relationship assertion shall record provenance.
Why this control exists	Relationship accountability requires knowing how the relationship entered the evidence stream.
When this applies	When a material relationship assertion must be traced to how, when, and under what authority or method it was created.
Evidence to inspect	Assertion provenance record, source/method record, responsible authority or approved rule reference, timestamp/effective period, version.
Evidence sufficiency	The relationship-provenance evidence must show how each material assertion was created, its source and method, the responsible authority or rule, the applicable version, and the timestamp or effective period. Insufficient: A graph edge or relationship record is not sufficient when a reviewer cannot determine whether it was declared, inferred, discovered, imported, derived, or generated, or cannot identify the method and authority behind the assertion.
Assessment procedure	1. Inspect each material relationship assertion. 2. Verify that the provenance record states whether the assertion was declared, inferred, discovered, imported, derived, or generated. 3. Verify that the record also identifies the source, method, authority or rule, applicable version, and timestamp or effective period.
Control-result determination	Pass: The assertion records whether it was declared, inferred, discovered, imported, derived, or generated, and includes source, method, responsible authority or approved rule reference, timestamp or effective period, and version. Fail: Source, creation method, authority or rule reference, timestamp/effective period, or version is missing or cannot be retrieved.
Common failure modes	• The relationship is visible but how it was created is unknown. • AI-inferred and human-declared assertions are indistinguishable. • Method version or source is missing. • Effective period is not preserved.
Remediation procedure	Pattern reference: R-01 - Missing evidence If a relationship exists but its origin cannot be determined: add the provenance record or keep the assertion Quarantined until its origin can be established If AI-inferred and human-declared assertions cannot be distinguished: record how each assertion was created and the method or authority responsible for it If the method version or source is missing: record the applicable source and method, rule, or model version If the effective period is missing: record when the relationship assertion is valid for the stated decision scope
Repeatable fix	Every material assertion carries provenance metadata from creation or import.
Controlled disposition	Disposition reference: D-02, Unresolved governed evidence. Use this reference when the provenance of a material relationship assertion is incomplete or cannot be reconstructed.
Example	A relationship records that it was imported from CRM rule set v5 on the effective date and approved by the data steward.
Non-example	A graph edge exists, but no one can tell whether it was declared, inferred, imported, or generated.
Authority and execution	Authority: Assertion authority or method owner must be identifiable; ontology stewardship preserves provenance.
Retest	Reconstruct the provenance of each affected material relationship assertion. Confirm the creation method, source, authority or rule, version, and effective time are now retrievable.

EO-005: Physical Relationship Representation or Boundary Evidence Anchor Is Recorded Where Required

Prerequisites	Pass required: CORE-005, EO-004.
Specification requirement	Each material relationship shall record the physical relationship representation required for the decision scope. Where an external, legacy, proprietary, or third-party system prevents direct inspection, a Boundary Evidence Anchor may represent the relationship boundary only when it identifies the exact external relationship evidence consumed and the inaccessible boundary.
Why this control exists	Extended Ontology closes the gap between governed relationship meaning and real relationship evidence.
When this applies	When a material governed relationship must be tied to the physical join, association, event, message, API, document, lineage, or other representation that substantiates it.
Evidence to inspect	Physical relationship locator or complete Boundary Evidence Anchor, provenance, relationship reference, inaccessible-boundary statement where applicable, and decision-scope mapping.
Evidence sufficiency	Direct physical evidence identifies the representation needed to test the relationship. Where direct inspection is legitimately unavailable, the complete Boundary Evidence Anchor identifies the exact external evidence and inaccessible boundary, required versions and time, relationship reference, and scope mapping. Insufficient: An ontology diagram or vendor attestation alone does not identify the consumed relationship evidence.
Assessment procedure	1. Trace the relationship to its required physical join, event, link, document, API, message, or equivalent evidence. 2. Where direct inspection is legitimately unavailable, verify every required Boundary Evidence Anchor field, including exact evidence identity, interface/version, time, inaccessible boundary, relationship reference, and scope. 3. Inspect fingerprints where possible and supporting contract or attestation references where available. Vendor attestation alone is not sufficient.
Control-result determination	Pass: The relationship can be traced to the required join/event/link/document/API/message or equivalent physical evidence; or a complete Boundary Evidence Anchor records source identity, interface/feed/contract and version, payload/event/message/document identifier, acquisition time/effective period, fingerprint where possible, supporting attestation/contract where available, inaccessible boundary, relationship-candidate or assertion reference, and decision-scope mapping. Vendor attestation alone is not sufficient. Fail: A material relationship is relied on without traceable physical evidence or a complete Boundary Evidence Anchor.
Common failure modes	• A conceptual relationship has no traceable physical evidence. • Joins are inferred from naming alone. • Association structures or relationship attributes are omitted. • Physical representation changes without updating the governed relationship.
Remediation procedure	Pattern references: R-01, R-13 If physical representation is missing: locate and record the evidence used to substantiate the relationship. If a join is inferred only from names: obtain governed relationship evidence. If direct inspection is legitimately unavailable: complete the Boundary Evidence Anchor, including exact evidence identity and inaccessible boundary. If the representation changed: version the new anchor and reassess affected future use. Preserve historical references.
Repeatable fix	Governed relationship records retain the physical representation used by the scope and update it through change control.
Controlled disposition	Disposition reference: D-02, Unresolved governed evidence. Use this reference when a material governed relationship lacks the physical representation needed for testing.
Example	Account-to-Contract is evidenced by the source association table and key mapping.
Non-example	The ontology diagram shows a relationship, but the implementing data cannot be located or tested.
Authority and execution	Authority: Ontology steward owns relationship meaning; source owners confirm the physical relationship evidence.
Retest	Trace the affected relationship to physical evidence or inspect every required field of the permitted Boundary Evidence Anchor. Verify the exact consumed evidence, relationship reference, scope mapping, and conditional fingerprint and supporting-reference obligations.

EO-006: Related Identifier Alignment and Semantic Grain Are Tested

Prerequisites	Pass required: ET-011, EO-003.
Specification requirement	Each material relationship shall test whether related identifiers and concepts are aligned at compatible semantic grain for the decision scope.
Why this control exists	A relationship path can fail because its endpoints identify different business things at different grains.
When this applies	When a material relationship connects identifiers or concepts whose business identity or semantic grain could differ.
Evidence to inspect	Endpoint identity records, business-meaning and semantic-grain records, equivalence/non-equivalence rule, endpoint-alignment test results, and decision-scope mapping.
Evidence sufficiency	Each material endpoint has identity, business-meaning, and grain evidence. A recorded equivalence or non-equivalence rule governs compatibility, and endpoint-alignment test results satisfy that rule for the intended use. Insufficient: Endpoint records, technically joinable keys, or a crosswalk alone do not establish that the intended alignment was tested and satisfied its governing rule.
Assessment procedure	1. Identify both material endpoints and retrieve their identity, meaning, grain, and governing alignment rule. 2. Execute or inspect the endpoint-alignment test for the intended relationship use. 3. Compare recorded test results with the equivalence or non-equivalence rule. 4. Verify intended joining, traversal, counting, or inference does not exceed the demonstrated compatibility.
Control-result determination	Pass: The record identifies each material endpoint, its identity evidence, business meaning, and semantic grain; the governing equivalence or non-equivalence rule is recorded; and endpoint-alignment test results satisfy that rule for the intended relationship use. Fail: Relationship endpoints are joined, traversed, counted, or inferred as compatible without required grain and identity evidence.
Common failure modes	• Endpoints represent different business things or grains. • Source keys are assumed equivalent. • Many-to-many conditions are treated as one-to-one. • Crosswalks exist but are not governed for the scope.
Remediation procedure	Pattern references: R-03 - Unstable identity or grain; R-05 - Conflicting evidence If relationship endpoints represent different business things or incompatible grains: separate the endpoints or establish the governed compatibility or crosswalk rule If source keys are assumed equivalent: prove endpoint identity through approved Business Identity evidence or a governed crosswalk If a many-to-many condition is treated as one-to-one: record the actual cardinality or grain and correct the relationship logic If a crosswalk exists but is not governed for the decision scope: approve, version, and bind the crosswalk to the stated scope before stated use
Repeatable fix	Relationship onboarding requires endpoint identity and grain checks before traversal is approved.
Controlled disposition	Disposition reference: D-02, Unresolved governed evidence. Use this reference when relationship endpoints do not yet have demonstrated identity and grain compatibility.
Example	Account-to-Billing Customer uses a governed crosswalk proving both endpoints represent account-level business instances.
Non-example	A person-level identifier is joined to an account-level identifier and treated as a one-to-one relationship.
Authority and execution	Authority: Identity authority governs endpoint identity and grain; ontology authority governs relationship compatibility.
Retest	Repeat the endpoint-alignment test under the recorded rule and effective versions. Confirm identity, meaning, grain, and test results support the intended relationship use.

EO-007: Discovery, Inference, or Declaration Method Is Recorded

Prerequisites	Pass required: EO-004.
Specification requirement	Each material relationship shall record the method by which it was declared, discovered, inferred, imported, or derived.
Why this control exists	DACS permits relationship discovery. Stated use requires the method evidence declared by EO-007 to review or reproduce the assertion path where the control applies.
When this applies	When a material relationship was declared, discovered, inferred, imported, derived, or generated by a method that must be reviewable or reproducible.
Evidence to inspect	Method record, input evidence, authority, rule/model/version where applicable, repeatability evidence where applicable.
Evidence sufficiency	The method evidence must identify the process by which each material relationship was declared, discovered, inferred, imported, derived, or generated, including the method owner or authority, input evidence, applicable rule or model version, and repeatability condition where required. Insufficient: Describing the method only as AI, analysis, discovery, or manual review is not sufficient when the reviewer cannot identify the actual method, inputs, authority, or version that produced the relationship assertion.
Assessment procedure	1. Inspect the method record for each material relationship assertion. 2. Verify method or process, owner or authority, input evidence, rule or model version where applicable, and repeatability condition where applicable are recorded.
Control-result determination	Pass: The record includes method name or process, method owner or authority, input evidence, rule/model/version where applicable, and repeatability condition where applicable. Fail: The method name/process, authority, input evidence, required rule/model/version, or required repeatability condition is missing or cannot be retrieved.
Common failure modes	• The assertion method is described only as “AI” or “analysis”. • Input evidence is not retained. • Model or rule version is missing. • Declared relationships have no named authority. • Repeatability condition is undefined.
Remediation procedure	Pattern references: R-01 - Missing evidence; R-12 - Automated or AI-assisted control If the assertion method is described only as AI, analysis, or another vague label: record the specific method or process that produced the relationship assertion If input evidence was not retained: preserve the inputs required to review or reproduce the assertion path If the model or rule version is missing: record the applicable version used to create the assertion If a declared relationship has no named authority: identify the person, role, or approved rule that declared it If the repeatability condition is undefined: state what inputs, versions, rules, or conditions must be held constant when the assertion is replayed or reviewed
Repeatable fix	Each method has a controlled method record and produces traceable assertion evidence.
Controlled disposition	Disposition reference: D-02, Unresolved governed evidence. Use this reference when the method that produced a material relationship cannot yet be reviewed or reproduced from recorded evidence.
Example	A relationship inferred by rules engine v8 records input evidence and the rule that produced it.
Non-example	The team knows AI found the relationship but cannot identify the model version, inputs, or method.
Authority and execution	Authority: Method owner or declaring authority owns the assertion method; ontology authority approves its use for the scope.
Retest	Reinspect the method record for each affected relationship assertion. Confirm the method, owner or authority, input evidence, rule or model version where applicable, and repeatability condition are now recorded.

EO-008: Minimum Relationship Vector Criteria Are Defined

Prerequisites	Pass required: CORE-002, EO-003.
Specification requirement	Before a material relationship vector is evaluated, the decision scope shall define the measurement scale and minimum criteria for Strength, Confidence, and Orientation that govern the stated use. DACS supplies no universal numeric floor.
Why this control exists	A vector only controls use when the decision scope defines what passes.
When this applies	Before a material relationship vector is evaluated for a decision scope that relies on that relationship type or path.
Evidence to inspect	Vector-criteria record, scale definitions, thresholds/rules, authority, version/effective period, decision-scope mapping, reassessment triggers, and creation/effective timestamp.
Evidence sufficiency	The vector-criteria evidence must define the required Strength, Confidence, and Orientation thresholds or approved qualitative rules before the relationship is evaluated at the Gate. Insufficient: Criteria are not sufficient when they are chosen or changed after the relationship result is known, are undocumented, or omit a required vector dimension for the material relationship type or path.
Assessment procedure	1. Inspect criteria for every required vector dimension: Strength, Confidence, and Orientation. 2. Verify scale definitions, threshold or qualitative rule, authority, effective version, scope mapping, and applicable reassessment triggers. 3. Compare criteria creation/effective time with the dependent vector evaluation. 4. If criteria were selected after seeing the result, preserve that finding and assess a new prospective version.
Control-result determination	Pass: The criteria record identifies each vector dimension, measurement or qualitative scale, threshold/rule, authority, version/effective period, decision-scope mapping, and reassessment trigger where applicable, and it was established before the dependent vector evaluation. Fail: Criteria are absent, created after seeing the vector result, borrowed from an unrelated scope, or depend on an unspecified DACS default threshold.
Common failure modes	• Thresholds are chosen after observing results. • Qualitative rules are undocumented. • Criteria exist for Confidence but not Strength or Orientation. • Criteria are not bound to relationship type or decision scope.
Remediation procedure	Pattern references: R-06 - Threshold or rule failure; R-04 - Missing authority If thresholds were selected after reviewers saw the results: define and approve the vector criteria before evaluating the relationship If qualitative criteria are used but not documented: record the qualitative decision rule so another assessor can apply it consistently If criteria exist for only one or two vector dimensions: define the required Strength, Confidence, and Orientation criteria If the criteria are not bound to a relationship type or decision scope: link the criteria to the relationship type or path and the stated decision scope
Repeatable fix	Decision-scope setup requires approved vector criteria by relationship type or path before Gate execution.
Controlled disposition	Disposition reference: D-02, Unresolved governed evidence. Use this reference when minimum relationship-vector criteria were not defined before Gate evaluation.
Example	Before testing, the scope records its own Strength scale and minimum, Confidence threshold, and permitted Orientation, with authority and effective version. These are scope criteria, not DACS default thresholds.
Non-example	Reviewers accept the relationship after seeing the result even though no approved criteria were defined.
Authority and execution	Authority: Decision-scope authority approves the minimum vector criteria before evaluation.
Retest	Verify every required dimension, scale, criterion, authority, version/effective period, scope mapping, and applicable trigger was established before the dependent evaluation. Later corrections belong to a new evaluation.

EO-009: Relationship Vector Is Recorded for Material Relationships

Prerequisites	Pass required: EO-007, EO-008.
Specification requirement	Each material relationship shall carry a relationship vector containing Strength, Confidence, and Orientation.
Why this control exists	The vector makes relationship evaluation testable rather than assumed.
When this applies	When a material relationship is evaluated using the DACS relationship vector of Strength, Confidence, and Orientation.
Evidence to inspect	Relationship vector record, Strength evidence, Confidence evidence, Orientation evidence, decision-scope mapping.
Evidence sufficiency	The relationship-vector evidence must include all three required dimensions, Strength, Confidence, and Orientation, and must identify the measurement method or approval basis used for the decision scope. Insufficient: A single confidence score, generic trust score, or unqualified relationship rating is not sufficient when Strength, Confidence, and Orientation cannot each be inspected and understood.
Assessment procedure	1. Inspect each material relationship vector. 2. Verify Strength, Confidence, and Orientation are all recorded with the measurement method or approval basis used for the decision scope.
Control-result determination	Pass: Strength, Confidence, and Orientation are recorded with measurement method or approval basis for the decision scope. Fail: Any vector component is missing for a material relationship.
Common failure modes	• Only a single confidence score is recorded. • Strength or Orientation is missing. • Vector values have no measurement or approval basis. • Vector is copied between scopes without evaluation.
Remediation procedure	Pattern references: R-01 - Missing evidence; R-06 - Threshold or rule failure If only a single confidence or trust score is recorded: record Strength, Confidence, and Orientation separately If Strength or Orientation is missing: complete the relationship vector with all required dimensions If vector values have no measurement or approval basis: record how each value was measured, derived, or approved If a vector from another decision scope was copied without evaluation: evaluate the relationship vector for the current decision scope
Repeatable fix	Relationship evaluation uses a standard vector record with all three dimensions and their basis.
Controlled disposition	Disposition reference: D-02, Unresolved governed evidence. Use this reference when one or more required relationship-vector dimensions, or their measurement basis, are missing.
Example	Strength 4/5, Confidence 0.92, Orientation dependency are recorded using approved criteria.
Non-example	A relationship has one “trust score” with no orientation and no way to distinguish signal strength from evidence confidence.
Authority and execution	Authority: Relationship authority approves vector method or values; automated scoring may implement approved criteria.
Retest	Reinspect each affected relationship vector. Confirm that Strength, Confidence, and Orientation are all present and that the measurement method or approval basis for each dimension is recorded.

EO-010: Relationship Vector Meets Decision-Scope Criteria

Prerequisites	Pass required: EO-009.
Specification requirement	Each material relationship used for decision evidence for stated use shall meet the decision-scope vector criteria. A constrained-use exception may permit Caution after a failed vector test, but it does not make this control Pass.
Why this control exists	Relationship use must be controlled by evidence, not plausibility.
When this applies	When a material relationship is proposed for stated use and must be compared with the decision-scope vector criteria.
Evidence to inspect	Relationship vector evaluation record, applicable vector criteria, threshold or qualitative-rule results, Gate Record, and exception record where constrained use is authorized after a Fail.
Evidence sufficiency	Evaluation records compare Strength, Confidence, and Orientation with every applicable criterion and preserve the actual control result. Exception evidence is separate and may authorize bounded Caution after a Fail. Insufficient: High confidence, plausibility, or an approved exception does not establish that every vector criterion was met.
Assessment procedure	1. Compare each required vector dimension with the effective decision-scope criterion. 2. Record Pass only when every applicable criterion is satisfied; otherwise record Fail. 3. Separately inspect any exception, its authority and bounds, and the resulting Gate state. The exception does not change this result.
Control-result determination	Pass: The recorded Strength, Confidence, and Orientation evidence satisfies every applicable decision-scope vector criterion. Fail: Any applicable vector criterion fails, is missing, or is not evaluated. An approved constrained-use exception may affect the Gate readiness state but the control remains Fail.
Common failure modes	• A relationship that does not meet the approved vector criteria is still relied on as evidence for stated use. • Exception is verbal. • Only one vector dimension is checked. • Out of date vector evidence is reused after material change.
Remediation procedure	Pattern references: R-06 - Threshold or rule failure; R-10 - Prohibited or out-of-scope use If a relationship does not meet the approved vector criteria but is still relied on as evidence for stated use: remove it from stated use, improve the evidence, or use an authorized bounded exception that produces the appropriate readiness state If an exception exists only verbally: record the exception, authority, limits, and review condition If only one vector dimension was evaluated: evaluate every vector dimension required by the decision-scope criteria If outdated vector evidence is being reused after material change: recalculate or reassess the vector under the current evidence and criteria
Repeatable fix	Vector evaluation is repeatable against versioned criteria and records exceptions separately from Pass.
Controlled disposition	Disposition reference: D-05, Threshold, constraint, or conflict. Use this reference when an applicable vector criterion fails or cannot be established. Any valid constrained-use exception affects Gate permission only; the failed vector result remains visible.
Example	Recorded Strength, Confidence, and Orientation satisfy their respective scope-defined criteria. The vector evaluation records Pass; the applicable Gate separately determines permitted use.
Non-example	A relationship below threshold is marked Pass because a reviewer believes it is probably correct.
Authority and execution	Authority: The responsible relationship or decision-scope authority owns the approved vector criteria and any constrained-use exceptions. A governed manual or automated mechanism may apply the criteria under that authority.
Retest	Reevaluate every applicable vector criterion under its recorded version. Preserve the new Pass or Fail separately from any exception and Gate disposition. An exception alone does not close the failed vector test.

EO-011: Permitted and Prohibited Relationship Paths Are Declared

Prerequisites	Pass required: CORE-002, EO-003.
Specification requirement	Each decision scope shall declare permitted and prohibited relationship paths when relationship traversal affects the decision.
Why this control exists	Path control prevents unauthorized semantic traversal.
When this applies	When relationship traversal can change the meaning, evidence path, or outcome of the stated decision scope.
Evidence to inspect	Permitted/prohibited path record, traversal rule, constraint record, decision-scope mapping.
Evidence sufficiency	The path evidence must state which material relationship paths are permitted, which are prohibited, and any traversal limits or path constraints that govern how the decision path may use them. Insufficient: Technical ability to traverse a graph, join, lineage path, or association is not sufficient authorization to use that path when the decision scope has not approved the traversal.
Assessment procedure	1. Trace the material decision path and identify relationship traversals that can affect the result. 2. Verify permitted paths, prohibited paths, path constraints, and traversal limits are recorded before use.
Control-result determination	Pass: Permitted paths, prohibited paths, path constraints, and traversal limits are recorded. Fail: A decision path uses relationship traversal without approved path rules.
Common failure modes	• Graph or join traversal follows any technically available path. • Prohibited paths are implicit. • Traversal depth or path constraints are absent. • An approved path in one scope is reused in another without review.
Remediation procedure	Pattern references: R-10 - Prohibited or out-of-scope use; R-02 - Ambiguous meaning If traversal follows any technically available path: declare the permitted relationship paths for the stated decision scope If prohibited paths are only implicit: record the prohibited paths explicitly If traversal depth, direction, or other path limits are missing: define the required path constraints before use If a path approved in another decision scope is reused without review: evaluate and approve the path for the current scope
Repeatable fix	Traversal rules are stored as governed path policies and checked manually or automatically before use.
Controlled disposition	Disposition reference: D-02, Unresolved governed evidence. Use this reference when material relationship traversal lacks approved permitted, prohibited, or constrained path rules.
Example	Account -> Contract -> Status is permitted; Account -> Prospect -> Credit Action is prohibited for the scope.
Non-example	An analytics query traverses any available graph edge because the graph technically allows it.
Authority and execution	Authority: Decision-scope owner and ontology authority approve permitted and prohibited traversal paths.
Retest	Retrace the affected relationship path. Confirm that every material traversal follows an approved permitted path, avoids prohibited paths, and respects the recorded traversal limits and constraints.

EO-012: Relationship Conflict and Jurisdiction Resolution Rule Exists Where Applicable

Prerequisites	Pass required: EO-011. Recorded result required: ET-013.
Specification requirement	When competing relationship assertions, jurisdictions, policies, or authorities can produce mutually exclusive relationship use, a recorded conflict-resolution or jurisdictional precedence rule shall exist before material reliance.
Why this control exists	Conflicting relationship evidence cannot support Defensible Analytics without disposition.
When this applies	When two or more material relationship assertions conflict for the same decision scope.
Evidence to inspect	Precedence/adjudication rule, applicable jurisdictional authorities, scope, version/effective period, tie-break/escalation behavior, and permitted/prohibited path. Include conflict and resolution records when an actual conflict exists.
Evidence sufficiency	Each applicable conflict class has a recorded rule with authority, scope, effective version, tie-break or escalation behavior, and permitted/prohibited path. Every actual conflict affecting material reliance is resolved under the rule or by a recorded competent-authority decision before use. Insufficient: An unresolved conflict held under Stop or Quarantined is correctly contained but does not establish Pass for conflict resolution. Escalation, informal selection, or an exception without competent resolution is not proof of resolution.
Assessment procedure	1. Identify applicable conflict classes and retrieve their precedence or adjudication rules. 2. Verify authority, scope, effective version, tie-break/escalation behavior, and permitted/prohibited path. 3. Trace each actual conflict affecting reliance to a resolution under that rule or a recorded competent-authority decision. 4. Record Fail for an unresolved conflict; inspect containment and any separately authorized Gate state without treating them as resolution.
Control-result determination	Pass: Each applicable conflict class has a recorded precedence/adjudication rule with authority, scope, version/effective period, tie-break or escalation behavior, and permitted/prohibited path. Each actual conflict affecting material reliance is resolved under that rule before use. A recorded competent-authority decision may resolve the conflict for the bounded scope. Fail: A conflict is unresolved, precedence is invented during assessment, or a relationship proceeds despite mutually exclusive authoritative constraints.
Common failure modes	• Conflicting relationships are averaged, ignored, or selected case by case without an approved rule. • Source precedence is not governed. • Human resolution is not recorded. • Both conflicting assertions remain usable without disposition.
Remediation procedure	Pattern references: R-05 - Conflicting evidence; R-11 - Human adjudication If conflicting relationships are averaged, ignored, or selected case by case: apply an approved conflict-resolution or adjudication rule If source precedence is not governed: define and approve the source-precedence rule for the conflict class If human resolution is not recorded: convert the adjudication into a governed decision, mapping, rule, or exception record If both conflicting assertions remain usable without disposition: assign the appropriate disposition to the conflicting evidence until the conflict is resolved
Repeatable fix	Known conflict classes have versioned precedence, adjudication, or escalation rules and preserve the losing evidence for audit.
Controlled disposition	Disposition reference: D-05, Threshold, constraint, or conflict. Unresolved jurisdictional or authoritative conflict is Fail and normally Stop; do not invent precedence during assessment.
Example	CRM and Billing disagree on account ownership; the approved authority rule selects Billing for this scope and records the conflict.
Non-example	The pipeline silently chooses whichever source arrives last.
Authority and execution	Authority: Relationship or decision authority owns conflict-resolution precedence, adjudication, and exception decisions.
Retest	Reinspect the governing rule and the recorded resolution of every actual conflict affecting material reliance. Verify competent authority and bounded scope. Stop or Quarantined containment alone does not satisfy the resolution test.

EO-013: Relationship Constraints Are Applied

Prerequisites	Pass required: EO-011. Recorded result required: EO-012.
Specification requirement	Each material relationship path shall apply the recorded governance, usage, jurisdictional, and conflict-resolution constraints that govern the stated decision scope.
Why this control exists	A relationship may be valid in one context and invalid in another.
When this applies	When a material relationship is subject to domain, time, authority, source, privacy, policy, regulatory, contractual, risk, purpose, or similar constraints.
Evidence to inspect	Relationship path, applicable constraint/policy records, jurisdiction/precedence rule, evaluation evidence, exception/resolution record where applicable, and Gate Record.
Evidence sufficiency	The constraint evidence must identify every material domain, time, authority, source, privacy, policy, regulatory, contractual, risk, purpose, or similar constraint and show that the applicable constraints were evaluated for the relationship use. Insufficient: Documenting a constraint is not sufficient when the decision path does not actually apply it at the point where the relationship is used.
Assessment procedure	1. Inspect material relationships against required domain, time, authority, source, privacy, policy, regulatory, contractual, risk, and purpose constraints. 2. Verify applicable constraints were actually evaluated, not merely documented.
Control-result determination	Pass: Every applicable constraint and resolved precedence rule is evaluated before reliance, prohibited paths are blocked, bounded exceptions are explicit, and unresolved authoritative conflict results in a failed control and a Stop Gate state unless competent authority has recorded a valid bounded resolution. Fail: A constraint is ignored, a prohibited path is used, or unresolved jurisdictional conflict is allowed to proceed.
Common failure modes	• Constraints are documented but not evaluated at use time. • Time validity is ignored. • Source or authority restrictions are lost during traversal. • Privacy, policy, contractual, or purpose constraints do not propagate with the relationship.
Remediation procedure	Pattern references: R-10 - Prohibited or out-of-scope use; R-06 - Threshold or rule failure If relationship constraints are documented but not evaluated when the relationship is used: apply the relevant constraints at the Gate or other controlled point of use If time validity is ignored: evaluate the relationship against its effective period before use If source or authority restrictions are lost during traversal: preserve and evaluate those restrictions throughout the relationship path If privacy, policy, contractual, risk, or purpose constraints do not propagate with the relationship: attach and enforce the applicable constraints wherever the material relationship is used
Repeatable fix	Constraints are attached to governed relationship types or paths and evaluated at the Gate.
Controlled disposition	Disposition reference: D-05, Threshold, constraint, or conflict. Use this reference when a required relationship constraint has not been applied to the material use.
Example	A relationship may be used only for records effective during the contract period and from approved sources.
Non-example	A valid relationship is used outside its effective period because the join still works.
Authority and execution	Authority: Relationship steward applies constraints; relevant policy, privacy, risk, contractual, or domain authorities own their constraint rules.
Retest	Reevaluate the affected relationship against all applicable constraints. Confirm that required domain, time, authority, source, privacy, policy, regulatory, contractual, risk, and purpose constraints are actually applied at use time.

EO-014: Cross-Domain Semantic Compatibility Is Declared Where Applicable

Prerequisites	Pass required: EO-006.
Specification requirement	When a relationship crosses domains, functions, systems, or stewardship authorities, semantic compatibility shall be declared before stated use.
Why this control exists	Cross-domain use requires more than local application meaning.
When this applies	When a material relationship crosses business domains, functions, systems, or stewardship authorities.
Evidence to inspect	Semantic domain references, boundary rules, compatibility record, grain rule, authority/stewardship record, decision-scope mapping.
Evidence sufficiency	The cross-domain compatibility evidence must show the semantic domains and boundaries on both sides of the relationship, compatible grain, material overlap or disjointness rules, and the responsible cross-domain authority or stewardship process. Insufficient: Similar names, shared identifiers, or a technically valid connection are not sufficient when the two domains use different meanings or grains and no governed compatibility decision has been recorded.
Assessment procedure	1. Identify each material relationship that crosses business domains, functions, systems, or stewardship authorities. 2. Verify the semantic domain and boundary on both sides of the relationship. 3. Verify compatible grain, material overlap or disjointness rules, and the responsible cross-domain authority or stewardship process before stated use.
Control-result determination	Pass: Cross-domain relationships reference semantic domains, boundary rules, compatible grain, disjointness or overlap rules where material, and authority or stewardship process. Fail: Cross-domain relationships are relied on for stated use without compatibility evidence.
Common failure modes	• Cross-domain terms look similar but have different meanings or grain. • Stewardship boundaries are unclear. • Overlap or disjointness is assumed. • One domain imposes its local relationship semantics on another without agreement.
Remediation procedure	Pattern references: R-02 - Ambiguous meaning; R-05 - Conflicting evidence; R-04 - Missing authority If cross-domain terms look similar but have different meanings or grains: reconcile the meanings and grains before treating the relationship as compatible If stewardship boundaries are unclear: identify the accountable authorities in each domain and the joint decision process If overlap or disjointness is assumed: record the approved overlap, disjointness, or boundary rule If one domain imposes its local relationship semantics on another without agreement: obtain explicit cross-domain agreement on the relationship meaning and permitted use
Repeatable fix	Cross-domain relationships require a compatibility record and accountable cross-domain review.
Controlled disposition	Disposition reference: D-02, Unresolved governed evidence. Use this reference when cross-domain semantic compatibility has not yet been established for the material relationship.
Example	Sales Account and Finance Customer are linked only after their different grains and boundary rules are reconciled for the scope.
Non-example	A relationship crosses domains because both sides use the word “customer,” with no compatibility evidence.
Authority and execution	Authority: Relevant domain stewards or authorities jointly establish compatibility; decision-scope owner approves use.
Retest	Reinspect each affected cross-domain relationship. Confirm that domain boundaries, compatible grain, material overlap or disjointness rules, and cross-domain authority or stewardship are now recorded and approved.

EO-015: Traversal Path Is Determinate Where Used

Prerequisites	Pass required: EO-011. Recorded result required: EO-006, EO-013, EO-014.
Specification requirement	A relationship traversal used as decision evidence shall return the same path result, or the same unresolved or exception result, when the inputs, rule set, threshold where used, version, and decision scope are unchanged.
Why this control exists	Decision-path reconstruction requires repeatable relationship traversal.
When this applies	When a relationship traversal path is relied on as decision evidence for stated use and repeated execution must yield a determinate path or governed unresolved outcome.
Evidence to inspect	Traversal rule and version, tested inputs, thresholds where used, path records, repeat-test results, scope reference, and exception record where applicable.
Evidence sufficiency	Repeat-test records hold inputs, rules, thresholds where used, versions, and scope unchanged and return the same path or the same governed unresolved or exception result. Insufficient: An explanation for different outcomes under unchanged conditions does not establish Pass. A consistently unresolved path does not establish permission for relationship use.
Assessment procedure	1. Replay the same material traversal with the same inputs, rule set, version, and decision scope. 2. Verify repeated runs return the same path or the same unresolved or exception result, and investigate unexplained differences.
Control-result determination	Pass: Repeat tests using the same recorded inputs, rules, thresholds where used, versions, and scope return the same path result or the same unresolved or exception result. A repeatable unresolved result does not establish permission to use the relationship. Fail: Any different traversal outcome under the same inputs, rule set, threshold, version, and decision scope is Fail. A recorded explanation does not convert that failed determinism test into Pass; a changed rule, threshold, version, or scope is a different test case.
Common failure modes	• Traversal order is nondeterministic. • Eligible paths are selected differently under unchanged conditions. • Tie-breakers or required thresholds are unrecorded. • Graph or rule version is not captured. • An unresolved path is silently replaced with another path.
Remediation procedure	Pattern references: R-06 - Threshold or rule failure; R-11 - Human adjudication If traversal order is nondeterministic: define the ordering rule required to produce a repeatable path result If equivalent eligible paths are selected differently across runs: define the approved path-priority or tie-break rule If tie-break logic is missing: add and govern the tie-break condition If the graph, rule, or traversal version is not captured: record the version used for the assessed traversal If an unresolved path is silently replaced with another path: preserve a governed unresolved or exception outcome instead of substituting an unapproved path
Repeatable fix	Traversal execution records rule/version and uses deterministic selection or governed unresolved outcomes.
Controlled disposition	Disposition reference: D-06, Determinacy or repeatability. Use this reference while traversal does not reproduce the same path, or the same governed unresolved or exception result, under the same governed conditions.
Example	Two equivalent paths are resolved by a documented priority rule, producing the same path on replay.
Non-example	A graph search returns different eligible paths while the recorded inputs, rules, thresholds, versions, and scope are unchanged. A later explanation does not make that test Pass.
Authority and execution	Authority: Traversal-rule owner governs deterministic path selection; ontology authority approves the rule for the scope. Execution: Traversal execution must preserve the input, rule or graph version, ordering or tie-break logic, and result needed for replay.
Retest	Repeat traversal with unchanged recorded inputs, rules, thresholds where used, versions, and scope. Compare outcomes, including unresolved or exception results. A changed configuration is a new test case; repeatability alone does not permit relationship use.

EO-016: Relationship Readiness State Is Declared

Prerequisites	Recorded result required: EO-010, EO-013, EO-015.
Specification requirement	Each material relationship shall have a readiness state for the stated decision scope.
Why this control exists	Relationship evidence requires a decision-scope disposition.
When this applies	When a material relationship is used in the decision path and therefore requires a scope-bound readiness disposition.
Evidence to inspect	Relationship readiness record, Gate Record, reason, responsible authority or approved rule reference, timestamp, review condition.
Evidence sufficiency	The relationship-readiness evidence must show the formal readiness state assigned to the material relationship for the stated decision scope and the supporting reason, authority or rule, timestamp, and review condition where required. Insufficient: Existence in an ontology, graph, catalog, or governed repository is not sufficient to establish that the relationship is in Proceed for the decision scope being assessed.
Assessment procedure	1. Inspect each material relationship used by the decision scope. 2. Verify the readiness state is supported by Gate evidence, reason, authority or rule, timestamp, and review condition where required.
Control-result determination	Pass: The relationship is assigned Proceed, Caution, Stop, or Quarantined with reason, responsible authority or approved rule reference, timestamp, and review condition where required. Fail: A material relationship is used without a readiness state or the state is unsupported by evidence.
Common failure modes	• Relationship readiness is inferred from relationship existence. • State has no supporting Gate evidence. • Caution constraints are not recorded. • Readiness is out of date after relationship or scope change.
Remediation procedure	Pattern references: R-01 - Missing evidence; R-08 - Material change or drift If relationship readiness is inferred from the relationship merely existing: evaluate the relationship through the applicable Gate and assign the resulting readiness state If the readiness state has no supporting Gate evidence: produce or link the Gate evidence that supports the state If Caution is used without recording its constraints: record the bounded-use conditions, authority, and review condition If the readiness state is outdated after relationship or scope change: reassess the affected relationship and issue a current state
Repeatable fix	Relationship readiness is a scope-bound governed record updated through Gate execution.
Controlled disposition	Disposition reference: D-02, Unresolved governed evidence. Use this reference when a material relationship lacks a supported readiness state for the decision scope.
Example	A newly imported relationship remains Quarantined until provenance and vector controls are complete.
Non-example	A relationship is labeled Proceed simply because it exists in the ontology repository.
Authority and execution	Authority: The responsible decision-scope authority approves relationship readiness based on Gate evidence. An approved rule may execute or record the evaluation; the ontology steward remains accountable for the underlying relationship evidence.
Retest	Reinspect the readiness record for each affected material relationship. Confirm that the formal readiness state is supported by Gate evidence, reason, authority or rule, timestamp, and review condition where required.

EO-017: Ontology Change Triggers Forward Reassessment

Prerequisites	Pass required: CORE-023. Recorded result required: EO-016.
Specification requirement	Each material Extended Ontology change shall trigger impact assessment for active or prospective decision scopes that rely on the changed relationship artifact. Historical Gate and Conformance Records remain fixed to the ontology version that governed them.
Why this control exists	Relationship rules can invalidate decision paths previously allowed for stated use.
When this applies	When a material relationship type, orientation, path, vector criterion, constraint, provenance rule, or permitted/prohibited traversal rule changes.
Evidence to inspect	Ontology change/version record, impact rule, affected-scope list, readiness invalidation/reassessment record, replacement Gate/Conformance Record where required, and immutable historical references.
Evidence sufficiency	A material ontology change is versioned, affected active or prospective scopes are identified, and required invalidation or reassessment precedes new reliance. Replacement Gate or Conformance Records link to unchanged historical records. Insufficient: A version log alone does not establish impact handling when affected future use continues without required reassessment.
Assessment procedure	1. Inspect ontology change rules and a recent or test change to type, orientation, path, vector criteria, constraint, provenance, or path rules. 2. Verify affected scopes receive impact analysis, Gate reassessment, and Conformance Record update.
Control-result determination	Pass: A material ontology change is versioned, affected active/prospective scopes are identified, prior readiness for new reliance is invalidated or reassessed as defined, and any replacement Gate/Conformance Record is linked to the prior record without rewriting it. Fail: Future reliance continues under a materially changed ontology without reassessment, or historical records are retroactively recalculated or overwritten merely because the ontology changed.
Common failure modes	• Relationship type or orientation changes without scope impact analysis. • Path-rule changes do not invalidate prior readiness or conformance determination. • Vector criteria change without reassessment. • Ontology version changes are recorded but not operationalized.
Remediation procedure	Apply forward-only impact assessment. Reassess affected active/prospective use; do not retroactively recalculate completed historical decisions solely because ontology changed.
Repeatable fix	Ontology version changes produce a repeatable affected-scope review and conformance-status update.
Controlled disposition	Disposition reference: D-04, Change or reassessment. Use this reference after a material ontology change until affected decision scopes have been identified and reassessed.
Example	Changing a relationship from permitted to prohibited triggers reassessment of every path that traverses it.
Non-example	A relationship type is redefined but existing decisions previously allowed for stated use continue under the old meaning without review.
Authority and execution	Authority: Ontology owner governs the change; affected decision-scope owners authorize reassessment and Conformance Record updates. Execution: A material ontology change must identify affected decision scopes and route them to impact review and Gate reassessment.
Retest	Apply or inspect a representative material ontology change. Confirm that affected decision scopes are identified and the required impact analysis, Gate reassessment, and linked replacement Conformance Records are created.