Evaluate the mechanism link label

Type: kb/types/instruction.md

Outcome

Produce kb/work/linking-contract-consistency/mechanism-label-direction-review.md: a read-only semantic evaluation with one exact disposition for every active mechanism edge and every row deferred to mechanism evaluation by the grounds adjudication.

Recommend one of these outcomes:

  1. one source-as-subject successor for a coherent mechanism relation;
  2. a principled split between explanation, operational mechanism, prerequisite, or other recurring relations;
  3. reclassification into existing relations with no dedicated successor;
  4. retirement into connective prose where no formal relation earns its cost.

Do not edit corpus edges, collection contracts, the catalogue, ADRs, durable instructions, or existing workshop results. Write only the review and, if a separate ledger is genuinely useful, a workshop-local TSV linked from it.

Governing context

Read ADRs 020, 058, and 060; the current link vocabulary and relevant collection contracts; the directional grammar; and the grounds direction review and boundary adjudication.

The last local inventory found 79 active mechanism edges and 49 deferred mechanism-like grounds edges. Recompute both surfaces rather than trusting those counts. Preserve each row's origin label so the review can test whether authors were using the two labels differently. The nine previously observed files authoring both labels are high-information cases, not a privileged sample.

Evaluate the corpus

Resolve targets and classify every active tuple by its actual source→target assertion. Inspect local context first and open full source and target artifacts for boundary cases. Define the mutable surface and mutually exclusive exclusions; cover ordinary and bold footer forms; report syntax the inventory cannot parse.

At minimum distinguish:

  • a target claim that explains why or how the source phenomenon occurs;
  • a target process or component through which the source literally operates;
  • an enabling condition or temporal/logical prerequisite;
  • premise dependence, evidence, definition, extension, exemplification, implementation, comparison/navigation, removal, and unresolved ambiguity.

Do not treat explained-by or operates-through as existing vocabulary: neither is currently registered. Test them only as candidate assertions. Likewise, do not assign a row to the directionally unresolved enables or precondition identifier merely because it is prerequisite-shaped; record the semantic class and the neighboring-label dependency.

For every proposed new identifier, state the literal source <label> target assertion and test whether ordinary language reverses the endpoints, overstates causation, or confuses an explanatory note with the mechanism it describes. Decide whether explanation and operational mechanism produce different follow/skip or maintenance decisions. Test whether any independently useful inverse exists without creating a reciprocal-authoring obligation.

Compare at least:

  • explained-by as a broad explanation successor;
  • operates-through as a narrower operational-mechanism successor;
  • a split between those relations;
  • reclassification or retirement with no successor.

Use existing labels only when their registered assertion is exact. Identify overlaps with premised-on, rests-on, evidenced-by / is-evidence-for, extends, exemplifies, defined-in, implements, and the unresolved prerequisite vocabulary.

Required review

Include:

  • live and excluded counts reconciled by origin label and source→destination pair;
  • one exact semantic disposition for every active tuple, preserving source, resolved target, and origin label;
  • counts and representative cases for each final class;
  • same-file comparison of every source that authors both the existing label and a deferred candidate;
  • strongest evidence for and against each candidate outcome;
  • recommended identifier(s), assertion template(s), reader need, direction kind, inverse decision, and neighboring-label boundaries—or an explicit retirement recommendation;
  • exact rows that depend on later enables / precondition adjudication rather than silently assigning those labels;
  • authorization and migration consequences without performing them;
  • surprises, confidence, and concrete reversal evidence.

The result must be specific enough for maintainer adjudication and for completing the grounds disposition ledger. Validate changed output, run git diff --check, and report changed paths. The parent dispatch requests Luna through the runtime; record the requested model and any model identity actually exposed to the executing process without inventing stronger provenance.