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
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- State reopen conditions and next result. Identify observations that change the contract and the smallest next result, often
SourceSemanticInventory@UsefromSIE.2.
SIE.1:4.2 - Record the Result
| Contract position | Required content |
|---|---|
| receiver and use | named receiver, Work, query/decision/operation/workflow, horizon, and first useful answer |
| answer claims | propositions or fields, grain, scope, interval/effectivity, and action changed |
| source cut | governed contexts, candidate assets, inclusion reason, and known access limits |
| semantic boundary | distinctions to preserve, permitted loss, uncertainty treatment, unmatched/incompatible behavior |
| service conditions | currentness, latency, availability, recovery, and quality thresholds that change use |
| authority and protection | meaning owner, identifier or value authority, access/permission, receiver authority, and protected conditions |
| validation | representative positive, negative, unlike/change cases and expected branches |
| disposition | pass, narrow, unresolved, or stop rules; next result and observable reopen conditions |
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.