Typed Memory

Free-text memory is the right primitive for most agent work: notes, decisions, lessons, observations. But when you're building a predictive system — forecasting, decision tracking, calibration audit — you need structure. A typo in a forecast field shouldn't be discovered when the regression model fails six weeks later; it should fail at the store boundary, immediately.

Typed Memory adds four Pydantic v2 schemas on top of the regular memory store. Validated rows go in, validated instances come out. The store stays the same — typed rows ride alongside untyped notes and participate in the same retrieval pipeline.

The four built-in schemas

Schema	Purpose
`calibration`	A subjective probability assigned to a claim, with rationale and observation window
`forecast`	A point prediction with confidence interval, deadline, and resolution criterion
`anchor`	A measured baseline value (anchor low/high range) used to ground forecasts and detect drift
`outcome`	A resolved observation tied to a forecast or calibration, with realized value and error

Each schema extends a TypedMemoryBase with:

model_config = ConfigDict(
    extra="forbid",                  # typo'd fields fail at the boundary
    str_strip_whitespace=True,
    validate_default=True,
)
schema_version: int = Field(default=SCHEMA_VERSION, frozen=True)

extra="forbid" is the key choice: any field name not in the schema raises a validation error on store. That moves discovery of typos from "regression model fails downstream" to "the call that tried to store it failed immediately."

The three MCP tools

Tool	Purpose
`omega_typed_store`	Store a typed memory. The `payload` must conform to the Pydantic schema for the chosen `schema`.
`omega_typed_query`	Query typed memories of a given schema. Returns validated instances serialized as JSON. Rows that fail re-validation are silently skipped with a logged warning.
`omega_typed_schemas`	Return the JSON-schema for every registered model. Field names, types, constraints, defaults. Useful for discovery before storing.

A typical session

# 1. Discover what schemas are available
omega_typed_schemas()
→ calibration, forecast, anchor, outcome (with full JSON-schema for each)

# 2. Store a forecast
omega_typed_store(
    schema="forecast",
    payload={
        "claim": "Q3 retention will hit 78%",
        "point_estimate": 0.78,
        "confidence_interval": [0.74, 0.82],
        "deadline": "2026-09-30",
        "resolution_criterion": "internal cohort dashboard",
    },
    entity_id="growth",
)
→ stored memnode_e9c9…

# 3. Query forecasts since a date — get validated instances back
omega_typed_query(schema="forecast", since="2026-04-01", entity_id="growth")
→ [{claim: "...", point_estimate: 0.78, confidence_interval: [0.74, 0.82], ...}, ...]

Why the design choices

skip_inference=True on store — embedding-similarity dedup would collapse five forecasts with similar shape into one row. That's wrong for typed memories: you want every Forecast row preserved, even ones that share most of their text. Content-hash and canonical-hash dedup still fire (correct semantics).
json_extract on typed_schema discriminator instead of LIKE substring matching — SQLite's JSON1 (built-in since 3.38) does this efficiently and correctly.
Silently skip failed re-validation in query — one corrupt row from an older schema version shouldn't take down the query. The skipped row is logged so you can find and migrate it.

Use cases

Calibration audit: log every probability you assign, resolve with outcomes, run Brier scoring over the result set.
Forecast registry: track which predictions you made when, with what confidence, against what resolution criterion.
Anchor evolution: log the baseline measurements that ground forecasts; detect drift over time.
Outcome mining: join forecasts to their realized outcomes for post-mortem analysis.

The first consumer is Meridian (Sosa Research's predictive product line) — calibration rationale, anchor evolution, and forecast-vs-actual mining all ride on these primitives without each needing its own schema layer.