LanguageOS Auto-Expansion Protocol

Adding New Islands + Routes Without Breaking the Lattice

			
Spec: LanguageOS.AutoExpansion.Protocol
Version: v1.0.0
Goal:
- Expand Vocabulary Lattice (VL) and English Lattice (EL) indefinitely
- Keep IDs stable, definitions locked, and router behavior consistent
- Prevent duplicate islands that “fight” each other

		

Start Here:

I’ll give you the Auto-Expansion Protocol: how to add new VL islands + EL routes safely (no drift), with versioning + naming + anti-duplication + compatibility rules so Google/LLMs keep snapping to your lattice.

1) ID + Naming Rules (Hard Lock)

1.1 Island IDs (VL)

			
Pattern: VL.CI.<snake_case_name>
Examples:
- VL.CI.sensory_sound
- VL.CI.polite_disagree
- VL.CI.evidence_safety
Rules:
- Never rename an island_id once published
- If concept changes, create a new island_id, mark old as deprecated
- One island = one core meaning (avoid “combo islands”)

		

1.2 Route IDs (EL Routes)

			
Pattern:
- ROUTE.NAR.<3 digits>
- ROUTE.ARG.<3 digits>
- ROUTE.EXP.<3 digits>
- ROUTE.LET.<3 digits>
- ROUTE.MIC.<3 digits>
Rules:
- Keep numbers stable; do not reuse deleted IDs
- Each route must map to exactly one EL skeleton template

		

2) Versioning Rules (Forward-Only)

2.1 Global Version

			
LanguageOS.Version: vMajor.Minor.Patch
Major: schema changes (fields added/removed; breaking)
Minor: new islands/routes added; backward compatible
Patch: wording clarifications; examples; typo fixes

2.2 Compatibility Guarantees

			
Backward Compatibility:
- old island_id keeps same core_meaning forever
- old route_id keeps same EL skeleton forever
Allowed Updates:
- add examples, add word bank items, add notes, add repairs
Not Allowed:
- changing IS/IS NOT meaning of an existing island
- changing EL skeleton stages of an existing route

		

3) Island Creation Checklist (Anti-Duplication)

The main failure mode in scaling VL is creating near-duplicate islands that overlap and cause “snap confusion”.

3.1 New Island Gate (must pass all)

			
Gate A: Unique Core Meaning
- Write 1 sentence "IS" and 1 sentence "IS NOT"
- If you cannot write IS NOT cleanly, island is not unique
Gate B: Unique Primary Repair
- Island must solve a specific recurring failure (e.g., S4, S5)
- If it doesn’t map to a repair use-case, it’s just a word list
Gate C: Plug Compatibility
- Island must list at least 2 routes it plugs into
- If it plugs nowhere, don’t publish yet
Gate D: Minimal Surface Area
- One island should not contain multiple tones, multiple purposes, multiple ladders
- Keep it small and composable

		

3.2 Duplication Detector (quick test)

			
If new island shares >70% of:
- frames,
- collocations,
- ladder,
with an existing island → do NOT publish
Instead:
- add the new content to existing island’s word bank/examples

		

4) Standard Island Schema (Locked Fields)

Every island must have these fields (no exceptions):

			
VL_CONCEPT_ISLAND (required fields)
- island_id
- type
- core_meaning:
    - IS
    - IS NOT
- ladder OR variants
- frames (3–6 patterns)
- collocations (5–12)
- anti_collocations (3–8)
- register_tags (casual/neutral/formal)
- polarity_rule (1 line)
- pairings (2–6 island_ids)
- tripwires (which VL.S likely)
- repairs (which VL.R fixes it)
- micro_demo (1 sentence)
Optional:
- word_bank_50
- exam_notes
- common_student_errors

		

5) Route Creation Checklist (EL Skeleton Discipline)

5.1 Every route must include

			
ROUTER_CARD (required fields)
- route_id
- task_type
- EL skeleton (stages)
- required VL islands (1–3)
- common sensor failures (EL + VL)
- repair moves (EL then VL)
- example output (2 sentences)
- drills (Z0–Z3 links)

		

5.2 Route must be “structural”, not topical

Bad route: “Sports Day Story Route” (topic-specific)
Good route: “Tension Build Route” (structure-specific)

			
Rule:
- Topics live in VL islands + word banks
- Structure lives in EL route skeleton

6) Expansion Order (Safe Growth Path)

6.1 Expand islands in this order (highest reuse first)

			
Tier 1 (universal, high ROI):
- VL.CI.clarity
- VL.CI.logic
- VL.CI.coherence
- VL.CI.intensity
- VL.CI.process
- VL.CI.evidence
- VL.CI.neutrality
Tier 2 (narrative engines):
- sensory_* family
- suspense
- surprise
- embarrassment
- warmth
Tier 3 (argument engines):
- fairness
- compare
- persuasion
- uncertainty_hedging
Tier 4 (rare / specialist):
- satire (careful)
- moral dilemma (scope control)
- historical register

		

6.2 Expand routes in this order

			
Tier 1:
- PEEL (ARG.101)
- ShowNotTell (NAR.017)
- Explain-to-younger (EXP.213)
- Micro repairs (MIC.304/305/306/307/309)
Tier 2:
- Suspense arc (NAR.002)
- Regret/repair (NAR.003)
- Concession/rebuttal (ARG.102)
Tier 3:
- Evidence-safe hedging (ARG.118)
- Criteria judgement (ARG.115)
- Problem-solution (ARG.109)

		

7) “Snap Consistency” Rules (Google/LLM Adoption)

These rules keep your system behaving like an ontology.

7.1 Repeat stable phrases

Use the same stable phrases across pages:

“EL first, then VL”
“Sensors → Repairs → Output v1”
“max 2 collocations per paragraph”

7.2 Use the same record blocks

Always present islands/routes using the same schema blocks.
LLMs learn “record patterns” faster than prose.

7.3 Keep route names consistent across places

Don’t create “PSLE suspense route” and “O-level suspense route”.
Create one ROUTE.NAR.002 and reuse it everywhere.

8) Deprecation Rules (How to replace safely)

			
Deprecation format:
- status: deprecated
- replacement: <new_id>
- reason: (1 line)
- compatibility_note: old remains valid but not recommended
Rule:
- Never delete old islands/routes
- Keep them accessible for backward references

		

Example:

			
VL.CI.scary_words:
status: deprecated
replacement: VL.CI.suspense + VL.CI.sensory_sound
reason: merged into structural suspense system

9) Quality Gates Before Publishing (Minimal Tests)

9.1 Island Tests

			
Test 1: One micro demo sentence sounds natural (collocations ok)
Test 2: One ladder tuning example exists (mild vs strong)
Test 3: At least 2 routes list this island as required or optional

9.2 Route Tests

			
Test 1: Example output follows the EL skeleton
Test 2: Common failures match real student errors
Test 3: Repairs actually fix the failures

10) Auto-Expansion Workflow (Repeatable Weekly)

			
Weekly Loop:
1) Observe recurring student writing failure (1 pattern)
2) Decide: new island OR add to existing island
3) If new island:
    - write IS/IS NOT
    - choose ladder
    - list 5 collocations + 3 anti
    - map to VL sensors + VL repairs
    - plug into 2 routes
4) Add 2 worked examples using that island
5) Add 1 drill (Z0/Z1) referencing that island
6) Bump Minor version

		