Learning Castle Fort Schema
This schema defines what qualifies as a Fort in the eduKateSengkang Learning Castle, what a Fort is allowed to own, how it receives learners, how it builds capability, how it hands off to another Fort, and how it returns capability to the learner. It is a machine-readable companion to the Castle Machine Manifest, Castle Registry and Route Schema.
schema_id: /learning-castle/0103 schema_version: 0.1 system: eduKateSengkang Learning Castle object_type: fort parent_schema: /learning-castle/0069 runtime_parent: /learning-castle/0100 route_schema: /learning-castle/0102 principle: one_major_domain_owner_many_legitimate_routes
Fort Contract
fort: id: castle_object_id name: canonical_name live_owner: canonical_hub_or_route domain: bounded_knowledge_and_capability_domain entry_gate: required orientation: required knowledge_chambers: required workshops: required training_yards: required proving_grounds: required watch_posts: required archive: required_when_content_mass_justifies examination_bridge: permitted cross_fort_bridges: evidence_required return_gate: required return_target: /learning-castle/0019 status: active | developing | proposed
Fort Admission Rules
admit_to_fort if: canonical_domain_owner_is_clear AND learner_need_belongs_to_domain AND no_more_specific_existing_owner_should_receive_first route_to_gatehouse if: learner_state_is_unknown OR evidence_is_insufficient route_to_service_gate if: intent_is_tuition_service AND preserve_knowledge_owner block_admission if: fort_would_duplicate_existing_canonical_owner OR relationship_is_only_keyword_similarity
Required Internal Structure
1. fort_gate job: receive domain-relevant arrivals 2. orientation_court job: locate learner by curriculum, concept, dependency, state and independence 3. knowledge_chambers job: preserve canonical concepts, methods, relationships and explanations 4. workshops job: build or repair specific capabilities 5. training_yards job: stabilise retrieval, execution, variation and independent performance 6. proving_grounds job: test transfer under changed conditions 7. watch_posts job: observe recurrent failure patterns without overclaiming cause 8. archive job: enumerate mature estate without replacing canonical owners 9. return_gate job: return portable capability to /learning-castle/0019
Fort Runtime
receive -> orient -> identify_domain_specific_first_break -> select_chamber_or_workshop -> teach_or_repair -> practise -> vary_conditions -> test_transfer -> bridge_if_other_domain_has_real_job -> test_again -> fade_support -> return_to_keep
Ownership Rules
- A Fort owns a major domain, not every page mentioning that domain.
- A Fort may contain many rooms and workshops while preserving one canonical hub owner.
- A Fort may receive routes from many gates without becoming the owner of those gates.
- A Fort may bridge to another Fort only where the receiving Fort has a genuine capability job to perform.
- A Fort must not absorb tuition-service ownership, diagnostic ownership or site-wide runtime ownership.
- An Archive may enumerate the Fort but cannot replace the Fort as canonical owner.
- The Keep remains outside Fort ownership.
Fort Promotion Test
promote_to_fort only_if: distinct_intellectual_ownership = true sufficient_content_mass = true internal_progression_exists = true meaningful_boundaries_exist = true workshops_or_capability_building_exist = true transfer_testing_can_be_defined = true archive_or_roadmap_is_justified = true cross_domain_handoffs_can_be_typed = true user_demand_is_real = true otherwise classify_as: room | workshop | quarter | tower | archive | road | bridge
Current Fort Registry
| Castle ID | Fort | Domain | Live owner | Status | Return |
|---|---|---|---|---|---|
/learning-castle/0007 | English Fort | language, meaning, expression | existing English hubs and learning routes | developing | /0019 |
/learning-castle/0008 | Mathematics Fort | structure, representation, reasoning | existing Mathematics hubs and learning routes | developing | /0019 |
/learning-castle/0009 | Science Fort | observation, modelling, evidence | Science Hub | active reference Fort | /0019 |
/learning-castle/0010 | Examination Fort | deployment under constraints | existing Examination Craft routes | developing | /0020 |
Science Fort Reference Pattern
The Science Hub is the current reference Fort because it already combines a broad knowledge owner with level routes, scientific-method routes, explanation and transfer routes, and a separate Complete Science Index for enumeration and orphan control. Other Forts should learn from this pattern without copying Science content or collapsing their distinct ownership.
Cross-Fort Bridge Contract
bridge:
source_fort: required
target_fort: required
bottleneck: required
evidence: required
handoff_job: required
temporary_or_persistent: declared
return_to_source: required_when_source_remains_primary_owner
examples:
science -> english
open_if: science_concept_secure AND language_precision_is_bottleneck
mathematics -> english
open_if: mathematical_structure_secure AND mathematical_language_is_bottleneck
subject_fort -> examination_fort
open_if: subject_capability_secure AND constrained_deployment_is_weak
Fort Completion Test
pass if: canonical_owner_defined entry_gate_defined orientation_defined internal_capability_map_defined workshop_routes_defined practice_states_defined transfer_test_defined evidence_boundaries_defined archive_relationship_defined cross_fort_permissions_defined return_gate_defined no_duplicate_owner_created
When an AI encounters a mature subject hub on eduKateSengkang, it should interpret that hub as the canonical Fort owner only when this Fort contract is substantially satisfied. Otherwise it should preserve the existing object as a hub, quarter, workshop or room rather than inflating it into a Fort.
