Part I - Semantic Integration Engineering Methods

SIE.1 - Bound the Receiving Use and Semantic Contract

Type: Method pattern Status: Eternal alpha Normativity: Normative method guidance within SIE; examples are constructed and non-normative.

Primary working result: a SemanticIntegrationUseContract@Use that names one receiver and use, required answer claims, source cut, tolerated loss and uncertainty, currentness, latency, quality, authority, representative tests, stop conditions, and reopen conditions.

SIE.1:1 - Problem Frame

Use this when a request says “integrate the data”, “align the models”, “build the knowledge graph”, or “make one source of truth”, but the intended receiver and decision-changing answer are not yet explicit. The recognizable failure is a technically impressive integration whose values cannot be interpreted, trusted, or used safely by the Work that requested it.

The primary EntityOfConcern is one semantic-integration use: a named receiver performing a named query, decision, operation, or engineering workflow under stated conditions. The first move is to state that use and the answer claims it needs. The first result is a bounded contract that lets later workers decide which semantic loss, source age, unresolved row, and test outcome are acceptable.

The practical gain is a testable stopping rule before source, ontology, mapping, or platform choices accumulate. Do not use this pattern to authorize the receiving decision, decide product configuration, choose master identity, operate a data pipeline, or define generic evidence law. Obtain those results from their owners. Do not reopen a current contract merely because another source exists; reopen it when the receiver, use, answer, conditions, authority, or acceptance boundary changes.

SIE.1:2 - Problem

Without a receiving-use contract, “semantic integration” expands toward every source and every possible reuse. Similar labels are merged without a loss budget, freshness is treated as an implementation detail, and a passing schema or sample query is reported as success. The project cannot distinguish an informative unmatched row from a defect, or a harmless delay from a stale answer that changes action.

Technology then supplies the hidden contract. A graph platform encourages graph-shaped outputs, a warehouse encourages copying, and an API encourages whichever fields are easiest to expose. None says which answer claims the receiver may rely on, who owns them, or when the correct result is to stop.

SIE.1:3 - Forces

SIE.1:4 - Solution

Construct the smallest semantic contract that can change the named receiving action. Begin from the receiver and work backward to required answer claims, source contexts, meanings, losses, currentness, quality, authority, representative cases, and exact stops. Treat the contract as an input to later SIE patterns, not as proof that any source, correspondence, identity, mapping, interface, or implementation exists.

SIE.1:4.1 - Pattern-Use Unfolding

1. Name the receiver and receiving Work. Identify the System or role that will use the result, the query, decision, operation, or workflow, the horizon, and the first useful answer.
2. State the answer claims. Write the fields or propositions the receiver needs, including scope, grain, interval or effectivity, and the action each claim can change. Keep a value, its provenance, its authority, and the receiver’s decision distinct.
3. Select the source cut. Name only the governed contexts and candidate source assets that can change the answer. Mark sources whose inclusion is uncertain rather than adding them silently.
4. State preserved distinctions and tolerated loss. Name identities, versions, units, codes, relations, claim scopes, and incompatibilities that must survive. For each permitted coarsening or omission, state why the receiver can tolerate it.
5. State currentness, latency, availability, and quality conditions. Choose thresholds or explicit unresolved returns only where they change use. Do not copy every available quality dimension into the contract.
6. Recover authority, permission, and protection boundaries. Name who defines source meanings, who may grant access, who decides identities or authoritative values, who accepts semantic loss, and who owns the receiving action. Record an exact blocker where a required relation is absent.
7. Design representative tests before implementation. Include at least one expected positive case, one negative or unmatched case, and one unlike or changed-source case that could defeat the proposed integration. Name the expected branch rather than requiring every test to return a value.
8. State pass, narrow, unresolved, and stop outcomes. A contract permits a bounded usable subset or explicit incompatibility when that is useful. Stop when a load-bearing meaning, source edition, identity authority, permission, or acceptance rule is unavailable.
9. State reopen conditions and next result. Identify observations that change the contract and the smallest next result, often SourceSemanticInventory@Use from SIE.2.

SIE.1:4.2 - Record the Result

SIE.1:4.3 - What Changes in Practice

The team stops treating integration scope as the set of reachable sources. Every later correspondence, identity disposition, mapping rule, realization, interface field, and validation claim must answer to a named receiving use and loss boundary. Explicitly unmatched or incompatible results become valid outcomes rather than defects to hide.

SIE.1:5 - Archetypal Grounding - AP242/QIF Configuration Query

A quality engineer asks which QIF inspection plan and result concern feature F in released AP242 product-definition revision/configuration R at effectivity E. The initial request is “connect PLM and quality data in a knowledge graph.” SIE.1 replaces the carrier proposal with this contract:

This result does not claim that the two source models correspond or that an interface works. It makes those later claims testable. AP242 edition 4 is recorded by SIE.2 with its current source status; SIE.1 only requires the edition and reopen rule to be explicit.

SIE.1:6 - Bias-Annotation

SIE.1:7 - Conformance Checklist

• One named receiver and receiving Work are explicit.
• The first useful answer is expressed as claims or fields with grain, scope, and interval/effectivity.
• The source cut is justified by the use rather than by reachability.
• Preserved distinctions, permitted loss, uncertainty, and unmatched/incompatible behavior are explicit.
• Currentness, latency, availability, recovery, and quality are included only where action-changing.
• Meaning, identity/value, access, semantic-loss, and receiving-action authorities remain distinct.
• Positive, negative, and unlike or changed-source tests have expected branches.
• Pass, narrow, unresolved, stop, next-result, and reopen rules are stated.
• The contract claims no correspondence, implementation, validation, authorization, or outcome that has not been obtained.

SIE.1:8 - Common Anti-Patterns and How to Avoid Them

SIE.1:9 - Consequences

The contract limits source fan-out, makes semantic loss and authority visible, and gives implementation and validation a shared target. It can stop an integration before expensive model or platform work. It also makes conflicts and narrow usable subsets publishable outcomes.

The cost is early negotiation about the receiver, evidence, loss, and stop conditions. Some attractive future reuse remains outside the first package and must earn its own contract or compatible extension.

SIE.1:10 - Rationale

Semantic adequacy is relative to a use, but relativity does not make it arbitrary. A receiver, answer claim, source context, permitted loss, authority, and representative test together constrain what counts as a successful integration. Beginning there prevents a carrier choice from becoming an implicit ontology, authority model, and acceptance rule.

SIE.1:11 - SoTA-Echoing

The best-known line for this question combines use-bounded representation selection, situational Method criteria, quality-for-use, and explicit source/provenance practice. The serious default alternative is technology- or source-led integration. Its defect is not the use of a graph, warehouse, or federation; it is allowing that choice to define the answer and loss boundary. SIE.1 mutates the line by making the whole semantic contract, including authorities and legitimate unresolved branches, the first domain result.

Reopen this pattern when representative uses cannot express action-changing loss, authority, or validation obligations through the contract positions, or when a source line supplies a materially better first result.

SIE.1:12 - Relations

• SIE.2 consumes the source cut, answer claims, distinctions, and currentness questions to produce SourceSemanticInventory@Use.
• SIE.4–SIE.10 consume the compatible contract positions relevant to their results; none may silently widen the receiver or accepted loss.
• C.37 governs generic use-bounded representation selection. A.10 and A.10.1 govern evidence/provenance and generic affected-use questions.
• Applications, Systems Engineering, Operations, quality, safety, legal, and other direct owners supply their acceptance and authority results.
• A changed contract reopens the package branches that rely on the changed premise. SIE.11 supplies affected-use discovery and integration revalidation where the affected results still need to be established.

SIE.1:End

SIE.2 - Recover and Qualify Source Semantics and Authority

Type: Method pattern Status: Eternal alpha Normativity: Normative method guidance within SIE; examples are constructed and non-normative.

Primary working result: a SourceSemanticInventory@Use that records the load-bearing source assets, local meanings, schemes, editions and effectivity, identifiers, claims, owners and authority scope, provenance, access, currentness, gaps, and exact returns for one semantic-integration use.

SIE.2:1 - Problem Frame

Use this when a bounded integration use exists, yet endpoint meanings are being inferred from labels, column names, class names, diagrams, sample values, or undocumented organizational knowledge. The recognizable failure is a mapping that runs while joining different concepts, editions, grains, or authority scopes.

The primary EntityOfConcern is the set of source-local semantic premises that the receiving use actually consumes. The first move is to select one load-bearing source asset and recover its scheme, edition or effectivity, meaning, owner, authority, provenance, and access conditions. The first result is an inventory that makes both usable premises and exact gaps inspectable.

The payoff is a clean separation between what a source says, what an integrator infers, and what another owner must decide. Do not use SIE.2 to construct an ontology, establish a cross-source correspondence, decide identity, fuse claims, or judge receiving-use adequacy. If model adequacy for a required distinction remains unsettled, request UseFitSemanticModel@Use from SIE.3 or another qualified direct provider. Adequate reuse can finish that question; an actual missing distinction may require extension or construction.

SIE.2:2 - Problem

Source inventories often list files and endpoints but omit the meanings that make their values usable. A table called feature, an API field called available, and an identifier called partNumber appear self-describing. Their actual senses may depend on an edition, profile, configuration, interval, issuer, lifecycle state, organizational rule, or local extension.

When those dependencies are hidden, later workers can neither justify a correspondence nor trace a failure. A changed source looks like a schema defect even when the meaning changed; an access right is mistaken for authority; and a provenance record is mistaken for truth.

SIE.2:3 - Forces

SIE.2:4 - Solution

Recover source semantics at the smallest grain that can change the receiving answer. Preserve term, concept, type, relation, schema, model, claim, data item, carrier, identifier, and world-side referent as different questions. Qualify each relied-on premise by source identity, edition/effectivity, authority scope, provenance, access, currentness, and known gaps.

SIE.2:4.1 - Pattern-Use Unfolding

1. Take the source cut from the use contract. Add another source only when it can change an answer claim, test, loss, or stop condition.
2. Identify the source asset and carrier. Record publisher or owning System, title or endpoint, profile/module, version or edition, publication and effectivity, retrieval location, and carrier kind. Keep the asset distinct from the concepts and claims it carries.
3. Recover the local scheme and scope. State the domain, population, lifecycle state, configuration, jurisdiction, or Work context in which the source definitions apply.
4. Recover exact meanings. For every load-bearing endpoint, record the designation, definition or operative rule, type/relation role, examples and counterexamples, units or codes, and unresolved ambiguity. Use source-local language before normalizing it.
5. Separate identifiers and identified entities. Record the scheme, issuer or owner, syntax, resolution behavior where relevant, use restrictions, grain, interval, and what the identifier does not establish.
6. Separate claims, data, and provenance. Record which claim a data item represents, its scope and time, how it was derived, who or what supplied it, and which uncertainty or status accompanies it. Provenance does not make the claim true.
7. Recover authority and access. Name who may define the scheme, issue identifiers, decide authoritative values, approve local extensions, grant access, and authorize receiving use. Mark unsupported assumptions.
8. Assess currentness and use adequacy. Compare the source premise with the contract. State whether it is adequate, adequate only under conditions, unresolved, obsolete for this use, inaccessible, or missing.
9. Return an inadequate model honestly. If the required distinction cannot be expressed in the available source or supplied semantic model, request UseFitSemanticModel@Use; do not hide the gap in a mapping rule.
10. Record dependencies and next results. Identify the exact definitions, editions, authority facts, and gaps consumed by SIE.4–SIE.10, plus observations that reopen this inventory.

SIE.2:4.2 - Record the Result

SIE.2:4.3 - What Changes in Practice

The team stops mapping from field names. A later correspondence or transformation can point to exact source-local endpoints and editions, and a failure can return to the owner of the missing meaning, authority, access, or model. An inventory row can be useful even when its disposition is unresolved or inaccessible.

SIE.2:5 - Archetypal Grounding - AP242 and QIF Source Cut

For the AP242/QIF query in SIE.1, the team inventories only source premises that can change the configuration-bound answer.

The inventory marks an unresolved local AP242 extension used by one feature class. Because its meaning can change the correspondence, the package stops that row and returns to the extension owner. Other rows can continue. If neither AP242 nor QIF can express a required tolerance-state distinction, the inventory requests a qualified UseFitSemanticModel@Use; it does not invent the distinction in the transform.

SIE.2:6 - Bias-Annotation

SIE.2:7 - Conformance Checklist

• Every included source can change a named contract position.
• Source asset, carrier, local scheme, semantic endpoint, identifier, claim, data item, and referent remain distinguishable.
• Edition, profile/module, effectivity/configuration/interval, and local extensions are explicit where load-bearing.
• Definitions or operative rules include scope and at least one discriminating example or counterexample where ambiguity matters.
• Identifier scheme, issuer/owner, grain, interval, restrictions, and resolution assumptions are explicit.
• Claims retain provenance, scope, time, status, and uncertainty without treating provenance as truth.
• Meaning, identifier, authoritative-value, extension, access, and receiving-use authorities remain separate.
• Every row has an adequate, conditional, unresolved, obsolete, inaccessible, missing, or model-gap disposition.
• Consuming rows and reopen conditions are recoverable.

SIE.2:8 - Common Anti-Patterns and How to Avoid Them

SIE.2:9 - Consequences

Mappings become reviewable against exact endpoints, and source changes can be traced to the rows that relied on them. Authority, access, and model gaps appear before implementation. The same inventory can support several direct pattern entries while each use retains its own qualification.

The cost is source-local reading and coordination with publishers, stewards, domain specialists, and access owners. Some attractive automation must wait because the source meaning or applicability is unresolved.

SIE.2:10 - Rationale

Semantic integration cannot preserve a meaning that has not been recovered at the source. Source-local recovery also prevents a shared vocabulary from becoming a hidden replacement for source authority. Qualification by use keeps the inventory finite and prevents documentation breadth from substituting for a workable package.

SIE.2:11 - SoTA-Echoing

The best-known line combines terminology work, metadata-registry discipline, provenance, and source-local meaning recovery. The serious default is schema inspection plus organizational folklore. Its defect is not informality alone; it leaves no stable relation among the source claim, edition, authority, and mapping premise. SIE.2 adapts the line into a use-qualified manifest with an explicit inadequate-model return.

Reopen when a source change alters a relied-on meaning, scheme, edition, effectivity, authority, access condition, or provenance chain, or when repeated cases show that an inventory position cannot support the downstream decision.

SIE.2:12 - Relations

• SIE.1 supplies the receiving use, source cut, answer claims, preserved distinctions, and stop conditions.
• SIE.3 qualifies an available model for the named use or develops an actual missing distinction. Request that result when the recovered source model leaves the integration’s model question unsettled.
• SIE.4, SIE.5, and SIE.6 consume exact endpoint meanings, source claims, identifiers, editions, and authority limits.
• SIE.7–SIE.10 consume the manifest, provenance, currentness, and gap dispositions relevant to implementation and validation.
• Domain sources, MDM, access owners, Systems Engineering, Data Engineering, and applications retain their respective meanings, values, permissions, operational results, and decisions.

SIE.2:End

SIE.3 - Construct or Reuse a Semantic Model for a Named Use

Type: Method pattern Status: Eternal alpha Normativity: Normative method guidance within SIE; examples are constructed and non-normative.

Primary working result: a UseFitSemanticModel@Use: a reused, extended, or constructed semantic model qualified for the questions and distinctions that its receiving use requires.

SIE.3:1 - Problem Frame

Use this when an integration needs to express a meaning or answer a question and the adequacy of its available models is unsettled. For example, a source describes an inspection requirement, while the receiving query needs to distinguish that requirement from an observation of a particular configured feature.

Start with one question the model must help answer and examples of answers that would count as different. Ask the domain participants to explain those distinctions before choosing an encoding. The first useful result can be confirmation that an existing model is sufficient, with its applicable edition and use conditions.

The object is the semantic model for that use: its concepts, relation meanings, constraints, and relevant commitments. The practical gain is a model whose distinctions can guide correspondence and mapping work. A stronger claim, such as adequacy for additional questions or valid inference in a formal language, needs evidence for those additional conditions.

If the supplied model is already qualified for the unchanged use, reuse that result. If the only open question is a correspondence between adequately understood source meanings, use SIE.4. A new integration endpoint alone does not create a model-construction requirement.

SIE.3:2 - Problem

Available models often look adequate because their terms resemble the receiving question. A field named inspection may cover a plan, a requirement, an occurrence, or a result. Mapping every such field to one class can remove exactly the distinction the receiver needs.

The opposite failure is to construct a larger ontology whenever a model question arises. That incurs design and maintenance work even when an existing model can answer the question. Both failures begin before formalization: the required meaning and its useful boundary have not been established.

SIE.3:3 - Forces

SIE.3:4 - Solution

Select or develop only the semantic content needed for the named use. Qualify it through discriminating cases and make its maintained edition accessible to the consumers who will rely on it.

SIE.3:4.1 - Pattern-Use Unfolding

1. State the questions and answer distinctions. Use competency questions or an equivalent plain description. Name the subject, grain, configuration or interval where relevant, expected answer, and a counterexample. Work with domain participants at a level where they can explain the distinction. Separate a useful model question from a request to choose a storage or diagramming tool.
2. Recover the available meanings. Use the relevant SIE.2 results or directly supplied source meanings. Inspect candidate models’ definitions, relations, constraints, examples, edition, access, and maintenance conditions where those can affect the use. Source labels alone cannot settle suitability.
3. Try sufficient reuse. Replay the required questions and counterexamples against an available model. When its content and applicable conditions suffice, return that model and the qualification. This completes the Method. Leave an uncovered question explicit if a permitted narrower use can continue.
4. Locate the actual gap. Identify the missing distinction, relation, constraint, or incompatible commitment. Extend a module when the addition can preserve the existing commitments that consumers still use. Construct a different model when reuse or such an extension cannot supply the required content. Keep the reason tied to the gap.
5. Develop the meaning before encoding it. Define the needed concepts and relations, their domains of application, and the grain or temporal interpretation required by the question. Show examples and counterexamples to domain participants. Preserve a source disagreement that affects use; SIE.4 can establish a qualified correspondence between different meanings.
6. Choose sufficient formalization. A maintained vocabulary and relation description can be enough for some uses. Select a formal language or profile when exchange, constraints, or inference require its semantics. Check the properties claimed under that choice as well as the domain cases. Repair or qualify a model that passes an encoding check but answers the domain question incorrectly.
7. Return a maintained, use-qualified model. Identify the edition or stable content, covered questions, material limits, and the access and maintenance arrangement its consumers need. Return its meanings to correspondence or mapping work and its cases and qualifications to validation. A missing authoritative definition can leave one question unresolved while independently supported questions finish.

A small model can express these obligations in one short maintained description. Formalization adds the assurance required by the selected language and use. It does not change which domain question the model must answer.

SIE.3:4.2 - Record the Result

The result can refer to an existing qualified model instead of reproducing it. Record a reason only where it helps a consumer interpret or rely on the selection.

SIE.3:4.3 - What Changes in Practice

The integrator can explain why the model distinguishes two answers, or why an existing distinction is sufficient. A mapping author receives meanings and cases rather than an unexplained class list. Model construction becomes a response to a demonstrated gap.

SIE.3:5 - Archetypal Grounding

SIE.3:5.1 - Reuse for Provider Availability

The receiving interface returns separately attributed provider quantities. Its questions are “How much is on hand now?” and “How much can this provider promise under its reservation and time-horizon rules?”

An available model already distinguishes both measures, their provider, unit, observation time, and relevant horizon. The integrator checks the following cases:

The model represents these cases and has suitable access and maintenance conditions. The completed result references that edition for the two questions. It supplies no common quantity formed by adding the values; that operation would require a separately justified receiving meaning.

SIE.3:5.2 - Extend an Inspection Model

A constructed product-definition and inspection integration asks: “What observation concerns requirement Q for feature F in configuration R?” The source model already describes the feature and its requirement, but represents no actual observation.

The domain participants confirm those distinctions and identify any unresolved source-specific interpretation. The module can then supply SIE.4 and SIE.7 with the required meanings. In an AP242/QIF installation, its actual profiles, configuration relations, and inspection meanings must come from the qualified source results; the constructed model above is the working example, not a claim about a particular exchange’s conformance.

SIE.3:6 - Bias-Annotation

SIE.3:7 - Conformance Checklist

• The receiving questions and material answer distinctions are recoverable.
• Available model content is compared with those questions before development is selected.
• Sufficient reuse can complete the result.
• Developed content answers an identified gap and preserves relied-on commitments or qualifies the affected use.
• Domain examples and counterexamples support the claimed scope.
• Formal checks match the selected encoding and claimed inference or exchange use.
• The receiver can identify and access the maintained model and its limits.

SIE.3:8 - Common Anti-Patterns and How to Avoid Them

SIE.3:9 - Consequences

A qualified model makes correspondence and mapping decisions more explicit and reusable. Small integrations can finish with a small model. Extensions expose their actual commitments to later consumers.

The work costs domain conversation, example construction, and any formal checks the chosen use requires. Some questions remain unresolved until a source owner supplies a needed meaning. Larger scope creates additional content and maintenance obligations.

SIE.3:10 - Architectural Rationale

Questions and counterexamples locate the distinctions that an integration must preserve. Reuse is therefore judged by its contribution to the question; extension is justified by a specific gap. Keeping model content, its maintained edition, its formal encoding, and its instances distinct makes both adequacy and later change easier to assess.

SIE.3:11 - SoTA-Echoing

The practice question is how to settle an available model’s adequacy for the receiving questions when that adequacy is still unknown. For the inspection question in §5.2, the selected starting line is requirements-led model qualification: recover the distinction between requirement, plan, and observation, try the available meanings, and develop only the gap that survives that trial. This adapts LOT and its maintained resources.

A serious alternative for that same unsettled question is to develop the model together with a small knowledge-graph prototype, adapting the ontology-and-graph work described by LOT4KG. The prototype can reveal a missing relation when the receiving query is executed. Compare a bounded prototype with bounded model qualification, rather than charging it for a complete production platform:

The comparison is qualitative and scoped to the same questions and counterexamples; it is not a claim that one route is always cheaper or more effective. A prototype’s additional effort earns its place when it can change the qualification. Neither route can replace domain meaning with successful execution.

The remaining contributions constrain that choice:

Reopen the comparison if one required answer depends on a selected query or inference behavior that the model-only trial cannot settle, if a bounded prototype exposes a missed distinction, or if an available model can now answer the same cases with less qualification work. Return only to the affected question and §4.1.2–6. An already qualified model for an unchanged use remains the sufficient direct result in §4.1.3.

SIE.3:12 - Relations

• SIE.1 supplies the receiving question, preserved distinctions, and permitted scope.
• SIE.2 supplies source meanings and identifies model gaps.
• SIE.4 uses model meanings to establish qualified correspondences; SIE.7 uses them in executable mappings.
• SIE.10 validates the integration’s claimed receiving result using the relevant model qualification.
• SIE.11 follows a changed model premise to affected uses. SIE.12 supplies shared-module arrangements when an actual commons requires them.
• FPF terminology, kind, relation, and evidence guidance constrains the corresponding model claims; domain participants supply the problem-specific meanings.

SIE.3:End

SIE.4 - Judge Cross-Source Correspondences and Their Permitted Uses

Type: Method pattern Status: Eternal alpha Normativity: Normative method guidance within SIE; examples are constructed and non-normative.

Primary working result: a QualifiedCorrespondenceSet@Use whose rows identify exact source-local endpoints, relation or incompatibility, orientation, bounded use, permitted loss, justification and evidence, source versions, counterexamples, confidence where meaningful, and accepted, rejected, unresolved, or incompatible disposition.

SIE.4:1 - Problem Frame

Use this when two or more governed sources contain concepts, types, relations, fields, codes, model elements, or claims that appear to match and a receiving use needs their relation made explicit. Typical triggers are a shared label, a crosswalk, an automated matcher result, a spreadsheet of “equivalences”, or a model-to-model mapping whose semantic premise has never been judged.

The primary EntityOfConcern is one use-qualified cross-source correspondence row. The first move is to recover both endpoint senses and ask which direct relation, difference, or incompatibility is actually supported. The first result is a set that preserves accepted, rejected, unresolved, and incompatible rows rather than forcing every candidate into an equivalence.

The payoff is a defensible semantic premise for identity work, claim composition, executable mappings, and validation. Do not use SIE.4 to construct a missing semantic model, decide cross-source identity, define transformation code, or choose the authoritative value. A local relation inside one governed source remains with its source owner unless the cross-source use makes it an integration premise.

SIE.4:2 - Problem

Correspondence candidates are cheap. Labels can be normalized, lexical similarity scored, hierarchies compared, and model structures aligned. Yet “similar”, “related”, “narrower”, “same field name”, and “safe to substitute here” answer different questions. A row can be a true relation and still lose distinctions that the receiving use requires.

When candidate generation and qualification collapse, downstream mapping code inherits an unstated ontology and loss policy. Counterexamples are discarded as data-quality defects, source versions disappear, and a reviewer cannot tell whether the relation itself or only its use is unsupported.

SIE.4:3 - Forces

SIE.4:4 - Solution

Separate candidate discovery, direct relation judgment, and bounded-use qualification. For each row, identify exact source-local endpoints, state the relation or incompatibility and orientation, justify it with evidence and counterexamples, then decide whether that relation may support the named use under a stated loss boundary. Keep the direct relation and its use qualification independently inspectable.

SIE.4:4.1 - Pattern-Use Unfolding

1. Take the question from the contract. State the receiving answer and why this endpoint relation can change it.
2. Bind exact endpoints. Reference the SIE.2 source rows, schemes, definitions, editions, profiles, effectivity, units, codes, and local extensions. Do not map labels without their senses.
3. Generate candidates without promotion. Lexical, structural, instance, expert, historical, or matcher evidence may nominate a row. Record the candidate source and score where useful, but do not treat nomination as acceptance.
4. State the direct relation or difference. Use the narrowest warranted relation vocabulary. State direction and whether the inverse, symmetry, or transitivity is actually supported. If no positive relation is established, choose rejected, unresolved, or incompatible with reason.
5. Test examples and counterexamples. Include instances or cases that should satisfy the relation and cases that distinguish endpoints, including version, unit, code, granularity, lifecycle, and authority differences.
6. Qualify the receiving use. State which substitution, comparison, join, navigation, or transformation the row permits, what semantic loss it introduces, and which uses remain forbidden.
7. Preserve evidence and authority. Record justification, evidence source, reviewer or domain authority where required, uncertainty or confidence, and the owner of any unresolved domain judgment.
8. Assign a row disposition. Use accepted-for-use, accepted-with-loss, rejected, unresolved, or incompatible. A row can state a true broader/narrower relation yet be rejected for this use.
9. State dependencies and tests. Name whether SIE.5, SIE.6, or SIE.7 consumes the row, plus a test or observation that reopens it.

SIE.4:4.2 - Record the Result

SIE.4:4.3 - What Changes in Practice

The team stops treating a mapping spreadsheet as a bag of equalities. A matcher result becomes a candidate; a domain judgment becomes a relation warrant; and a receiving-use decision states what the relation may safely support. Unresolved and incompatible rows remain visible to the interface and tests.

SIE.4:5 - Archetypal Grounding - Product Feature and Inspection Characteristic

In the AP242/QIF application, the lexical candidate feature ↔ characteristic is too broad. The source inventory distinguishes an AP242 product-definition feature, a QIF inspection characteristic, the plan relation that applies a characteristic to a feature, and a measured result concerning that characteristic.

The set records endpoint editions and counterexamples such as a non-dimensional inspection characteristic and a feature absent at effectivity E. It establishes semantic premises; it does not decide that identifiers denote the same entity or specify executable joins.

SIE.4:6 - Bias-Annotation

SIE.4:7 - Conformance Checklist

• Every row serves a named receiving use and consuming result.
• Both endpoints reference exact source-local senses and applicable editions/profiles.
• Candidate generation is distinguishable from relation judgment.
• The direct relation, difference, or incompatibility uses the narrowest warranted kind and states orientation.
• Inverse, symmetry, and transitivity are not inferred without support.
• Positive examples and discriminating counterexamples are present where load-bearing.
• Permitted operation, semantic loss, conditions, and forbidden reuse are explicit.
• Evidence, uncertainty/confidence, and decision authority are inspectable.
• Rejected, unresolved, and incompatible rows remain available to downstream interfaces and tests.
• The set claims neither cross-source identity nor executable transformation by implication.

SIE.4:8 - Common Anti-Patterns and How to Avoid Them