Smart Cities As Reactive Semantic Trees

This demo shows a simple but powerful idea:

A city can behave like a living semantic system instead of a collection of disconnected databases.

In most software, traffic systems, districts, public services, and security tools are separated into different applications.

In .me, they become one reactive graph.

Districts affect traffic.

Traffic affects routing.

Service schedules react to time.

Security stays private while still participating in logic.

Every change propagates automatically.

View the source demo

The Tiny Mental Model

Think of .me as a city-sized semantic nervous system.

Every path stores one fact:

me.city.name("Veracruz")
me.districts[3].currentLoad(8500)
me.traffic.junctions[3].vehiclesPerMinute(67)

Then the graph derives meaning from those facts:

me.districts["[i]"]["="]("overCapacity", "currentLoad > capacity")

That rule becomes live infrastructure logic.

Whenever the load changes, the city recomputes automatically.

No polling.

No manual synchronization.

No giant update function.

What The Demo Builds

The demo models four major parts of a city:

System	Example	What it represents
Districts	`districts[3]`	Population zones and load management
Traffic	`traffic.junctions[3]`	Reactive traffic control
Services	`services.cityHall`	Public operating schedules
Security	`security`	Private internal operations

All of them exist inside the same semantic tree.

That means the city can reason across systems instead of treating them as isolated databases.

Step 1: Declare The City

The city itself becomes a semantic entity.

me["@"]("veracruz-smart-city")
me.city.name("Veracruz")
me.city.country("Mexico")
me.city.population(700000)
me.city.timezone("America/Mexico_City")

For dummies version:

The graph now knows the city exists.

Everything else belongs to this city tree.

Step 2: Model Districts

Each district stores its own facts:

me.districts[1].name("Centro Histórico")
me.districts[1].capacity(15000)
me.districts[1].currentLoad(14200)

Another district:

me.districts[3].name("Veracruz Puerto")
me.districts[3].capacity(8000)
me.districts[3].currentLoad(8500)

Now teach the graph how to interpret those numbers.

me.districts["[i]"]["="](
  "loadPercent",
  "currentLoad / capacity * 100"
)
me.districts["[i]"]["="](
  "overCapacity",
  "currentLoad > capacity"
)
me.districts["[i]"]["="](
  "needsRedirection",
  "loadPercent > 85"
)

For dummies version:

The graph learns:

how full each district is,
whether it exceeded capacity,
and when traffic should be redirected.

You never manually calculate those fields again.

Querying The City

Now the graph can answer questions directly.

me("districts[overCapacity == true].name")

Result:

{
  "3": "Veracruz Puerto"
}

Or:

me("districts[needsRedirection == true].name")

Result:

{
  "1": "Centro Histórico",
  "3": "Veracruz Puerto"
}

For dummies version:

The city can now identify stressed areas automatically.

Step 3: Reactive Traffic Systems

Traffic intersections are also nodes.

me.traffic.junctions[3].location("Malecón × Arista")
me.traffic.junctions[3].vehiclesPerMinute(67)
me.traffic.junctions[3].greenPhaseSec(45)

Then the graph derives traffic behavior:

me.traffic.junctions["[i]"]["="](
  "saturated",
  "vehiclesPerMinute > 50"
)
me.traffic.junctions["[i]"]["="](
  "recommendedGreenSec",
  "greenPhaseSec + vehiclesPerMinute / 2"
)

For dummies version:

If traffic becomes heavy, the system notices automatically.

The graph also calculates a better green-light duration from live flow.

Reading Live Traffic State

me("traffic.junctions[saturated == true].location")

Result:

{
  "3": "Malecón × Arista"
}

And:

me("traffic.junctions[1..3].recommendedGreenSec")

Result:

{
  "1": 66,
  "2": 39,
  "3": 78.5
}

No scheduler needed.

No cron jobs.

The graph recomputes instantly.

Step 4: Public Services React To Time

Services are also semantic nodes.

me.services.cityHall.opensAt(8)
me.services.cityHall.closesAt(15)
me.services.cityHall.currentHour(14)

Then the graph derives availability:

me.services.cityHall["="](
  "isOpen",
  "currentHour >= opensAt && currentHour < closesAt"
)

For dummies version:

The city hall does not store “open” manually.

The graph figures it out from time.

Time Changes Everything

At 14:00:

me("services.cityHall.isOpen")

Result:

true

Then time advances:

me.services.cityHall.currentHour(16)

Now the graph recomputes automatically:

me("services.cityHall.isOpen")

Result:

false

Nobody manually updates the status.

The dependency graph already knows what changed.

Step 5: Reactive City Events

Now the interesting part.

A port event increases district load:

me.districts[3].currentLoad(9800)

That single mutation automatically affects:

loadPercent
overCapacity
needsRedirection

without touching those fields manually.

me("districts[3].loadPercent")

Result:

122.5

me("districts[3].needsRedirection")

Result:

true

For dummies version:

The city reacts to stress automatically.

You update one fact.

The meaning spreads through the graph.

Step 6: Stealth Nodes — Private Government Operations

Some city systems should not be public.

.me supports structural privacy using stealth nodes.

me.security["_"]("city-security-ops-2026")

Now the node becomes hidden to public observers.

Internal logic still works:

me.security.incidentsToday(3)
me.security["="](
  "alertLevel",
  "incidentsToday > 2"
)

The owner sees:

me("security.alertLevel")

Result:

true

But a public observer sees:

me.as(null)("security.alertLevel")

Result:

undefined

For dummies version:

The city can think with private data without exposing the data publicly.

The graph stays honest.

It does not fake values.

It simply hides what should not be visible.

Step 7: Explainability Without Leaking Secrets

The graph can explain decisions.

me.explain("security.alertLevel")

Result:

{
  "value": true,
  "expression": "incidentsToday > 2",
  "inputs": [
    {
      "label": "incidentsToday",
      "value": "●●●●",
      "origin": "stealth"
    }
  ]
}

For dummies version:

The system explains why the alert happened without revealing the secret incident count.

That is important for real governance systems:

auditable,
explainable,
but privacy-safe.

Step 8: Cross-Node Pointers

Districts can reference other systems directly.

me.districts[3].trafficNode["->"](
  "traffic.junctions[3]"
)

Now the district can resolve live traffic values through the pointer:

me("districts[3].trafficNode.location")

Result:

"Malecón × Arista"

And:

me("districts[3].trafficNode.saturated")

Result:

true

For dummies version:

The district is linked directly to its nearby traffic system.

Not copied.

Not duplicated.

Connected.

Why This Is Different From Traditional Smart City Software

Traditional city systems often look like this:

if (district.load > threshold) {
  notifyTrafficSystem()
}
if (traffic.isSaturated) {
  updateDashboard()
}

That creates:

scattered logic,
duplicated state,
synchronization bugs,
hidden dependencies.

In .me:

districts own district facts,
traffic owns traffic facts,
services own schedules,
security owns private operations,
policies read semantic paths,
and the graph recomputes automatically.

The city becomes a living dependency system.

Build It Yourself

You can rebuild the demo in this order:

Create the city.
Add districts.
Add traffic systems.
Add public services.
Add derived rules.
Trigger a city event.
Add stealth security operations.
Link systems with pointers.
Ask the graph what changed.

Run the real demo:

cd npm
npm install
node tests/Demos/Smart_City.ts

To run all demos:

npm run test:demos:run-all

The Big Idea

A smart city is not just sensors and dashboards.

It is relationships.

.me models those relationships directly:

city facts + reactive derivations + explainable policies + structural privacy
= semantic infrastructure

That is what “Smart Cities As Reactive Semantic Trees” means.