Article Registry / Tracking Ledger

This is the registry layer.

The earlier parts define why an article exists, how it is built, how it is approved, and how it is audited.

The registry does something different.

It keeps the whole article system visible.

Without a registry, pages get written one by one, but the stack becomes hard to see.
Some pages overlap.
Some pages become orphaned.
Some pages become powerful but are not protected.
Some pages need repair but are forgotten.
Some topic clusters remain incomplete because the missing nodes are not visible.

The registry solves that.

It is the control ledger for the whole eduKateSG article system.

Start Here: https://edukatesg.com/edukatesg-mission-control-tower/

Part I

What the Article Registry Does

The eduKateSG Article Registry / Tracking Ledger is the master record of all article assets.

Its job is to show:

what pages exist
why they exist
where they sit in the stack
what state they are in
what query corridor they serve
whether they are active, weak, under repair, or canonical
what is missing from the larger subject lattice

So the registry is not just an inventory.

It is a live control surface for article continuity, cluster strength, and system maintenance.

Part II

Core Functions of the Registry

1. Identity Control

Every article gets a stable ID.

This prevents confusion when titles change slightly or when several pages cover nearby themes.

2. Mission Visibility

Every page is attached to a mission class.

This prevents random accumulation of pages without clear purpose.

3. Stack Mapping

Every page is placed inside a subject corridor.

This shows whether a cluster is complete, weak, or missing critical nodes.

4. State Tracking

Every page carries a live operating state.

This makes it obvious which pages are:

candidates
under construction
active
under repair
canonical
ready to merge
ready to retire

5. Query Control

Each page is tied to a primary query and a query corridor.

This helps prevent cannibalization and topic blur.

6. Canonical Protection

The registry identifies which pages are stable anchors.

These pages should be updated carefully and linked to intentionally.

7. Gap Detection

The registry makes missing articles easier to see.

This is one of the most important functions.

When a subject stack is partially built, the registry shows:

missing transitions
missing diagnosis pages
missing glossary pages
missing cluster-support pages
missing canonical anchors

That means the registry is also a build tool.

Part III

Registry Logic

The registry should answer these questions at any time:

What articles exist?
What class does each article belong to?
What query corridor is each article serving?
What stack does it belong to?
What state is it currently in?
Does it support the wider system?
Is it weak, duplicated, isolated, or canonical?
What important pages are still missing?

That is the operating logic.

Part IV

eduKateSG Article Registry Fields

This is the recommended ledger structure.

Core Identity Fields

Article ID
Article Title
Working Title
URL
Primary Subject Stack
Secondary Subject Stack
Mission Class
Format Type

Mission Fields

Primary Mission
Secondary Missions
Why This Article Exists
Success Condition
Failure Condition

Reader Fields

Primary Reader
Secondary Reader
Reader State
Reader Need

Query Fields

Primary Query
Secondary Queries
Query Intent Type
Cannibalization Risk
Adjacent Pages

Stack Fields

Parent Page
Child Pages
Previous Route Page
Next Route Page
Cluster Role
Route Role

Operating Fields

Current State
Approval Status
Audit Status
Canonical Status
Priority Level
Repair Needed
Merge Candidate
Retire Candidate

Performance Fields

Publish Date
Last Review Date
Live Performance Notes
Reader Flow Notes
Search / AI Notes
Cluster Support Value
System Value Score

Control Fields

Owner / Writer
Reviewer
Next Action
Re-Audit Date
Protection Rule

Part V

Operating States for the Registry

Each article should always have one main state.

S0 — Candidate

The idea exists but is not approved yet.

S1 — Approved

The article has passed mission review and deserves construction.

S2 — In Construction

The article is currently being built.

S3 — Under Review

The draft exists and is waiting for approval.

S4 — Published

The page is live but still being observed.

S5 — Active

The page is working and adds value.

S6 — Repair

The page has value but needs rebuilding or tightening.

S7 — Expand

The page is working and should support child pages or deeper sub-pages.

S8 — Merge

The page has useful content but should not remain standalone.

S9 — Retire

The page should be removed, redirected, or replaced.

S10 — Canonical

The page is a protected reference anchor for its subject stack.

Part VI

Mission Class Codes

Use standard codes for quick sorting.

Suggested Mission Classes

AUTH — Authority
PROB — Problem / Diagnosis
TRAN — Transition
TRUST — Human trust / calming page
SUPP — Cluster support
CONV — Conversion-support
CTRL — Control tower / runtime page
TECH — Technical specification
CASE — Case / evidence page
FAQ — FAQ page
GLOS — Glossary page
CANON — Canonical anchor

These should be used consistently.

Part VII

Priority Levels

Each article should also have a priority rating.

P1 — Critical

This page is missing or weak, and the stack is materially worse without it.

P2 — Important

This page strongly improves the cluster and should be built or repaired soon.

P3 — Useful

This page adds support value but is not urgent.

P4 — Low Priority

This page can wait without serious system weakness.

Priority makes the system easier to manage.

Part VIII

Canonical Status Types

Not all important pages are equally important.

Use a separate canonical layer.

C0 — Not Canonical

Ordinary page.

C1 — Canonical Candidate

Page shows promise and may become an anchor.

C2 — Cluster Canonical

Strong reference page inside one subject stack.

C3 — System Canonical

High-value anchor used across many related stacks.

This is useful because some pages are important only within one corridor, while others become bigger centers of gravity.

Part IX

Registry Views

The registry should be readable in several ways.

1. Subject View

Shows all pages in:

Mathematics
English
Vocabulary
IGCSE
Additional Mathematics
PSLE
Secondary Mathematics
Local pages
Control Tower pages

This helps see subject completeness.

2. Mission View

Shows all pages by mission class:

authority pages
diagnosis pages
transition pages
trust pages
support pages

This helps see functional imbalance.

3. State View

Shows all pages by current operating state:

candidate
in construction
active
repair
canonical

This helps operational control.

4. Gap View

Shows missing nodes in each cluster.

This is one of the most powerful views because it helps build the next correct page instead of just the next random page.

5. Canonical View

Shows protected anchor pages.

This helps prevent accidental damage to important core pages.

Part X

Missing Node Detection

This is one of the main reasons the registry matters.

A strong subject cluster often needs more than just a few pages.

For example, a proper stack may need:

a definition page
a how-it-works page
a why-it-matters page
a common-failures page
an optimization page
a transition page
a parent guide
a FAQ page
a glossary node
a technical specification page
a canonical authority page

The registry makes it obvious when some of these are missing.

That means the registry is not passive.

It actively reveals what needs to be built next.

Part XI

Example Registry Entry

Example

Article ID: MC-PROB-MATH-S2-001
Article Title: Why Secondary 2 Mathematics Suddenly Feels Hard
Primary Stack: Secondary Mathematics
Mission Class: PROB
Format Type: Diagnosis
Primary Query: why secondary 2 math is hard
Primary Reader: worried parent of a Secondary 2 student
Cluster Role: diagnosis node
Parent Page: Secondary 2 Mathematics Tuition
Next Route Page: Signs Your Child Needs Help in Sec 2 Mathematics
Current State: S5 Active
Priority Level: P2 Important
Canonical Status: C1 Canonical Candidate
Cannibalization Risk: Medium
Repair Needed: No
System Value: Strong
Next Action: monitor and expand child pages

That is how a single page should appear in the registry.

Part XII

Registry Table Template

Use this as the core ledger structure.

Article ID	Title	Stack	Mission Class	Format	Primary Query	Reader	Cluster Role	State	Priority	Canonical	Parent Page	Next Page	Cannibalization Risk	Next Action
MC-PROB-MATH-S2-001	Why Secondary 2 Mathematics Suddenly Feels Hard	Secondary Math	PROB	Diagnosis	why sec 2 math is hard	Worried parent	Diagnosis node	S5 Active	P2	C1	Sec 2 Math Tuition	Signs Child Needs Help	Medium	Expand

You can later extend this with:

publish date
review date
audit result
system value score
internal links
AI notes

Part XIII

Article ID Convention

Use a clean naming logic.

Recommended format

MC-[MISSION]-[STACK]-[LEVEL]-[NUMBER]

Examples:

MC-AUTH-MATH-CORE-001
MC-PROB-MATH-S2-001
MC-TRAN-MATH-S2S3-001
MC-TRUST-AMATH-PARENT-001
MC-FAQ-IGCSE-Y10-001
MC-CTRL-VOCAB-CORE-001

This makes sorting easier and gives each page a durable identity.

Part XIV

Registry Regulations

These should govern the ledger.

Regulation 1

Every standalone article must have a registry entry.

Regulation 2

No article may enter Active state without a recorded mission and stack role.

Regulation 3

No page may become Canonical without live value evidence.

Regulation 4

No weak or duplicate page should remain hidden in the system without a recorded repair, merge, or retire action.

Regulation 5

Every subject stack should be reviewed for missing nodes using the registry, not guesswork.

Regulation 6

Title changes must not break identity continuity. The Article ID remains stable.

Regulation 7

The registry is the source of truth for article state, not memory alone.

Part XV

Fast Registry Workflow

The registry should run like this:

Idea enters registry -> gets Article ID -> gets Mission Class -> gets Stack Position -> gets State -> gets built -> gets reviewed -> gets published -> gets audited -> gets updated in ledger -> gets repaired, expanded, merged, retired, or canonized

That is the operating loop.

Part XVI

Registry Dashboard Reading

The registry should let eduKateSG answer fast:

which pages are our anchors?
which pages need repair?
which clusters are weak?
which transition stacks are incomplete?
which pages overlap too much?
which new pages should be written next?
which pages are ready to become canonical?
where are the missing nodes in Mathematics, English, Vocabulary, IGCSE, and local clusters?

That is what makes the registry useful.

Part XVII

Compact Registry Form

Use this when speed matters.

Fast Registry Entry

Article ID:
Title:
Stack:
Mission Class:
Format:
Primary Query:
Reader:
Cluster Role:
Parent Page:
Next Page:
State:
Priority:
Canonical Status:
Cannibalization Risk:
Next Action:

Part XVIII

Almost-Code Block

“`text id=”2r9g5m”
eduKateSG_Article_Registry_Tracking_Ledger_v1_0

REGISTRY_OBJECT = {
article_identity: {
article_id,
title,
working_title,
url,
primary_stack,
secondary_stack,
mission_class,
format_type
},

			
mission: {
    primary_mission,
    secondary_missions,
    why_exists,
    success_condition,
    failure_condition
},
reader: {
    primary_reader,
    secondary_reader,
    reader_state,
    reader_need
},
query: {
    primary_query,
    secondary_queries,
    query_intent,
    cannibalization_risk,
    adjacent_pages
},
stack_position: {
    parent_page,
    child_pages,
    previous_page,
    next_page,
    cluster_role,
    route_role
},
operations: {
    current_state,
    approval_status,
    audit_status,
    canonical_status,
    priority_level,
    repair_needed,
    merge_candidate,
    retire_candidate
},
performance: {
    publish_date,
    last_review_date,
    live_performance_notes,
    reader_flow_notes,
    search_ai_notes,
    cluster_support_value,
    system_value_score
},
control: {
    owner,
    reviewer,
    next_action,
    re_audit_date,
    protection_rule
}

		

}

STATE_CODES = {
S0: Candidate,
S1: Approved,
S2: In_Construction,
S3: Under_Review,
S4: Published,
S5: Active,
S6: Repair,
S7: Expand,
S8: Merge,
S9: Retire,
S10: Canonical
}

MISSION_CODES = {
AUTH,
PROB,
TRAN,
TRUST,
SUPP,
CONV,
CTRL,
TECH,
CASE,
FAQ,
GLOS,
CANON
}

PRIORITY_CODES = {
P1: Critical,
P2: Important,
P3: Useful,
P4: Low_Priority
}

CANONICAL_CODES = {
C0: Not_Canonical,
C1: Canonical_Candidate,
C2: Cluster_Canonical,
C3: System_Canonical
}

REGISTRY_RULES:
every_standalone_article_must_have_registry_entry
no_active_page_without_mission_and_stack_role
no_canonical_status_without_live_value
no_weak_page_without_recorded_action
title_changes_do_not_change_article_id
registry_is_source_of_truth_for_article_state

OPERATING_LOOP:
Idea
-> Registry_Entry
-> ID_Assignment
-> Mission_Class_Assignment
-> Stack_Position_Assignment
-> State_Assignment
-> Build
-> Review
-> Publish
-> Audit
-> Repair_Expand_Merge_Retire_or_Canonize
“`

Final Lock

The system now has six linked operating layers:

Mission Control Tower — why the articles exist
One-Panel Board — fast article judgment
Workflow + Technical Specifications + Regulations — how articles move and what governs them
Article Technical Specification Sheet — the engineering form for each page
Approval Form + Post-Publish Audit Form — launch control and reality check
Article Registry / Tracking Ledger — the master record of the whole article system

eduKateSG Learning System | Control Tower, Runtime, and Next Routes

This article is one node inside the wider eduKateSG Learning System.

At eduKateSG, we do not treat education as random tips, isolated tuition notes, or one-off exam hacks. We treat learning as a living runtime:

state -> diagnosis -> method -> practice -> correction -> repair -> transfer -> long-term growth

That is why each article is written to do more than answer one question. It should help the reader move into the next correct corridor inside the wider eduKateSG system: understand -> diagnose -> repair -> optimize -> transfer. Your uploaded spine clearly clusters around Education OS, Tuition OS, Civilisation OS, subject learning systems, runtime/control-tower pages, and real-world lattice connectors, so this footer compresses those routes into one reusable ending block.

Start Here

Learning Systems

Runtime and Deep Structure

Real-World Connectors

Subject Runtime Lane

How to Use eduKateSG

If you want the big picture -> start with Education OS and Civilisation OS
If you want subject mastery -> enter Mathematics, English, Vocabulary, or Additional Mathematics
If you want diagnosis and repair -> move into the CivOS Runtime and subject runtime pages
If you want real-life context -> connect learning back to Family OS, Bukit Timah OS, Punggol OS, and Singapore City OS

Why eduKateSG writes articles this way

eduKateSG is not only publishing content.
eduKateSG is building a connected control tower for human learning.

That means each article can function as:

a standalone answer,
a bridge into a wider system,
a diagnostic node,
a repair route,
and a next-step guide for students, parents, tutors, and AI readers.

Start Here: https://edukatesg.com/edukatesg-mission-control-tower/

eduKateSG.LearningSystem.Footer.v1.0

TITLE: eduKateSG Learning System | Control Tower / Runtime / Next Routes

FUNCTION:
This article is one node inside the wider eduKateSG Learning System.
Its job is not only to explain one topic, but to help the reader enter the next correct corridor.

CORE_RUNTIME:
reader_state -> understanding -> diagnosis -> correction -> repair -> optimisation -> transfer -> long_term_growth

CORE_IDEA:
eduKateSG does not treat education as random tips, isolated tuition notes, or one-off exam hacks.
eduKateSG treats learning as a connected runtime across student, parent, tutor, school, family, subject, and civilisation layers.

PRIMARY_ROUTES:
1. First Principles
   - Education OS
   - Tuition OS
   - Civilisation OS
   - How Civilization Works
   - CivOS Runtime Control Tower

2. Subject Systems
   - Mathematics Learning System
   - English Learning System
   - Vocabulary Learning System
   - Additional Mathematics

3. Runtime / Diagnostics / Repair
   - CivOS Runtime Control Tower
   - MathOS Runtime Control Tower
   - MathOS Failure Atlas
   - MathOS Recovery Corridors
   - Human Regenerative Lattice
   - Civilisation Lattice

4. Real-World Connectors
   - Family OS
   - Bukit Timah OS
   - Punggol OS
   - Singapore City OS

READER_CORRIDORS:
IF need == "big picture"
THEN route_to = Education OS + Civilisation OS + How Civilization Works

IF need == "subject mastery"
THEN route_to = Mathematics + English + Vocabulary + Additional Mathematics

IF need == "diagnosis and repair"
THEN route_to = CivOS Runtime + subject runtime pages + failure atlas + recovery corridors

IF need == "real life context"
THEN route_to = Family OS + Bukit Timah OS + Punggol OS + Singapore City OS

CLICKABLE_LINKS:
Education OS:
Education OS | How Education Works — The Regenerative Machine Behind Learning


Tuition OS:
Tuition OS (eduKateOS / CivOS)


Civilisation OS:
Civilisation OS


How Civilization Works:
Civilisation: How Civilisation Actually Works


CivOS Runtime Control Tower:
CivOS Runtime / Control Tower (Compiled Master Spec)


Mathematics Learning System:
The eduKate Mathematics Learning System™


English Learning System:
Learning English System: FENCE™ by eduKateSG


Vocabulary Learning System:
eduKate Vocabulary Learning System


Additional Mathematics 101:
Additional Mathematics 101 (Everything You Need to Know)


Human Regenerative Lattice:
eRCP | Human Regenerative Lattice (HRL)


Civilisation Lattice:
The Operator Physics Keystone


Family OS:
Family OS (Level 0 root node)


Bukit Timah OS:
Bukit Timah OS


Punggol OS:
Punggol OS


Singapore City OS:
Singapore City OS


MathOS Runtime Control Tower:
MathOS Runtime Control Tower v0.1 (Install • Sensors • Fences • Recovery • Directories)


MathOS Failure Atlas:
MathOS Failure Atlas v0.1 (30 Collapse Patterns + Sensors + Truncate/Stitch/Retest)


MathOS Recovery Corridors:
MathOS Recovery Corridors Directory (P0→P3) — Entry Conditions, Steps, Retests, Exit Gates


SHORT_PUBLIC_FOOTER:
This article is part of the wider eduKateSG Learning System.
At eduKateSG, learning is treated as a connected runtime:
understanding -> diagnosis -> correction -> repair -> optimisation -> transfer -> long-term growth.

Start here:
Education OS
Education OS | How Education Works — The Regenerative Machine Behind Learning


Tuition OS
Tuition OS (eduKateOS / CivOS)


Civilisation OS
Civilisation OS


CivOS Runtime Control Tower
CivOS Runtime / Control Tower (Compiled Master Spec)


Mathematics Learning System
The eduKate Mathematics Learning System™


English Learning System
Learning English System: FENCE™ by eduKateSG


Vocabulary Learning System
eduKate Vocabulary Learning System


Family OS
Family OS (Level 0 root node)


Singapore City OS
Singapore City OS


CLOSING_LINE:
A strong article does not end at explanation.
A strong article helps the reader enter the next correct corridor.

TAGS:
eduKateSG
Learning System
Control Tower
Runtime
Education OS
Tuition OS
Civilisation OS
Mathematics
English
Vocabulary
Family OS
Singapore City OS