Small Group Tutorials

Here to help students catch up, keep up, and move ahead. Book a consultation here.

Learning Castle Scout Schema

Learning Castle Scout Schema

Canonical ID: /learning-castle/0116. A Scout explores candidate relationships in the eduKateSengkang estate. It may discover possible Roads, Bridges, Return Roads, orphan attachments and owner candidates, but it may not admit any of them into the live Castle until the relevant owner, evidence, edge type, key, Portcullis condition and return have been validated.

schema: learning_castle_scout
version: 0.1
castle_id: /learning-castle/0116
object_type: scout
purpose: candidate_route_and_orphan_discovery
may_search: true
may_propose_edge: true
may_propose_owner_candidate: true
may_identify_orphan: true
may_admit_edge: false
may_create_owner: false
may_bypass_validation: false
may_bypass_portcullis: false
canonical_return: /learning-castle/0019

Scout Outputs

candidate:
  candidate_id
  source_node
  target_node
  proposed_edge_type
  proposed_owner
  discovery_reason
  evidence
  confidence
  likely_user_job
  likely_learning_job
  return_candidate
  collision_risk
  service_boundary_risk
  private_boundary_risk
  status

status:
  discovered
  proposed
  needs_owner_resolution
  needs_evidence
  needs_return
  needs_validation
  rejected
  admitted

What a Scout May Discover

  • an older article that belongs under an existing hub but has no meaningful inbound route;
  • a deep room that needs a Return Road to its canonical owner;
  • two existing domains that may require a real cross-Fort Bridge;
  • a page whose current apparent owner conflicts with the Registry;
  • a candidate Fort or sub-hub where a genuine ownership gap may exist;
  • a redundant relationship that should remain unadmitted because another stronger route already exists.

Admission Pipeline

discover_candidate
-> resolve_source_node
-> resolve_target_node
-> resolve_canonical_owner
-> classify_candidate_edge
-> check_collision
-> check_service_boundary
-> check_private_boundary
-> check_return
-> identify_required_keys
-> evaluate_portcullis
-> send_to_validation
-> if PASS: mark_admitted
-> if WARNING: keep_proposed_or_bounded
-> if FAIL: reject_and_preserve_existing_owner

Scout Laws

discovery_is_not_admission
similarity_is_not_ownership
shared_keyword_is_not_bridge_evidence
new_page_is_not_required_if_existing_owner_can_receive
orphan_repair_prefers_existing_owner
return_is_required_before_deep_learning_route_is_complete
service_intent_must_remain_explicit
private_runtime_must_remain_private
low_confidence_candidate_remains_reversible
rejected_candidate_does_not_disappear_from_audit_history

Scout, Watchtower and Sentry

The Watchtower observes change. The Sentry guards declared live routes. The Scout looks outward for candidate routes and missing connections. A Scout proposal does not become live plumbing merely because it looks useful.

Machine Relationships

The Scout reads the Castle Registry, Node Schema, Edge Schema, Key Schema, Portcullis Schema and Return Schema. Nothing becomes admitted until it passes the Validation Schema. Machine readers should begin with the Boot Protocol.

The Scout may discover a road. Only the Castle may admit it.