Source/Target Type Check¶
Validation check — instantiates Composable Relation Modeling
Verifies that every arrow is used and composed only where its declared source and target types actually match.
A Source/Target Type Check answers one narrow, load-bearing question: for each arrow and each place it is wired, do the types at the endpoints line up? Every arrow declares a source type it accepts and a target type it produces; the check verifies that an arrow is only ever attached where its source matches what precedes it, and that in any composition the target of the first arrow equals the source of the second. Its defining limit is that it reasons purely about connectability — can these plug together at all — and says nothing about whether, once connected, the arrows obey composition laws or two routes agree. It is the gatekeeper that rejects impossible wirings before any downstream reasoning is attempted, turning "that connection won't work" from a runtime surprise into a checkable, up-front verdict against the arrow inventory.
Example¶
An A/V technician is wiring a conference room from a parts bin. The objects are port types — USB-C, HDMI, DisplayPort, VGA, 3.5mm-analog — and the arrows are cables and adapters, each of which is really a typed mapping: a plain HDMI cable is an arrow HDMI → HDMI, a USB-C → HDMI adapter is an arrow between those two types, a DisplayPort → VGA dongle is another. Someone hands the technician a plan: laptop USB-C out → USB-C→HDMI adapter → HDMI cable → HDMI→VGA passive dongle → projector VGA in.
The Source/Target Type Check walks the chain against the arrow inventory, matching each cable's declared source to the previous target. The first three links type-check cleanly: USB-C → HDMI, then HDMI → HDMI, then the chain expects an arrow whose source is HDMI. The HDMI→VGA passive dongle claims that source — but the inventory records it as valid only in the reverse direction (VGA sources can't be passively lifted to HDMI, and this dongle is passive-only). The check rejects the wiring at that exact link: no admissible arrow from HDMI to VGA in the passive inventory. The technician swaps in an active converter (a genuinely typed HDMI → VGA arrow) and the chain type-checks. No signal was ever sent; the mismatch was caught on the diagram.
How it works¶
- Maintain the typed arrow inventory. Every arrow is registered with an explicit source type and target type; an arrow whose types are unknown cannot be checked and must be resolved first.
- Match at every junction. Wherever an arrow attaches to the output of another, assert
target(previous) = source(next). A mismatch is a rejected wiring, reported at the specific junction. - Check whole chains, not just single links. Propagate types along a proposed path so that a chain type-checks only if every adjacent pair matches end to end.
- Reject, don't repair. The check's job is a verdict — admissible or not — plus the location of the first violation; it does not choose a fix.
It deliberately stops there: it does not ask whether admissible compositions are associative or whether the identity behaves — only whether the types permit connection at all.
Tuning parameters¶
- Type strictness — exact type equality vs. compatibility with declared coercions/adapters. Loose matching admits more wirings (implicit conversions) but can hide a mismatch a coercion silently papers over; strict matching is safe but rejects connections a real adapter would allow.
- Directionality enforcement — whether arrows are checked as strictly one-way or allowed to run in reverse. Enforcing direction catches phantom round-trips; relaxing it invites wirings that don't physically run.
- Granularity of types — coarse type buckets vs. fine subtypes (e.g.,
HDMIvs.HDMI-2.1). Finer types catch subtler incompatibilities but demand a richer inventory. - Failure verbosity — first violation only vs. every violation in a chain. Reporting all is more informative but noisier when one early mismatch cascades.
When it helps, and when it misleads¶
Its strength is prevention: it catches the largest and cheapest-to-fix class of composition failure — endpoints that simply don't match — before any effort is spent on the connection, and it localizes the fault to a single junction. It is the front-line gate every composition depends on.[n1]
Its failure mode is false safety: a chain that type-checks is only guaranteed to connect, not to behave, and teams routinely over-read a green type check as "the whole thing is correct." The classic misuse is trusting loose or coercion-heavy matching that connects endpoints which are nominally compatible but semantically wrong (a cable fits the port but carries the wrong signal). The guarding discipline is to keep types as fine as the real incompatibilities demand, to be conservative with implicit coercions, and to remember that passing the type check licenses only the next mechanism — the law and equivalence checks — not correctness itself.
How it implements the components¶
source_target_typing_rule— its core: the rule that every arrow attaches only where its source type matches the preceding target, enforced at each junction and along whole chains.typed_arrow_inventory— the registry of arrows with declared source and target types that the check reads and validates against; an untyped arrow is a gap the check flags.
It does not verify the composition laws once arrows do connect (associativity_invariant, identity_arrow_baseline — that is Identity and Associativity Test Suite, its nearest twin; the type check asks "can these connect?", the suite asks "given they connect, do they compose lawfully?"), and it does not enumerate composites (composition_rule — that is Composition Table).
Related¶
- Instantiates: Composable Relation Modeling — the check is the archetype's connectability gate.
- Consumes: Object–Arrow Diagram supplies the arrows and their declared endpoints.
- Sibling mechanisms: Identity and Associativity Test Suite · Object–Arrow Diagram · Composition Table · Commutative Path-Equivalence Diagram · Interface-Contract Category Map · Functorial Transfer Probe · Structure-Preservation Checklist · Categorical Refactoring Workflow
Editorial Notes¶
Form Classification¶
Form family: Assessment, Review & Assurance
Rationale: Source/Target Type Check operates as a bounded evaluation of existing evidence or work that produces a finding or disposition because it verifies that every arrow is used and composed only where its declared source and target types actually match.
Independent corroboration: The frozen evidence defines Source/Target Type Check as 'Verifies that every arrow is used and composed only where its declared source and target types actually match', so its operative form is Assessment, Review & Assurance.
Nearest alternative: Rule, Policy & Commitment — Source/Target Type Check includes features of a standing rule, threshold, contractual commitment, or policy constraint governing future conduct, but its defining operation is a bounded evaluation of existing evidence or work that produces a finding or disposition.
Review outcome: Independent reviewer agreement; medium confidence.
Origin Attribution¶
Primary origin: Mathematics
Origin pattern: Convergent development
Present-day reach: Multi-domain
Rationale: Verifying that arrows compose only when codomain and domain match is categorical and typed mathematical reasoning.
Related originating lineages:
- Computer Science & Software Engineering — Static type checking rejects ill-typed function composition.
- Linguistics & Semiotics — Selectional restrictions constrain semantically valid roles and arguments.
- Philosophy — Category mistakes violate the kinds of entities a relation can connect.
Review resolution: The blind reviewers agree that mathematics is the primary origin and differ only on alternate origin disagreement, origin mode disagreement, domain reach disagreement. I preserve every independently explained alternate from both records rather than imposing a numeric cap. I retain convergent because the combined evidence shows independent disciplinary development. The broader reach of multi_domain records portability separately from historical provenance; encyclopedia_synthesis=true preserves the affirmative synthesis judgment where either reviewer identified one.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
[n1] Robin Milner's slogan "well-typed programs cannot go wrong" captures the guarantee a type check provides — and its boundary: type safety rules out a specific class of connection errors, not all misbehavior. A chain that type-checks is well-formed, not thereby correct. ↩