Reason maintenance — structured justification tracking for Binding-triggered Worker activations

[mdproctor]

Overview

Track why each Worker was activated — which CaseContext keys satisfied its Binding's condition, what the `WorkerSelectionStrategy` decision was, and whether a human or meta-control intervention triggered the activation.

Part of epic #77 (Blackboard Architecture Evolution).

Background

Reactive scheduling research (ScienceDirect — blackboard for reactive scheduling) shows that reason maintenance — tracking justifications for assignments — enables:

• Rescheduling when earlier assumptions are invalidated
• Audit trails that explain case outcomes (not just what happened, but why)
• Learning from activation patterns across cases (which preconditions tend to co-occur, which strategies produced better outcomes)

Current EventLog captures that a worker executed. It does not capture why this Worker was selected over others that were also eligible.

What to build

• Enrich `WORKER_EXECUTION_STARTED` EventLog entries with:
  • `satisfiedCriteria`: which CaseContext keys matched the Binding's condition at activation time
  • `eligibleCandidates`: how many other Workers were also eligible via their Bindings
  • `selectionReason`: which `WorkerSelectionStrategy` selected this one and why (priority score, confidence, etc.)
  • `activationTrigger`: `CHOREOGRAPHY`, `STRATEGY_SELECTED`, `META_CONTROL`, `HUMAN_OVERRIDE`
• `JustificationQuery` — API to retrieve the justification chain for a given CaseContext key (which Worker activations produced it, what triggered those activations)
• Connects to Claudony lineage dashboard — justification data enriches the lineage graph

Relationship to existing work

Extends EventLog enrichment planned in epic #30 Phase 2 (key-level diffs on `WORKER_EXECUTION_COMPLETED`). Justification tracking is the activation-side enrichment; key-level diffs are the result-side enrichment.