# The Routing Object — WaterStorage v2 (load-bearing proposal)

Source: Discord feedback, 2026-06-29, the architectural addition.

## The proposal

Every artifact carries a tiny routing object as its identity:

```json
{
  "origin": "local",
  "phase": "lake",
  "temperature": 0.42,
  "confidence": 0.91,
  "lineage": [
    "stream://thought/182"
  ],
  "last_precipitation": "2026-06-29T15:42Z",
  "next_phase": "cloud"
}
```

## Why this is the load-bearing proposal

The author's insight:

> Notice there's no mention of storage providers. The object only knows its hydrologic state. That means the underlying implementation can evolve — from local files to databases to object stores — without changing the conceptual model.

This is **phase-identity over address-identity**. The same insight that makes the WaterStorage framework itself work — storage is a state, not a place — applied at the single-artifact level.

## Fields

| Field | Type | Meaning |
|---|---|---|
| `origin` | string | Where the artifact first condensed (local, cloud, watershed) |
| `phase` | string | Current phase state (ocean, vapor, cloud, rain, soil, streamlines, creek, lake, groundwater, return, ocean) |
| `temperature` | float 0-1 | Activity / energy level. Hot = actively evaporating/being read. Cold = dormant. |
| `confidence` | float 0-1 | How established / reliable the artifact is (related to sediment) |
| `lineage` | array | WaterIDs of parents (where this evaporated from / merged with) |
| `last_precipitation` | ISO timestamp | When the artifact last changed phase or was accessed |
| `next_phase` | string | Predicted / planned next phase |

## What this enables

1. **Universal merge**: Two artifacts merge by phase + lineage, not by URL. Critical for watershed imports.
2. **Climate queries**: "Show me all hot artifacts" → `temperature > 0.7`. "Show me everything about to rain" → `next_phase = "stream"`.
3. **Conservation by lineage**: An artifact is conserved if its lineage is conserved, regardless of physical substrate.
4. **Cross-substrate migration**: Move an artifact from local files to a database; the routing object travels intact. Identity is preserved.

## The relationship to WaterID (proposal #5)

If we adopt both:

- **WaterID** = the artifact's identity (which water is it?)
- **Routing Object** = the artifact's state (what is it doing right now?)

Together they form a complete hydrological identity. The WaterID is permanent (or near-permanent); the routing object is dynamic.

## The cost

Every artifact now has overhead. For tiny notes, this can be larger than the note itself. We need a compact serialization.

Compact form proposal:
```
origin=local; phase=lake; temp=0.42; conf=0.91; line=thought/182; lp=2026-06-29T15:42Z; next=cloud
```

27 fields of overhead per artifact vs 200+ in JSON. Still big for a one-line note, but tractable.

## Recommendation

Adopt as the v2 artifact identity standard. Test on the existing triad artifacts first (rewrite the 4 files with routing objects) before expanding.

---

*Load-bearing proposal. See `README.md` for context.*