Learning Castle Gate Schema

This schema defines the machine contract for every gate in the eduKateSengkang Learning Castle. A gate converts a known or bounded state into a permitted next route. It does not create evidence, invent ownership or force movement where the required key is missing.

schema_id: /learning-castle/0111
schema_version: 0.1
system: eduKateSengkang Learning Castle
object_type: gate
runtime_parent: /learning-castle/0100
state_schema: /learning-castle/0110
route_schema: /learning-castle/0102
edge_schema: /learning-castle/0104
return_schema: /learning-castle/0105
validation_schema: /learning-castle/0107
principle: no_gate_opens_without_a_valid_state_and_key

Gate Contract

gate:
  gate_id: /learning-castle/####
  name: human_readable_name
  input_states: allowed_states
  actor_scope: learner | parent | teacher | public | ai | mixed
  required_keys: evidence_or_intent_keys
  open_if: explicit_condition
  blocked_if: explicit_block_conditions
  permitted_destinations: declared_nodes_or_owner_classes
  edge_type: gate_road | service_road | bridge | return_road
  fallback: gatehouse | canonical_owner | stop
  evidence_required: true_or_false
  return_target: castle_id_or_owner
  status: active | developing | proposed

Core Gate Types

learner_gate:
  castle_id: /learning-castle/0030
  open_if: actor = learner
  destination: /learning-castle/0005
  edge_type: gate_road

civilian_gate:
  castle_id: /learning-castle/0029
  open_if: actor = parent_or_family
  destination: /learning-castle/0005
  edge_type: gate_road

service_gate:
  castle_id: /learning-castle/0031
  open_if: intent = tuition_service
  destination: relevant_service_owner
  edge_type: service_road
  preserve: knowledge_owner

subject_gate:
  open_if: domain_owner_resolved
  destination: relevant_fort
  edge_type: gate_road_or_road

transfer_gate:
  open_if: familiar_performance_secure AND transfer_not_secure
  destination: proving_ground
  edge_type: gate_road

examination_gate:
  open_if: subject_capability_secure AND constrained_deployment_weak
  destination: /learning-castle/0010
  edge_type: bridge

open_gate:
  castle_id: /learning-castle/0020
  open_if: capability_portable
  destination: world_return
  edge_type: return_road

Gate Keys

key.actor_known:
  evidence: actor_identity_or_role_is_clear

key.intent_known:
  evidence: user_goal_is_explicit_or_bounded

key.owner_resolved:
  evidence: canonical_owner_is_verified_or_bounded

key.state_resolved:
  evidence: smallest_defensible_state_is_assigned

key.evidence_sufficient:
  evidence: current_decision_is_supported_enough_to_route

key.bridge_justified:
  evidence: receiving_owner_has_real_job_and_handoff_reason

key.transfer_secure:
  evidence: capability_survives_meaningful_variation_or_delay

key.independence_secure:
  evidence: capability_survives_reduced_support

Gatehouse Rule

route_to_gatehouse if:
  state = unknown
  OR owner = unresolved
  OR evidence = conflicted
  OR several_routes_exist_but_primary_owner_is_unclear

Gatehouse job:
  narrow
  discriminate
  resolve owner
  identify first useful weak link
  then open smallest valid gate

Blocked Transitions

block gate if:
  state = unknown AND route_requires_prescription
  owner_conflict = true
  evidence_required = true AND evidence_sufficient = false
  cross_owner_handoff_has_no_bridge_justification
  service_intent = false AND destination_is_tuition_service
  route_would_create_duplicate_canonical_owner
  private_runtime_would_be_exposed
  return_path_required_but_missing

Fallback Behaviour

if gate_cannot_open:
  1. do_not_force_route
  2. preserve current owner
  3. route_to_gatehouse_if_uncertainty_can_be_reduced
  4. route_to_validation_if_owner_or_edge_conflict_exists
  5. stop_if_portcullis_rule_applies
  6. preserve return path

Gate Priority

when_multiple_gates_can_open:
  1. choose gate matching explicit intent
  2. choose smallest gate matching verified owner
  3. choose gate matching current learning state
  4. prefer same-owner progression over cross-owner bridge
  5. prefer reversible route when evidence is bounded
  6. preserve return

Live Gate Examples

example.parent:
  actor = parent
  state = unknown
  open = /learning-castle/0029
  next = /learning-castle/0005

example.math_transfer:
  owner = /learning-castle/0008
  knowledge = secure
  standard_practice = secure
  transfer = weak
  open = transfer_gate
  destination = proving_ground
  return = /learning-castle/0008

example.science_language_bridge:
  owner = /learning-castle/0009
  science_concept = secure
  language_precision = bottleneck
  key.bridge_justified = true
  open = bridge_gate
  destination = /learning-castle/0007
  return = /learning-castle/0009

example.service:
  actor = parent
  intent = tuition_service
  open = /learning-castle/0031
  destination = relevant_tuition_owner
  preserve = subject_knowledge_owner

Gate Validation

PASS if:
  input_state_allowed
  required_keys_present
  destination_exists
  owner_boundary_preserved
  edge_type_valid
  return_present_when_required

WARNING if:
  gate_is_reasonable_but_one_condition_is_bounded

FAIL if:
  gate_opens_without_required_key
  OR destination_has_no_valid_owner
  OR route_breaks_service_or_private_boundary
  OR return_is_missing

AI Gate Procedure

1. read current state
2. resolve actor and intent
3. resolve canonical owner
4. list candidate gates
5. check required keys
6. reject blocked gates
7. choose smallest valid gate
8. validate destination and edge type
9. traverse
10. preserve return

A Castle Gate therefore behaves like a logic gate: it converts state plus evidence into a permitted transition. The metaphor and the machine rule are the same object viewed at different levels.