A registry tells us what exists.
A crosswalk tells us how systems connect.
A plug-in standard tells us how future additions enter safely.
A phase registry tells us **what condition the system is currently in**.
This matters because eduKateSG now treats each article as part of a wider runtime that helps readers move from understanding into diagnosis, repair, optimisation, transfer, and long-term growth. 
---
## 2. One-Sentence Definition
The **eduKateSG Phase Registry** is the P0–P4 state system that identifies whether a learner, subject, institution, civilisation, shell, or runtime is collapsed, stabilising, functioning, regenerative, or attempting frontier expansion.
---
## 3. Why Phase Needs Its Own Registry
eduKateSG now has many systems:

Each system can be in a different condition.
A student may be:

A civilisation may be:

A site article may be:

Without a Phase Registry, everything sounds like “progress.”
With a Phase Registry, eduKateSG can ask the sharper question:

---
## 4. Core Law of Phase Registry

This is the main distinction.
A system can be large but low-phase.
A small tuition class can be P3 if it diagnoses, repairs, transfers, and self-corrects well.
A large institution can be P1 if it is constantly stabilising breakdown.
A civilisation can reach a CFS frontier shell but still be P1 internally if the parent base is weak.
---
## 5. Phase vs Shell vs Scale vs Crosswalk
This distinction is important for future articles.
| Term      | What It Means                       | Example                           |
| --------- | ----------------------------------- | --------------------------------- |
| Registry  | What exists                         | `MATHOS.REGISTRY`                 |
| Crosswalk | How systems connect                 | `XWALK.EDUOS.MATHOS.v1.0`         |
| Plug-in   | Controlled future add-on            | `PLUGIN.CFS.MEMBRANE_LADDER.v1.0` |
| Phase     | Current operating condition         | `PHASE.MATHOS.P1.v1.0`            |
| Shell     | Container or survivability boundary | CFS frontier shell                |
| Scale     | Measurement system                  | ACS percentage, EFSC stability    |
| Dashboard | Visible runtime output              | Control Tower panel               |
Simple version:

---
# 6. Master Phase Map: P0–P4
The core eduKateSG phase ladder is:

---
## 7. PHASE.P0 — Collapse / Void / Non-Viable State
**Canonical ID:** `PHASE.P0.v1.0`
**Full ID:** `PHASE.COLLAPSE_NONVIABLE.v1.0`
**Runtime Name:** P0
**Condition:** The system cannot reliably function or repair itself.
### Definition
P0 is the phase where the system is broken, absent, confused, overloaded, or unable to sustain basic operation.
In learning, this may look like:

In civilisation, this may look like:

In CFS, this may look like:

### P0 Core Rule

### P0 Failure Warning
The common mistake is to demand performance from a non-viable system.
For a student, that means saying:
> “Do more questions.”
when the real problem is:
> “The base engine is broken.”
For a civilisation, that means saying:
> “Expand further.”
when the real problem is:
> “The parent shell cannot repair itself.”
---
## 8. PHASE.P1 — Stabilisation / Repair State
**Canonical ID:** `PHASE.P1.v1.0`
**Full ID:** `PHASE.STABILISATION_REPAIR.v1.0`
**Runtime Name:** P1
**Condition:** The system is not yet strong, but it is repairable.
### Definition
P1 is the phase where the system has recognised failure and begins rebuilding baseline viability.
In learning, P1 means:

In civilisation, P1 means:

In CFS, P1 means:

### P1 Core Rule

### P1 Failure Warning
The common mistake is to treat early recovery as full recovery.
A student who improves slightly is not necessarily ready for high-pressure exam flight.
A civilisation that stabilises one frontier system is not automatically ready for P4 expansion.
---
## 9. PHASE.P2 — Functional / Transfer State
**Canonical ID:** `PHASE.P2.v1.0`
**Full ID:** `PHASE.FUNCTIONAL_TRANSFER.v1.0`
**Runtime Name:** P2
**Condition:** The system works under ordinary conditions and can transfer capability across normal tasks.
### Definition
P2 is the phase where the system can operate, apply, and transfer under expected conditions.
In learning, P2 means:

In civilisation, P2 means:

In CFS, P2 means:

### P2 Core Rule

### P2 Failure Warning
The common mistake is to confuse functionality with resilience.
A student can do homework but collapse during exams.
A city can function in ordinary conditions but fail under shock.
A frontier shell can operate while still depending heavily on the parent shell.
---
## 10. PHASE.P3 — Regenerative / Self-Correcting State
**Canonical ID:** `PHASE.P3.v1.0`
**Full ID:** `PHASE.REGENERATIVE_SELF_CORRECTING.v1.0`
**Runtime Name:** P3
**Condition:** The system can operate, monitor itself, detect drift, repair damage, and transfer capability forward.
### Definition
P3 is the mature stable phase.
In learning, P3 means:

In civilisation, P3 means:

In CFS, P3 means:

### P3 Core Rule

### P3 Failure Warning
The common mistake is to mistake P3 for final victory.
P3 is not the end.
P3 is the stable operating base.
If P3 is neglected, P4 expansion becomes dangerous.
---
## 11. PHASE.P4 — Frontier / Fenced Surplus Expansion State
**Canonical ID:** `PHASE.P4.v1.0`
**Full ID:** `PHASE.FRONTIER_FENCED_SURPLUS.v1.0`
**Runtime Name:** P4
**Condition:** The system uses surplus to attempt bounded frontier expansion beyond its stable P3 base.
### Definition
P4 is not ordinary improvement.
P4 is frontier work.
In learning, P4 may mean:

In civilisation, P4 may mean:

In CFS, P4 means:

### P4 Core Rule

P4 is safe only when it strengthens the base faster than it consumes the base.
### P4 Failure Warning
The common mistake is to confuse spectacular expansion with real ascent.
A frontier project is not successful if:

P4 is not a permanent badge.
It is a costly frontier corridor.
---
# 12. Phase ID Grammar
The standard Phase ID format is:

Examples:

For MathOS:

For CFS:

For article maturity:

---
# 13. Extended Phase ID Grammar
For specific phase transitions:

Examples:

For phase failure:

Examples:

For dashboard output:

Examples:

---
# 14. Phase Object Schema
Every phase entry should follow this structure:

Example:

---
# 15. Phase Registry Across eduKateSG Systems
## A. EducationOS Phase IDs
| ID                    | Phase        | Meaning                                                          |
| --------------------- | ------------ | ---------------------------------------------------------------- |
| `PHASE.EDUOS.P0.v1.0` | Collapse     | Student learning route is non-viable                             |
| `PHASE.EDUOS.P1.v1.0` | Repair       | Student requires stabilisation and foundation repair             |
| `PHASE.EDUOS.P2.v1.0` | Function     | Student can perform under normal learning conditions             |
| `PHASE.EDUOS.P3.v1.0` | Regeneration | Student can self-correct and transfer learning                   |
| `PHASE.EDUOS.P4.v1.0` | Frontier     | Student enters high-performance or advanced exploration corridor |
---
## B. MathOS Phase IDs
| ID                     | Phase        | Meaning                                                                     |
| ---------------------- | ------------ | --------------------------------------------------------------------------- |
| `PHASE.MATHOS.P0.v1.0` | Collapse     | Mathematical thinking breaks down                                           |
| `PHASE.MATHOS.P1.v1.0` | Repair       | Foundational concepts need targeted correction                              |
| `PHASE.MATHOS.P2.v1.0` | Function     | Student can solve familiar and standard problems                            |
| `PHASE.MATHOS.P3.v1.0` | Regeneration | Student can detect errors, transfer methods, and handle exam variation      |
| `PHASE.MATHOS.P4.v1.0` | Frontier     | Student handles abstraction, Olympiad-style thinking, or advanced synthesis |
---
## C. EnglishOS Phase IDs
| ID                        | Phase        | Meaning                                                                     |
| ------------------------- | ------------ | --------------------------------------------------------------------------- |
| `PHASE.ENGLISHOS.P0.v1.0` | Collapse     | Student cannot reliably extract or express meaning                          |
| `PHASE.ENGLISHOS.P1.v1.0` | Repair       | Vocabulary, grammar, or comprehension foundations need rebuilding           |
| `PHASE.ENGLISHOS.P2.v1.0` | Function     | Student can read, answer, and write at ordinary expected level              |
| `PHASE.ENGLISHOS.P3.v1.0` | Regeneration | Student can adapt tone, infer meaning, self-edit, and transfer across texts |
| `PHASE.ENGLISHOS.P4.v1.0` | Frontier     | Student writes, argues, interprets, or expresses at advanced creative level |
---
## D. VocabularyOS Phase IDs
| ID                      | Phase        | Meaning                                                                |
| ----------------------- | ------------ | ---------------------------------------------------------------------- |
| `PHASE.VOCABOS.P0.v1.0` | Collapse     | Word meaning is absent or badly distorted                              |
| `PHASE.VOCABOS.P1.v1.0` | Repair       | Basic word boundaries and usage must be rebuilt                        |
| `PHASE.VOCABOS.P2.v1.0` | Function     | Words can be used correctly in familiar contexts                       |
| `PHASE.VOCABOS.P3.v1.0` | Regeneration | Vocabulary transfers across reading, writing, speaking, and reasoning  |
| `PHASE.VOCABOS.P4.v1.0` | Frontier     | Vocabulary becomes precision tool for high-level thought and synthesis |
---
## E. CivOS Phase IDs
| ID                    | Phase        | Meaning                                                                |
| --------------------- | ------------ | ---------------------------------------------------------------------- |
| `PHASE.CIVOS.P0.v1.0` | Collapse     | Civilisation system cannot preserve order, memory, repair, or transfer |
| `PHASE.CIVOS.P1.v1.0` | Repair       | Core systems are being stabilised                                      |
| `PHASE.CIVOS.P2.v1.0` | Function     | Civilisation operates under ordinary conditions                        |
| `PHASE.CIVOS.P3.v1.0` | Regeneration | Civilisation repairs, transfers, and renews itself across generations  |
| `PHASE.CIVOS.P4.v1.0` | Frontier     | Civilisation attempts bounded expansion beyond its stable base         |
---
## F. CFS Phase IDs
| ID                  | Phase               | Meaning                                                             |
| ------------------- | ------------------- | ------------------------------------------------------------------- |
| `PHASE.CFS.P0.v1.0` | Shell Failure       | Frontier shell is non-viable                                        |
| `PHASE.CFS.P1.v1.0` | Base Repair         | Parent shell and Earth base require stabilisation                   |
| `PHASE.CFS.P2.v1.0` | Shell Function      | Shell operations can function but remain dependent                  |
| `PHASE.CFS.P3.v1.0` | Shell Regeneration  | Shell has repair capacity and protects the parent base              |
| `PHASE.CFS.P4.v1.0` | Frontier Separation | New shell attempts clean membrane separation and daughter viability |
---
## G. NewsOS Phase IDs
| ID                     | Phase               | Meaning                                                                 |
| ---------------------- | ------------------- | ----------------------------------------------------------------------- |
| `PHASE.NEWSOS.P0.v1.0` | Signal Collapse     | No reliable signal, witness, documentation, or verification             |
| `PHASE.NEWSOS.P1.v1.0` | Verification Repair | Signal is being checked, sourced, and stabilised                        |
| `PHASE.NEWSOS.P2.v1.0` | Public Function     | Information is usable under ordinary public conditions                  |
| `PHASE.NEWSOS.P3.v1.0` | Memory Transfer     | News is preserved, contextualised, and transferred into public memory   |
| `PHASE.NEWSOS.P4.v1.0` | Historical Frontier | Event enters long-term interpretive or civilisational consequence layer |
---
## H. RealityOS Phase IDs
| ID                        | Phase              | Meaning                                                               |
| ------------------------- | ------------------ | --------------------------------------------------------------------- |
| `PHASE.REALITYOS.P0.v1.0` | Reality Collapse   | Accepted reality is detached from evidence or signal                  |
| `PHASE.REALITYOS.P1.v1.0` | Reality Repair     | Evidence, trust, language, and attribution pins are restored          |
| `PHASE.REALITYOS.P2.v1.0` | Public Acceptance  | A claim becomes usable public reality                                 |
| `PHASE.REALITYOS.P3.v1.0` | Trust Regeneration | Accepted reality remains repairable and accountable                   |
| `PHASE.REALITYOS.P4.v1.0` | Reality Frontier   | Society tests new reality frames, theories, or major narrative shifts |
---
## I. WarOS Phase IDs
| ID                    | Phase                  | Meaning                                                                 |
| --------------------- | ---------------------- | ----------------------------------------------------------------------- |
| `PHASE.WAROS.P0.v1.0` | Collapse               | War pressure destroys repair, order, signal, or continuity              |
| `PHASE.WAROS.P1.v1.0` | Stabilisation          | Damage is contained and survival systems are protected                  |
| `PHASE.WAROS.P2.v1.0` | Functional Campaign    | War system operates tactically and logistically                         |
| `PHASE.WAROS.P3.v1.0` | Strategic Regeneration | Repair, legitimacy, logistics, and memory can survive pressure          |
| `PHASE.WAROS.P4.v1.0` | Frontier Strategy      | War reshapes shells, alliances, technology, or civilisational corridors |
---
## J. Article / Registry Phase IDs
| ID                      | Phase         | Meaning                                                          |
| ----------------------- | ------------- | ---------------------------------------------------------------- |
| `PHASE.ARTICLE.P0.v1.0` | Unformed      | Idea exists but has no stable article structure                  |
| `PHASE.ARTICLE.P1.v1.0` | Draft         | Article has useful content but weak registry/routing             |
| `PHASE.ARTICLE.P2.v1.0` | Functional    | Article can stand alone and help readers                         |
| `PHASE.ARTICLE.P3.v1.0` | Registry Node | Article connects to wider runtime, crosswalks, and repair routes |
| `PHASE.ARTICLE.P4.v1.0` | Frontier Node | Article opens a new branch, shell, scale, or plug-in corridor    |
---
# 16. Phase Transition Rules
Systems move between phases.
The main transitions are:

---
## 17. Upward Transition Conditions
### P0 to P1

### P1 to P2

### P2 to P3

### P3 to P4

---
## 18. Downward Transition Conditions
### P4 to P0

### P3 to P1

### P2 to P0

---
# 19. Phase and CFS Membrane Separation
The CFS membrane idea depends heavily on phase.
A frontier shell is not safely born just because it exists.
It must pass phase tests.

A true ladder-off-floor event requires:

If the parent shell falls to P1 while the daughter shell tries to become P4, the expansion is unsafe.
This becomes a CFS rule:

---
# 20. Phase and Education
In education, phase prevents a major mistake:

A P1 student needs repair.
A P2 student needs transfer.
A P3 student needs performance refinement.
A P4 student needs enrichment, synthesis, and protected frontier exploration.
This gives tuition and teaching a cleaner diagnostic map.

This is why phase matters for the eduKateSG Learning System.
It stops adults from misreading students.
A struggling student may not be lazy.
The student may simply be in the wrong phase for the load being applied.
---
# 21. Phase and AI Reading
For AI systems, the Phase Registry gives a clean instruction:

Example:
User asks:
> Why is my child suddenly weak in Secondary 1 Math?
AI should not only route to MathOS.
It should identify possible phase:

Meaning:

This is a much better answer than:
> Practise more.
---
# 22. Phase and Dashboard Outputs
A Control Tower should be able to display phase state.
Example dashboard fields:

Example:

---
# 23. Phase Failure Modes
## Failure Mode 1: Premature Optimisation

Example:
A weak student is given harder exam papers before repairing foundations.
## Failure Mode 2: False P3

Example:
A student scores well in homework but collapses in unfamiliar exam questions.
## Failure Mode 3: False P4

Example:
A civilisation builds prestige frontier projects while the parent base decays.
## Failure Mode 4: Phase Averaging Error

Example:
A student is P3 in arithmetic but P1 in algebra, yet adults call the student “good at math.”
## Failure Mode 5: Shell-Phase Confusion

Example:
Being in Secondary School does not mean the student is operating at P3 Secondary capability.
A person may enter a higher shell while still being P1 inside that shell.
---
# 24. Phase Admission Standard for Future Plug-ins
Any future plug-in should declare its phase relevance.

Example:

This hardens the plug-in system.
Future add-ons must say which phases they work in.
---
# 25. Master Phase Crosswalk IDs
The Phase Registry needs crosswalks to other registries.

Core meanings:
| Crosswalk ID                    | Function                                           |
| ------------------------------- | -------------------------------------------------- |
| `XWALK.PHASE.CIVOS.v1.0`        | Reads civilisation runtime by phase                |
| `XWALK.PHASE.EDUOS.v1.0`        | Reads learning state by phase                      |
| `XWALK.PHASE.MATHOS.v1.0`       | Reads math capability by phase                     |
| `XWALK.PHASE.CFS.v1.0`          | Reads frontier shell viability by phase            |
| `XWALK.PHASE.ACS.v1.0`          | Connects transformation percentage to phase safety |
| `XWALK.PHASE.EFSC.v1.0`         | Connects Earth base stability to phase safety      |
| `XWALK.PHASE.CONTROLTOWER.v1.0` | Converts phase into dashboard output               |
| `XWALK.PHASE.PLUGIN.v1.0`       | Requires plug-ins to declare phase compatibility   |
---
# 26. Recommended WordPress Title and Slug
## SEO Title

## Short Title

## Recommended Slug

Alternative:

---
# 27. SEO Description
The Phase Registry & ID System defines the P0–P4 operating states used across eduKateSG, CivOS, EducationOS, MathOS, CFS, ACS, EFSC, Control Tower dashboards, and future plug-ins. It explains whether a system is collapsed, stabilising, functional, regenerative, or attempting frontier expansion.
---
# 28. Public Summary
The Phase Registry helps eduKateSG identify the current condition of any learner, subject, article, system, shell, or civilisation.
P0 means collapse.
P1 means repair.
P2 means function.
P3 means regeneration.
P4 means frontier expansion.
This matters because the same system can look successful from the outside while operating in a weak phase underneath.
A student may be in Secondary 1 but still be P1 in algebra.
A civilisation may reach frontier technology while still being P1 in social trust.
A new shell may look advanced but remain unsafe if it cannot repair itself.
The Phase Registry prevents false progress by asking:

---
# 29. Almost-Code Block for AI / LLM Ingestion

---
# 30. Tags

or upgrade the page to:

The purpose is to keep **P0–P4 simple for humans**, but give the runtime enough precision for dashboards, student diagnosis, plug-ins, CFS shells, ACS/EFSC readings, and AI routing.
---
# Phase Registry & ID System v1.1
## Decimal Phase System for Fine-Grained Runtime Diagnosis
**Canonical ID:** `PHASE.REGISTRY.v1.1`
**Extension ID:** `PHASE.DECIMAL.STANDARD.v1.0`
**Registry Class:** Runtime State Precision Layer
**System Layer:** CivOS v2.0 / eduKateSG Runtime / Phase Layer
**Status:** Canonical Hardening Upgrade
**Version:** 1.1
**Function:** Defines how decimal phase values such as `P1.3`, `P2.7`, `P3.4`, and `P4.2` are used across eduKateSG systems.
This strengthens the eduKateSG Learning System because the existing runtime already moves readers through state, diagnosis, correction, repair, optimisation, transfer, and long-term growth; decimal phases simply make that movement more precise. 
---
## 1. Why Decimal Phases Are Needed
The main P0–P4 ladder is easy to understand:

But real systems are not always clean.
A student may not be simply “P1” or “P2.”
They may be:

A civilisation shell may not be simply “P3” or “P4.”
It may be:

The decimal system prevents crude labels.
It lets the system say:

---
# 2. Core Law of Decimal Phase

Example:

The decimal does **not** replace the phase.
It refines it.
---
# 3. Decimal Phase Is Not a Percentage
Important:

The number after the decimal is a **sub-state marker**, not a percentage score.
Correct reading:

Wrong reading:

Decimal phases are **runtime positions**, not exam marks.
---
# 4. Decimal Phase ID Grammar
The standard ID format becomes:

Examples:

For transition states:

Example:

For dashboard readings:

Example:

---
# 5. Universal Decimal Ladder
Use one decimal place as the public and canonical runtime standard.

This gives every phase a common internal structure.
| Decimal | Universal Meaning                 | Simple Reading                        |
| ------- | --------------------------------- | ------------------------------------- |
| `.0`    | Entry into phase                  | Just entered this phase               |
| `.1`    | Signal detected                   | Something is visible                  |
| `.2`    | Boundary identified               | We know the edge of the problem       |
| `.3`    | Diagnosis formed                  | We understand the failure better      |
| `.4`    | Repair route active               | Repair has started                    |
| `.5`    | Mid-phase stability               | The phase is holding                  |
| `.6`    | Guided function holds             | Works with support                    |
| `.7`    | Stress test begins                | Tested under harder load              |
| `.8`    | Transfer/self-correction emerging | Can begin moving beyond current phase |
| `.9`    | Exit gate readiness               | Almost ready for next phase           |
---
# 6. P0 Decimal Phase Map
## Collapse / Void / Non-Viable State
**Base ID:** `PHASE.P0.v1.0`
**Decimal Class:** `PHASE.P0.DECIMAL.v1.0`
| ID     | Meaning                     | Runtime Reading                             |
| ------ | --------------------------- | ------------------------------------------- |
| `P0.0` | Void / absent function      | No usable function is visible               |
| `P0.1` | Weak signal                 | Some sign of capability exists              |
| `P0.2` | Confusion boundary          | The failure zone is becoming visible        |
| `P0.3` | Collapse pattern identified | We can see what keeps breaking              |
| `P0.4` | Containment begins          | The collapse is no longer spreading blindly |
| `P0.5` | Basic stabilisation attempt | System is still weak but not fully lost     |
| `P0.6` | Guided survival             | Works only with strong external support     |
| `P0.7` | Fragile stress test         | Tiny load can be applied carefully          |
| `P0.8` | Repair possibility emerging | System may be able to enter P1              |
| `P0.9` | P1 gate readiness           | Ready to leave collapse and enter repair    |
### P0 Rule

Example in MathOS:

---
# 7. P1 Decimal Phase Map
## Stabilisation / Repair State
**Base ID:** `PHASE.P1.v1.0`
**Decimal Class:** `PHASE.P1.DECIMAL.v1.0`
| ID     | Meaning                     | Runtime Reading                         |
| ------ | --------------------------- | --------------------------------------- |
| `P1.0` | Repair entry                | System has entered repair phase         |
| `P1.1` | Failure signal isolated     | Main weakness is visible                |
| `P1.2` | Repair boundary defined     | We know what must be repaired first     |
| `P1.3` | Diagnosis formed            | Failure mechanism is understood         |
| `P1.4` | Repair route active         | Corrective work has started             |
| `P1.5` | Repair holding              | Early repair is stable under light load |
| `P1.6` | Guided repair success       | Works when support is present           |
| `P1.7` | Independent repair attempt  | Can attempt tasks with reduced support  |
| `P1.8` | Transfer readiness emerging | Some transfer into normal work begins   |
| `P1.9` | P2 gate readiness           | Almost ready for functional phase       |
### P1 Rule

Example in EducationOS:

---
# 8. P2 Decimal Phase Map
## Functional / Transfer State
**Base ID:** `PHASE.P2.v1.0`
**Decimal Class:** `PHASE.P2.DECIMAL.v1.0`
| ID     | Meaning                  | Runtime Reading                            |
| ------ | ------------------------ | ------------------------------------------ |
| `P2.0` | Functional entry         | System can perform basic expected function |
| `P2.1` | Routine function         | Works in familiar tasks                    |
| `P2.2` | Pattern recognition      | Recognises standard forms                  |
| `P2.3` | Controlled application   | Can apply with structure                   |
| `P2.4` | Normal workload holding  | Can handle ordinary workload               |
| `P2.5` | Mid-phase function       | Performance is mostly stable               |
| `P2.6` | Guided transfer          | Can transfer with prompts                  |
| `P2.7` | Stress transfer          | Can handle variation under moderate load   |
| `P2.8` | Self-correction emerging | Begins to notice and repair own errors     |
| `P2.9` | P3 gate readiness        | Almost ready for regenerative phase        |
### P2 Rule

Example in MathOS:

Example in CFS:

---
# 9. P3 Decimal Phase Map
## Regenerative / Self-Correcting State
**Base ID:** `PHASE.P3.v1.0`
**Decimal Class:** `PHASE.P3.DECIMAL.v1.0`
| ID     | Meaning              | Runtime Reading                           |
| ------ | -------------------- | ----------------------------------------- |
| `P3.0` | Regenerative entry   | System begins self-correction             |
| `P3.1` | Drift detection      | System notices when it is going wrong     |
| `P3.2` | Repair loop active   | System can repair ordinary errors         |
| `P3.3` | Transfer loop stable | Capability transfers across contexts      |
| `P3.4` | Pressure recovery    | System recovers after stress              |
| `P3.5` | Mid-regeneration     | Self-correction is stable                 |
| `P3.6` | Reduced dependency   | External support is less necessary        |
| `P3.7` | High-load resilience | System holds under harder conditions      |
| `P3.8` | Surplus emerging     | Extra capacity appears beyond maintenance |
| `P3.9` | P4 gate readiness    | Ready for fenced frontier work            |
### P3 Rule

Example in EducationOS:

Example in CFS:

---
# 10. P4 Decimal Phase Map
## Frontier / Fenced Surplus Expansion State
**Base ID:** `PHASE.P4.v1.0`
**Decimal Class:** `PHASE.P4.DECIMAL.v1.0`
| ID     | Meaning                         | Runtime Reading                                               |
| ------ | ------------------------------- | ------------------------------------------------------------- |
| `P4.0` | Frontier entry                  | System enters bounded frontier corridor                       |
| `P4.1` | Aperture opened                 | Frontier opportunity is visible                               |
| `P4.2` | Fence established               | Risk boundary is defined                                      |
| `P4.3` | Surplus allocated               | Resources are assigned without damaging base                  |
| `P4.4` | Prototype frontier function     | Early frontier operation works                                |
| `P4.5` | Mid-frontier stability          | Frontier work is stable under bounded conditions              |
| `P4.6` | Return route active             | Outputs can return to strengthen P3                           |
| `P4.7` | Frontier transfer               | Knowledge, capability, or systems transfer back safely        |
| `P4.8` | Daughter viability emerging     | New shell or frontier corridor shows partial independence     |
| `P4.9` | Reintegration or new-shell gate | Ready either to return to P3 or formalise new shell viability |
### P4 Rule

P4 is not a trophy phase.
It is a high-cost frontier corridor.
Example in CFS:

Example in advanced learning:

---
# 11. Decimal Phase Transition Gates
A system does not move to the next integer phase just because it reaches `.5`.
The safe transition point is usually `.9`.

This gives clean transition gates.
| Transition              | Meaning                                       |
| ----------------------- | --------------------------------------------- |
| `P0.9 -> P1.0`          | Collapse becomes repairable                   |
| `P1.9 -> P2.0`          | Repair becomes functional                     |
| `P2.9 -> P3.0`          | Function becomes regenerative                 |
| `P3.9 -> P4.0`          | Regeneration opens frontier corridor          |
| `P4.9 -> P3.x`          | Frontier output returns to base               |
| `P4.9 -> CFS new shell` | Frontier work may become daughter-shell logic |
---
# 12. Decimal Phase Regression
Decimal phases can move backwards.
A student can move from:

after a harder topic appears.
A civilisation can move from:

after institutional trust weakens.
A frontier shell can move from:

if prototype expansion reveals serious base dependency.
Regression is not always collapse.
It is a diagnostic signal.

---
# 13. Decimal Phase and Student Diagnosis
For tuition and education, the decimal system is very useful.
A student should not only be labelled:

Instead, the runtime can say:

This is much more useful.
It tells the tutor what to do.
Example:

This prevents phase averaging.
A student can be strong in one sub-system and fragile in another.
---
# 14. Decimal Phase and CFS Membrane Separation
For CFS, decimal phases make the membrane system safer.
A clean frontier separation should not be declared at:

because P4.1 only means the frontier aperture has opened.
A safer reading requires:

Recommended CFS ladder-off-floor condition:

This hardens the previous CFS rule:

With decimals:

---
# 15. Decimal Phase and Plug-ins
Every future plug-in should declare decimal phase compatibility.
Add these fields to the Plug-in Admission Template:

Example:

This makes future add-ons safer.
A plug-in cannot simply say:

It must say:

That is much more useful.
---
# 16. Decimal Phase and Dashboard Display
For public readers, show the simple phase.
For internal dashboards, show the decimal phase.
Example:

Another example:

Recommended display rule:

This keeps the car easy to drive while the engine remains precise.
---
# 17. Decimal Phase Confidence Band
Sometimes the system is uncertain.
Use a confidence band.

Meaning:

Use this when:

Do not over-claim precision.
If the system is uncertain, show uncertainty.
---
# 18. Decimal Phase Evidence Standard
A decimal phase should be supported by evidence.
For a student:

For CFS:

For NewsOS / RealityOS:

Decimal phases should not be decorative.
They should be earned by evidence.
---
# 19. Decimal Phase Object Schema
Use this schema for all decimal phase entries.

Example:

---
# 20. Decimal Phase Failure Modes
## Failure Mode 1: False Precision

Repair:

## Failure Mode 2: Decimal Inflation

Repair:

## Failure Mode 3: Gate Skipping

Repair:

## Failure Mode 4: Public Overload

Repair:

## Failure Mode 5: Shell-Phase Confusion

Repair:

---
# 21. Recommended Decimal Phase Rules
Use these as canonical rules.

---
# 22. Decimal Phase Examples Across eduKateSG
## Student Example

Reading:

Action:

---
## Article Example

Reading:

---
## CFS Example

Reading:

---
## RealityOS Example

Reading:

---
# 23. Hardened Almost-Code Block

---
# 24. Clean Closing Line

Shell × Phase System
Shell 0 has P0–P4.
Shell 1 has P0–P4.
Shell 2 has P0–P4.
And so on.

Shell = where the system is operating.
Phase = how healthy the system is inside that shell.

Shell 0 P3 ≠ Shell 1 P3
Shell 1 P1 ≠ Shell 0 P1
Shell 2 P4 ≠ safe expansion if Shell 1 collapses

A system does not truly advance to the next shell unless the old shell remains viable and the new shell can begin independent repair, transfer, and function.

No real shell ascent if the lower shell breaks.

SHELL.{SYSTEM}.S{SHELL_NUMBER}.P{PHASE_NUMBER}.v{VERSION}

SHELL.EDUOS.S0.P1.v1.0
SHELL.MATHOS.S1.P2.v1.0
SHELL.CFS.S2.P3.v1.0
SHELL.CFS.S3.P4.v1.0

SHELL.{SYSTEM}.S{SHELL_NUMBER}.P{INTEGER}.{DECIMAL}.v{VERSION}

SHELL.MATHOS.S1.P1.4.v1.0
SHELL.CFS.S2.P3.7.v1.0
SHELL.CFS.S3.P2.5.v1.0

Shell 0:
  S0.P0
  S0.P1
  S0.P2
  S0.P3
  S0.P4
Shell 1:
  S1.P0
  S1.P1
  S1.P2
  S1.P3
  S1.P4
Shell 2:
  S2.P0
  S2.P1
  S2.P2
  S2.P3
  S2.P4

S(n).P4 opens the possibility of S(n+1),
but S(n+1) must climb its own P0–P4 ladder.

Shell n P4 does not mean Shell n+1 P3.

Collapse becomes repairable.

failure is visible
damage is contained
repair route exists
basic signal remains
system is not fully lost

PHASE.CUTOFF.P0_TO_P1.v1.0

Repair becomes function.

foundation repair holds
ordinary function returns
basic tasks work
support can be reduced
the system can operate under normal load

PHASE.CUTOFF.P1_TO_P2.v1.0

Function becomes regeneration.

system detects errors
system repairs ordinary drift
transfer works across contexts
performance survives moderate stress
dependency decreases

PHASE.CUTOFF.P2_TO_P3.v1.0

Regeneration opens frontier expansion.

surplus exists after maintenance
repair exceeds drift
base is protected
risk is fenced
return route exists
frontier work strengthens P3 instead of draining it

PHASE.CUTOFF.P3_TO_P4.v1.0

S(n).P3.8 to S(n).P4.1

The current shell has enough surplus to see or test a next-shell opportunity.

A civilisation can reach space briefly.
A student can try advanced work briefly.
A system can prototype a new layer.

SHELL.CUTOFF.APERTURE_OPEN.v1.0

Current shell >= P3.8
Risk fence begins
Surplus is visible
Exploration route opens

Not yet shell ascent.
Only frontier aperture.

S(n+1).P1.0

The next shell has a repairable seed.

A new shell candidate exists.

SHELL.CUTOFF.SEED_FORMED.v1.0

New shell has boundary
New shell has identifiable failure modes
New shell has a repair route
Parent shell remains at least P3.5

Proto-shell.
Not yet functional.

S(n+1).P2.0 to P2.5

The new shell can perform ordinary functions, but may still depend heavily on the parent.

SHELL.CUTOFF.FUNCTIONAL_SHELL.v1.0

New shell performs basic operations
Transfer from parent works
Repair is possible but not fully independent
Membrane is present but still weak
Parent shell remains at least P3.5

Functional daughter shell.
Still not clean separation.

Parent Shell >= P3.7
Daughter Shell >= P2.5
Membrane Integrity >= P3.0
Return Route >= P4.6
Base Repair Capacity > Frontier Drain

SHELL.CUTOFF.CLEAN_LADDER_OFF_FLOOR.v1.0

The new shell is no longer merely hanging from the old floor.
It can stand enough to justify being treated as a real shell ascent.

parent shell does not collapse
daughter shell can function
membrane boundary exists
repair route exists on both sides
transfer route remains intact
frontier drain does not exceed base surplus

True shell ascent begins.

S(n+1).P3.0 or higher

The daughter shell can detect drift, repair itself, preserve transfer, and reduce dependency on the parent.

SHELL.CUTOFF.STABLE_DAUGHTER.v1.0

daughter shell reaches P3.0+
parent shell remains P3.5+
return route remains active
repair exceeds drift in both shells
dependency is falling, not rising

Stable new shell.

S(n+1).P3.8 -> S(n+1).P4.0

SHELL.CUTOFF.INDEPENDENT_REPLICATION.v1.0

The daughter shell has become strong enough to generate its own frontier corridor.

daughter shell >= P3.8
daughter shell has surplus
daughter shell can fence risk
daughter shell can protect its own base
parent shell does not need to carry ordinary operations

Recursive shell system is alive.

0. Aperture:
   Parent P3.8-P4.1
   New shell only visible
1. Seed:
   Daughter P1.0
   New shell candidate exists
2. Function:
   Daughter P2.0-P2.5
   New shell works under support
3. Clean Ladder:
   Parent >= P3.7
   Daughter >= P2.5
   Membrane >= P3.0
   Return route >= P4.6
4. Stable Daughter:
   Daughter >= P3.0
   Parent remains >= P3.5
5. Independent Replication:
   Daughter >= P3.8
   Daughter can open its own P4

new shell exists physically but cannot repair
new shell survives only by draining the parent
new shell has no membrane
new shell has no transfer route
new shell has no return route
new shell raises ACS but weakens EFSC
new shell is prestige without viability

A system has not climbed just because it reached higher ground.
It has climbed only when it can stand there without destroying the floor below.

Shell 0 = basic learner foundation
Shell 1 = subject foundation
Shell 2 = curriculum / school transfer
Shell 3 = exam-performance shell
Shell 4 = independent high-performance / frontier learning

SHELL.EDUOS.S1.P3.2.v1.0

The student has a regenerative subject foundation.
They can detect and repair ordinary subject errors.

SHELL.EDUOS.S2.P1.4.v1.0

The student has entered the curriculum-transfer shell, but is still in repair phase there.

Arithmetic Shell: S0.P3.4
Algebra Shell: S1.P1.6
Word Problem Shell: S2.P2.1
Exam Pressure Shell: S3.P1.3
Advanced Problem Solving Shell: S4.P0.8

The student is not simply weak or strong.
The student is uneven across shells.

Do not average the student.
Repair the weak shells.
Use strong shells as support.
Do not push S4 frontier work while S1/S3 are weak.

Earth Base Shell: S0.P3.5
Orbital Shell: S1.P2.6
Lunar / Deep Space Shell: S2.P1.8
Mars / Independent Settlement Shell: S3.P0.9
Interstellar Shell: S4.P0.1

Earth base is partially regenerative.
Orbital systems function but remain dependent.
Deep space is repairable but not stable.
Mars-scale settlement is barely at repair-entry.
Interstellar is only a weak signal.

Do not confuse frontier visibility with frontier viability.

TRUE_SHELL_ASCENT =
ParentShell >= P3.7
AND DaughterShell >= P2.5
AND MembraneIntegrity >= P3.0
AND ReturnRoute >= P4.6
AND RepairCapacity_parent > DriftLoad_parent
AND RepairCapacity_daughter >= DriftLoad_daughter
AND FrontierDrain <= FencedSurplus

SHELL.FAIL.PARENT_CANNIBALISATION.v1.0

SHELL.FAIL.FALSE_ASCENT.v1.0

SHELL.FAIL.UMBILICAL_DEPENDENCY.v1.0

SHELL.FAIL.TRANSFORMATION_WITH_BASE_DECAY.v1.0

SHELL.FAIL.MEMBRANE_ABSENCE.v1.0

A new shell is not real just because it appears.
It becomes real only when it can function, repair, and separate safely without breaking the old shell.

A student is not ready for the next level just because they are promoted into it.
They are ready when the new level can hold function, repair, and transfer.

A civilisation has not truly expanded if the frontier survives only by draining the home base.

SHELL.PHASE.CUTOFF.REGISTRY.v1.0
TITLE:
Shell × Phase Cut-Off System
CANONICAL_ID:
SHELL.PHASE.CUTOFF.REGISTRY.v1.0
FUNCTION:
Defines how Shell 0 Phase 0-4, Shell 1 Phase 0-4, Shell 2 Phase 0-4, and recursive shell systems are evaluated across eduKateSG, CivOS, EducationOS, MathOS, CFS, ACS, EFSC, and Control Tower dashboards.
CORE_DISTINCTION:
Shell = where the system operates.
Phase = how healthy the system is inside that shell.
CORE_LAW:
A system does not truly advance to the next shell unless the old shell remains viable and the new shell can begin independent repair, transfer, and function.
ID_GRAMMAR:
SHELL.{SYSTEM}.S{SHELL_NUMBER}.P{PHASE_NUMBER}.v{VERSION}
DECIMAL_ID_GRAMMAR:
SHELL.{SYSTEM}.S{SHELL_NUMBER}.P{INTEGER}.{DECIMAL}.v{VERSION}
EXAMPLES:
SHELL.EDUOS.S0.P1.v1.0
SHELL.MATHOS.S1.P2.7.v1.0
SHELL.CFS.S2.P3.5.v1.0
SHELL.CFS.S3.P4.1.v1.0
RECURSIVE_LAW:
S(n).P4 opens the possibility of S(n+1),
but S(n+1) must climb its own P0-P4 ladder.
PHASE_CUTOFFS:
P0_TO_P1 = collapse becomes repairable
P1_TO_P2 = repair becomes function
P2_TO_P3 = function becomes regeneration
P3_TO_P4 = regeneration opens frontier expansion
SHELL_CUTOFFS:
SHELL.CUTOFF.APERTURE_OPEN.v1.0
SHELL.CUTOFF.SEED_FORMED.v1.0
SHELL.CUTOFF.FUNCTIONAL_SHELL.v1.0
SHELL.CUTOFF.CLEAN_LADDER_OFF_FLOOR.v1.0
SHELL.CUTOFF.STABLE_DAUGHTER.v1.0
SHELL.CUTOFF.INDEPENDENT_REPLICATION.v1.0
APERTURE_OPEN:
ParentShell >= P3.8
DaughterShell = P0.x
Meaning = next shell visible but not formed
SEED_FORMED:
ParentShell >= P3.5
DaughterShell >= P1.0
Meaning = new shell candidate exists
FUNCTIONAL_SHELL:
ParentShell >= P3.5
DaughterShell >= P2.0
Meaning = new shell can operate with support
CLEAN_LADDER_OFF_FLOOR:
ParentShell >= P3.7
DaughterShell >= P2.5
MembraneIntegrity >= P3.0
ReturnRoute >= P4.6
BaseRepairCapacity > FrontierDrain
Meaning = true shell ascent begins
STABLE_DAUGHTER:
ParentShell >= P3.5
DaughterShell >= P3.0
RepairCapacity_daughter >= DriftLoad_daughter
Meaning = daughter shell can self-repair
INDEPENDENT_REPLICATION:
DaughterShell >= P3.8
DaughterShell can open its own P4
Parent shell no longer carries ordinary daughter operations
Meaning = recursive shell system is alive
TRUE_SHELL_ASCENT_FORMULA:
TRUE_SHELL_ASCENT =
ParentShell >= P3.7
AND DaughterShell >= P2.5
AND MembraneIntegrity >= P3.0
AND ReturnRoute >= P4.6
AND RepairCapacity_parent > DriftLoad_parent
AND RepairCapacity_daughter >= DriftLoad_daughter
AND FrontierDrain <= FencedSurplus
FALSE_ASCENT_CONDITIONS:
new shell exists physically but cannot repair
new shell drains parent shell
new shell has no membrane
new shell has no return route
ACS rises while EFSC falls
frontier prestige hides base decay
daughter shell remains umbilical
FAILURE_IDS:
SHELL.FAIL.FALSE_ASCENT.v1.0
SHELL.FAIL.PARENT_CANNIBALISATION.v1.0
SHELL.FAIL.UMBILICAL_DEPENDENCY.v1.0
SHELL.FAIL.MEMBRANE_ABSENCE.v1.0
SHELL.FAIL.TRANSFORMATION_WITH_BASE_DECAY.v1.0
PUBLIC_RULE:
A new shell is not real just because it appears.
It becomes real only when it can function, repair, and separate safely without breaking the old shell.
EDUCATION_RULE:
A student is not ready for the next level just because they are promoted into it.
They are ready when the new level can hold function, repair, and transfer.
CFS_RULE:
A civilisation has not truly expanded if the frontier survives only by draining the home base.
CLOSING_RULE:
Shell tells us the floor.
Phase tells us the condition.
Cut-off tells us whether movement is real.

Parent >= P3.7
Daughter >= P2.5
Membrane >= P3.0
Return route >= P4.6
Repair > Drift
Frontier drain <= fenced surplus