What Is the CitySim.150Y.CF Variable Registry?

A 150-year city simulation is only as honest as its variables.

If the variables are vague, the whole simulation becomes vague. If the variables are hidden, the model can be accused of cheating. If the variables drift in meaning from one city to another, then the engine is no longer one engine. It is just a different story each time.

That is why the CitySim.150Y.CF Variable Registry comes first.

One-sentence answer

The CitySim.150Y.CF Variable Registry is the canonical ledger of every variable the simulation is allowed to use, including what each variable means, how it is measured, what range it can take, how often it updates, what counts as failure, and how it connects to the rest of the city engine.

That is the minimum needed before any 150-year city run can be taken seriously.

Why this page has to exist

Tokyo taught an important lesson.

The problem was not that long-horizon city simulation is impossible. The problem was that a city model becomes too loose when it uses variables that are only partially defined, partially observed, or silently changed in meaning during the run.

That creates three immediate problems:

1. the model becomes hard to audit
2. backtesting becomes weak
3. different cities stop being comparable

So before another city is run, the engine needs a proper registry.

This page is that registry.

What the Variable Registry does

The Variable Registry does five things.

1. It defines the language of the engine

Before a city can be simulated, the engine must know what it is talking about.

For example:

• what is “youth inflow”?
• what is “base stock”?
• what is “school capture”?
• what is “legitimacy”?
• what is “late-life use”?

If these terms are not precisely defined, the model is just moving words around.

2. It separates observed reality from model structure

A strong simulation must distinguish between:

• observed variables
  things measured in the world through datasets
• derived variables
  things calculated from observed data
• latent variables
  real but not directly measurable states that must be approximated through proxies
• policy variables
  variables that can be changed through intervention
• shock variables
  external pressures that hit the city

This separation matters because the model should never pretend a guessed number is the same thing as a measured one.

3. It keeps the engine consistent across cities

Tokyo, Singapore, London, Seoul, or Osaka may differ, but the engine should still know what counts as:

• a demographic pressure
• a capability transfer pressure
• an infrastructure stress
• a legitimacy decline
• a repair corridor

The city changes.
The machine grammar should not.

4. It allows backtesting

A model cannot be backtested unless the variables are stable enough to compare across time.

That means each variable needs:

• a meaning
• a unit
• a time step
• a historical proxy
• a threshold rule

Without that, the model may still be interesting, but it is not calibratable.

5. It tells future readers where the simulation stops being data and starts being interpretation

That is a very important boundary.

Every serious simulation needs to say clearly:

• this part is observed
• this part is derived
• this part is estimated
• this part is an assumption
• this part is a scenario rule

If that boundary is blurred, trust breaks.

What every variable entry must contain

Every variable in CitySim.150Y.CF must have a full entry with the following fields.

Required fields

That is the minimum.

If a variable does not have these fields, it is not yet ready for use in a public 150-year run.

The five classes of variables

1. Observed variables

These are directly measured or close to directly measured.

Examples:

• total population
• births
• deaths
• net migration
• life expectancy
• school non-attendance rate
• unemployment rate
• infrastructure stock
• housing vacancy

These are the strongest foundation variables.

2. Derived variables

These are calculated from observed values.

Examples:

• dependency ratio
• youth inflow index
• teacher replacement pressure
• housing affordability stress
• credential detachment gap

These are still useful, but must remain traceable back to their inputs.

3. Latent variables

These are real, but not directly observable in one clean dataset.

Examples:

• legitimacy
• transfer integrity
• late-life civic usefulness
• social recoverability
• institutional coherence

Latent variables are allowed, but only if they are tied to declared proxy maps.

4. Policy variables

These are the variables a city can intentionally influence.

Examples:

• teacher training intensity
• retraining corridor capacity
• support for school non-attenders
• senior re-entry programme density
• standards calibration strength

These matter because CitySim is not only a diagnostic engine. It is also meant to test intervention corridors.

5. Shock variables

These are external or disruptive inputs.

Examples:

• fertility shock
• energy price shock
• migration shock
• war or trade shock
• infrastructure failure shock
• pandemic shock
• political legitimacy shock

A 150-year city model without shocks is too smooth to be credible.

Canonical variable domains for CitySim.150Y.CF

The variable registry must cover the whole city machine, not only education.

Domain 1. Demography

This is the population base and replacement engine.

Core variables:

• total population
• birth rate
• fertility rate
• death rate
• age distribution
• household formation
• dependency ratio
• migration inflow
• migration outflow
• elderly living alone

Domain 2. Education and transfer

This is the capability formation engine.

Core variables:

• school capture
• non-attendance
• dropout
• credential attainment
• transfer integrity
• teacher pipeline health
• parent capability support
• mid-life retool participation
• late-life learning participation

Domain 3. Economy and work

This is the productive use layer.

Core variables:

• labour participation
• youth employment transition
• career-curriculum alignment
• productivity
• sector mix
• retraining absorption
• wage distribution
• job obsolescence rate

Domain 4. Infrastructure and urban form

This is the physical city body.

Core variables:

• infrastructure stock quality
• maintenance burden
• housing affordability
• transit reach
• congestion stress
• utility reliability
• district unevenness

Domain 5. Health and longevity

This is the survivability and load-bearing layer.

Core variables:

• life expectancy
• healthy life expectancy
• chronic load burden
• disability-adjusted participation
• care dependency
• senior isolation

Domain 6. Governance and legitimacy

This is the rule, trust, coordination, and repair layer.

Core variables:

• public trust proxy
• institutional legitimacy
• policy continuity
• response speed
• repair rate
• archive continuity
• standards integrity

Domain 7. Social continuity and civic order

This is the wider civilisational binding layer.

Core variables:

• intergenerational transfer integrity
• civic participation
• family support strength
• social recoverability
• fairness / access gap
• cultural memory continuity

Domain 8. External pressure and shocks

This is the outside world hitting the city.

Core variables:

• trade exposure stress
• energy stress
• geopolitical shock load
• climate pressure
• water pressure
• migration shock
• financial shock

Minimum starter registry for v1 hardening

Before any new city is simulated, CitySim needs at least the following minimum variables locked.

A. Base and demography

B. Education and transfer

C. Economy and career continuity

D. Infrastructure and city body

E. Governance and repair

F. External stress

That is not the final registry.
It is the minimum viable registry that makes the engine harder to fake.

How variables should be named

The naming system should stay stable.

Rule 1: one canonical machine name

Use one permanent ID:

• POP_TOTAL
• SCHOOL_CAPTURE
• LEGITIMACY

Do not rename variables casually once published.

Rule 2: one public name

The public name can be more readable, but it should still map cleanly back to the machine ID.

Rule 3: no overloaded meanings

If “capture” means school corridor retention in one article, it should not suddenly mean emotional engagement in another.

Rule 4: one scale per variable

Do not let one city use 0–1 and another use 0–100 unless explicitly converted through the data adapter.

Consistency matters more than clever naming.

Variable quality grades

Not all variables are equally strong.

That should be stated openly.

Grade A — strong observed variable

Good official time-series data exists.

Grade B — observed but imperfect

Some data exists, but there are breaks in time, comparability, or granularity.

Grade C — derived variable

The value depends on multiple observed inputs and one declared transformation rule.

Grade D — latent variable with declared proxies

The variable is useful, but inference quality is weaker and must be treated carefully.

Grade E — experimental

The variable is still conceptually important, but proxy quality is weak and should not dominate verdicts.

A serious city run should publish the grade of each variable it uses.

What counts as failure in the Variable Registry

The registry fails when:

• variables are undefined
• the same variable changes meaning across runs
• hidden variables are introduced mid-analysis
• a latent variable is treated as if it were directly observed
• the ranges are arbitrary and never justified
• thresholds are added only after the result is known
• one city is scored with a different grammar from another

That is how a city simulation turns into a storytelling device instead of an engine.

What this page does not do

This page does not yet define:

• the real-world proxy dataset for each variable
• the exact conversion rules from raw data into index values
• the transition equations
• the calibration method
• the backtest thresholds

Those need their own pages.

This page only locks the registry grammar.

That comes first.

Why this matters for the whole CitySim build

If CitySim is going to become a real civilisation-grade city engine, then it needs the same discipline a serious engineering system would need.

Before flight:

• define the instruments
• define the units
• define the thresholds
• define what the readings mean

A city is more complex than an aircraft, but the principle is the same.

If the gauges are not defined, the control tower is theatre.

If the gauges are defined properly, the model may still be wrong, but at least it can be corrected honestly.

That is where CitySim needs to go next.

Final definition

The CitySim.150Y.CF Variable Registry is the canonical control ledger that defines every variable the city engine is allowed to use, how that variable is interpreted, how it is bounded, how it updates, how it fails, and how it connects measured reality to long-horizon city simulation.

Without it, there is no serious 150-year city engine.

Almost-Code

CITYSIM_150Y_CF_VARIABLE_REGISTRY_V1
PURPOSE:
Create one canonical variable grammar for all CitySim.150Y.CF runs.
CORE_LAW:
No city may be simulated using undeclared variables.
VARIABLE_ENTRY_SCHEMA:
{
  variable_id,
  public_name,
  domain,
  definition,
  variable_type,
  unit,
  range_min,
  range_max,
  time_step,
  update_rule,
  data_source_type,
  proxy_map,
  quality_grade,
  lag_type,
  failure_threshold,
  repair_threshold,
  owner_module,
  notes
}
VARIABLE_TYPES:
- observed
- derived
- latent
- policy
- shock
DOMAIN_SET:
- demography
- education_transfer
- economy_work
- infrastructure_urban_form
- health_longevity
- governance_legitimacy
- social_continuity
- external_stress
MINIMUM_VARIABLE_SET:
POP_TOTAL
POP_YOUTH_SHARE
POP_65_PLUS_SHARE
TFR
NET_MIGRATION
ELDERLY_ALONE
DEPENDENCY_RATIO
SCHOOL_CAPTURE
NON_ATTEND_RATE
DROP_OUT_RATE
TRANSFER_INTEGRITY
TEACHER_PIPELINE_HEALTH
PARENT_CAPABILITY_SUPPORT
MIDLIFE_RETOOL
LATE_LIFE_LEARNING_USE
LABOUR_PARTICIPATION
CAREER_ALIGNMENT
PRODUCTIVITY_PROXY
JOB_OBSOLESCENCE_PRESSURE
BASE_STOCK
MAINTENANCE_LOAD
HOUSING_STRESS
TRANSIT_REACH
UTILITY_RELIABILITY
LEGITIMACY
REPAIR_RATE
DRIFT_RATE
STANDARDS_INTEGRITY
ARCHIVE_CONTINUITY
ENERGY_STRESS
GEOPOLITICAL_STRESS
CLIMATE_PRESSURE
HEALTH_SHOCK_LOAD
QUALITY_GRADES:
A = strong observed
B = observed but imperfect
C = derived
D = latent with declared proxies
E = experimental
FAIL_CONDITIONS:
- variable undefined
- variable meaning shifts across runs
- hidden variable used
- latent variable treated as directly observed
- arbitrary scale without declared conversion
- threshold added after result is known
- different cities scored with different grammar
PASS_CONDITION:
A CitySim run is registry-valid only if all active variables are declared,
typed,
bounded,
thresholded,
and mapped to a source or proxy.
OUTPUT:
registry_validity = TRUE or FALSE

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

• Education OS | How Education Works
• Tuition OS | eduKateOS & CivOS
• Civilisation OS
• How Civilization Works
• CivOS Runtime Control Tower

Learning Systems

• The eduKate Mathematics Learning System
• Learning English System | FENCE by eduKateSG
• eduKate Vocabulary Learning System
• Additional Mathematics 101

Runtime and Deep Structure

• Human Regenerative Lattice | 3D Geometry of Civilisation
• Civilisation Lattice
• Advantages of Using CivOS | Start Here Stack Z0-Z3 for Humans & AI

Real-World Connectors

• Family OS | Level 0 Root Node
• Bukit Timah OS
• Punggol OS
• Singapore City OS

Subject Runtime Lane

• Math Worksheets
• How Mathematics Works PDF
• MathOS Runtime Control Tower v0.1
• MathOS Failure Atlas v0.1
• MathOS Recovery Corridors P0 to P3

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.

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