Learning Castle Watchtower Schema

Canonical ID: /learning-castle/0114. A Watchtower observes the condition of the Learning Castle without becoming the owner of the learner, subject, intervention or route. It exists to detect meaningful change, drift, blockage and unresolved uncertainty early enough for the correct owner to act.

schema: learning_castle_watchtower
version: 0.1
castle_id: /learning-castle/0114
object_type: watchtower
purpose: bounded_observation_and_change_detection
may_observe: true
may_signal: true
may_compare_expected_vs_observed: true
may_claim_domain_ownership: false
may_prescribe_without_gate: false
may_override_fort: false
may_override_portcullis: false
canonical_return: /learning-castle/0019

What a Watchtower Watches

• learner-state changes that materially alter the next useful route;
• route drift, broken edges and unresolved ownership;
• repeated failure after an intervention that was expected to work;
• evidence that a Gate should be reopened rather than blindly continuing;
• estate-level changes that make an existing machine declaration stale;
• expected-versus-observed differences large enough to require review.

Observation Contract

watch_record:
  observer
  observed_node
  observed_state
  expected_state
  evidence
  confidence
  change_type
  materiality
  timestamp
  recommended_gate
  canonical_owner
  return_target

change_type:
  improvement
  deterioration
  drift
  blockage
  contradiction
  stale_route
  ownership_conflict
  unknown

materiality:
  informational
  review
  gate_reopen
  route_block

Watchtower Law

A Watchtower reports; it does not seize control. Observation must remain attributable to evidence. A change in a score alone does not prove a change in underlying capability. A repeated signal may justify reopening a Gate, but the Gate, Key and Portcullis rules still determine whether traversal is permitted.

watchtower_runtime:
  observe
  -> compare_expected_vs_observed
  -> classify_change
  -> estimate_materiality
  -> resolve_canonical_owner
  -> if informational: record_and_return
  -> if review: signal_owner
  -> if gate_reopen: return_to_gate
  -> if route_block: signal_sentry_or_portcullis
  -> preserve_return

hard_rules:
  observation_is_not_ownership
  correlation_is_not_causation
  low_confidence_does_not_unlock_high_cost_route
  watchtower_does_not_bypass_key
  watchtower_does_not_bypass_portcullis
  unresolved_owner_returns_to_gatehouse
  every_material_signal_requires_evidence

Machine Relationships

The Watchtower reads the Node Schema and State Schema, can request reconsideration through the Gate Schema, respects the Key Schema and Portcullis Schema, and returns control through the Return Schema. Machine readers should begin with the Boot Protocol and Castle Registry.

The Watchtower should make change visible without mistaking visibility for authority.