Library / Semantic Integration Engineering Principles Framework
Jump to passage
In this reading

Link to current text

Published source confirmed at last check

Source changed 2026-10-03 11:52:20 UTC · snapshot created 2026-10-03 11:53:41 UTC · last check 2026-10-03 12:45:07 UTC

SIE.10:4 - Solution

Choose the conclusion at its actual scope. A known decisive failure or bounded unresolved premise can finish with sufficient evidence for that result. For a positive whole-use or contract-permitted narrower result, obtain matching evidence for every load-bearing premise, including the receiver’s interpretation. Use earlier results when their conditions still match. Preserve hard stops and distinguish unexamined premises from passing ones.

SIE.10:4.1 - Pattern-Use Unfolding

Steps 3–10 locate evidence for a positive use conclusion. A sufficient bounded failure or unresolved result can finish at step 2. Reuse matching earlier results for the applicable layers; a changed receiving interpretation can reopen a claim even when its carrier is unchanged.

  1. Identify the validation subject. Name the mapping, interface, or package result and receiving use being judged. Record the revisions and conditions on which the conclusion depends.
  2. Choose the conclusion and inspect known evidence. Take the relevant answer claim and stop condition from SIE.1. If a demonstrated defect already defeats it, return that bounded failure with sufficient evidence. If a necessary premise is unresolved and that settles the requested question, return the scoped gap. Further obligations remain unexamined. For a positive claim, derive all load-bearing distinctions, loss, currentness/service/quality, authority, protection, branch, and representative-use obligations.
  3. Validate carrier and schema. Test parseability, declared schemas/shapes, required fields, datatypes, cardinalities, identifiers, and branch encodings. Treat a pass as structural only.
  4. Validate semantic-model and endpoint adequacy. Test whether source and target concepts, types, relations, constraints, units/codes, and any supplied model express the required distinctions and examples/counterexamples.
  5. Validate correspondences and mappings. Challenge accepted SIE.4 rows and execute SIE.7 positive, boundary, negative, and unlike examples. Check selection, cardinality, conversion, defaults, errors, loss, and trace independently.
  6. Validate identity and authority. Test every load-bearing SIE.5 disposition at its grain and interval, including issuer, version, part-whole, reuse, split/merge, and unresolved branches. Verify required authority and permission inputs rather than inferring them from data access.
  7. Validate claim composition. Test SIE.6 comparability, conflict, non-comparability, supersession, incomplete-source, and uncertainty branches. Confirm that source claims and derivation remain recoverable.
  8. Validate realization and interface behavior. Test currentness, latency, availability, snapshot/caching, invalidation, source failure, partial results, access/protection, provenance, error semantics, and challenge paths required by SIE.8 and SIE.9.
  9. Validate provenance, currentness, and quality. Check that every relied-on output can recover its source and rule premises, that source/version/time status satisfies the use, and that selected quality measurements meet their action-changing thresholds. Do not treat provenance or process conformance as truth.
  10. Replay representative receiving Work. Run the named query, decision preparation, operation, or engineering workflow with expected positive, negative, and unlike cases. Observe whether the receiver obtains and interprets the required result and stops on forbidden branches.
  11. Assign dispositions at the supported scope. Use pass, narrow, unresolved, or stop for tested claims, and preserve any material unexamined reach. A positive narrow result states the contract-permitted subset and covers all of that subset’s load-bearing premises; excluded branches remain explicit. A hard stop cannot be offset by scores elsewhere.
  12. Record repairs, returns, and reopen. Send source, semantic, mapping, implementation, authority, or receiver defects to their direct owners; state which layer and consumers require retest after change.

SIE.10:4.2 - Record the Result

Validation positionRequired content
subject and usepackage/interface revision, source/rule versions, realization/test state, receiver and use
obligationspremises relevant to the claimed conclusion; all load-bearing contract obligations for a positive use claim
layer resultlayer, tested claim, method/case, evidence, expected/observed result, pass/narrow/unresolved/stop, defect owner
dependencyexact source, correspondence, identity, composition, mapping, realization or interface premise consumed
coverageexamined cases and matching earlier results; material unexamined or unresolved premises, distinguished from passing ones
use dispositionsupported local failure or gap, or positive result with its conditions and full load-bearing coverage; excluded subset and hard stops
continuationrepairs or direct-owner returns, focused retest, affected consumers, reopen condition

SIE.10:4.3 - What Changes in Practice

The team stops asking whether “the integration” passed one test. Each claim has an appropriate layer, evidence, and owner. A bounded subset can be used without hiding excluded rows, and a source or rule repair triggers focused revalidation instead of an automatic full rebuild or a silent continuation.