# Memory Maturity Benchmarks — Operational Counterpart to spec-memory-maturity

**Status:** Active draft (2026-04-27)
**Owner:** Ben Booth
**Layer:** Axiom core — operational telemetry & release gates
**Related:**
- `docs/specs/spec-memory-maturity.md` — the spec this doc operationalizes
- `docs/working/memory-benchmarks.md` — sibling benchmark doc (compliance + perf surface for the layered memory itself)
- `docs/working/memory-benchmarks-trend.md` — sibling trend-tracking doc
- `docs/working/plan-agent-modes-analysis.md` §7.8 — origin of the unified-maturity bet
- `docs/adrs/adr-033-layered-memory-architecture.md`, `docs/adrs/adr-034-plan-and-agent-pipeline.md`, `docs/adrs/adr-035-human-principal-binding.md`

---

## 1. Why this doc exists

`spec-memory-maturity.md` makes a confident-sounding claim: memory aggression scales because tiered retention, TIDY sweep, cohort archival, classification expiry, forgetting, and concept-graph pruning hold the line. That claim is unfalsifiable as written. This doc turns each mechanism into one or more **measurable signals** with thresholds, sources, and failure conditions — so a reviewer in 2031 (or a release reviewer next month) can verify the claim, not believe it.

Five categories of proof (§2 mechanical, §3 operational, §4 outcome, §5 longitudinal, §6 falsification). Each has concrete metrics. Sections §7–§10 specify the harness, telemetry schema, publication cadence, and what we'll admit if any of it breaks.

The discipline: **if any metric below crosses a stated threshold, we say so in the trend doc, in release notes, and to any cohort coordinator depending on the affected behavior.**

---

## 2. Mechanical compliance — pass / fail at every release

The `pytest -m maturity_compliance` marker (introduced in spec-memory-maturity §13) gates every release. Six binary tests; one failure blocks merge. Each row: what it asserts, the exact failure signal, the diagnostic command.

| ID | Test | Asserts | Fails if | Diagnostic |
|---|---|---|---|---|
| **MM1** | Retention round-trip | A fragment written today decodes from each tier (hot → warm → cold) without provenance loss. | `(T, U, A, R)` tuple bytes differ across tier transitions; or `tombstone:reason=...` overwrites provenance fields. | `axi memory sweep --dry-run --explain --fragment <id>`; compare hot vs cold projection bytes. |
| **MM2** | TIDY sweep idempotency | Running the sweep twice on identical state produces identical state (same set of L0 events emitted, same fragment statuses). | A second sweep emits *any* `ClassificationExpired` / `PromotionApproved` / `ColdTombstone` events when the first run already converged. | `axi memory sweep && axi memory sweep --diff-since-last`. The diff must be empty. |
| **MM3** | Cohort archive replay | A pinned cohort-archive fixture (Prague-2026 schema_version) decodes + projects under current Axiom. | Fragment count drift, signature verification failure, or projection emits fewer than the fixture's recorded baseline output. | `pytest tests/memory/test_cohort_archive_replay.py -k prague_2026`. |
| **MM4** | Classification expiry | A fragment stamped with `expires_at` past today gets its classification stamp updated on next sweep without operator intervention. | After a sweep, fragment's classification stamp still equals the pre-expiry regime; or audit log is missing the corresponding `ClassificationExpired` event. | `axi memory sweep --explain` and grep for `ClassificationExpired`. |
| **MM5** | Forgetting compliance | After a `ForgetRequest` from the accountable human, L1+ derivatives of the matched fragments are absent from active projections; original L0 events preserved. | Any post-sweep projection still cites a derivation-stopped fragment; OR original L0 event is missing from the audit log; OR a non-accountable principal succeeded in forgetting. | `axi me forget --dry-run --scope <id>` then inspect `axi memory diff --before-after`. |
| **MM6** | Plan-step-proof L2 fast path | A `PlanStep` with `proof_type ∈ {test, typecheck, replay}` and a satisfied proof artifact promotes its output to L2 without human review; `proof_type ∈ {attestation, null}` blocks on review. | Test/typecheck/replay output stuck at L1 across sweep cycles; OR attestation-proof output auto-promotes to L2 without `PromotionApproved` event citing a human principal. | `pytest -m maturity_compliance -k plan_step_proof -v`. |

These are deterministic. Skipped tests are tracked in the trend doc; an expansion of skip-set requires a justification line in the commit body.

---

## 3. Operational metrics — telemetry from production

Each metric: name, source, computation, day-1 baseline (Prague), one-quarter target, fail-condition. Numbers without a source today land via the §6 telemetry events as Phase 1 ships.

| Metric | Source | Computation | Prague day-1 baseline | One-quarter target | Fail-condition |
|---|---|---|---|---|---|
| **Tier population** (per cohort, per cognitive type) | `memory.sweep.completed` event payload | Count of fragments with status `hot` / `warm` / `cold` / `archive` per `(cohort_id, cognitive_type)`. | hot ≤ 50k, warm ≤ 20k, cold growing | hot stable (within ±20%), warm + cold growing linearly with calendar days | Hot population grows super-linearly with calendar time (curve of best fit > linear) → bounding broken. |
| **Sweep cost** (TIDY sweep duration) | `memory.sweep.completed.duration_ms` | p50, p95 over rolling 30 sweeps per scope. | p50 < 30 s, p95 < 90 s on a Workstation profile with ~50k fragments | p50 < 30 s, p95 < 60 s | p95 > 5 min for two consecutive sweeps → sweep cost not bounded. |
| **Sweep delta size** | `memory.sweep.completed.fragments_transitioned` | Count of fragments transitioning tier per sweep cycle. | < 5% of total population per nightly sweep | < 5% steady-state | Single sweep transitions > 25% of total population (suggests policy churn or threshold drift). |
| **L0 → L1 promotion rate** (per cognitive type, per month) | `memory.promotion.l0_to_l1` event count | Distinct fragment_ids promoted / month / cognitive type. | 5–50 per month per active type | Stable under cohort load | Drops to zero for `episodic` while sweep delta stays > 0 → promotion gate stuck. |
| **L1 → L2 promotion rate** (per cognitive type, per month) | `memory.promotion.l1_to_l2` event count | Distinct fragment_ids promoted / month / cognitive type, partitioned by source (`eve_crystallization`, `plan_step_proof`, `concept_cluster_fact`). | 1–10 per month | 10–50 per month as the cohort matures | Plan-step-proof source = 0 while plan executions > 0 → fast-path broken. |
| **L2 fact precision @ 90d** | Validation harness re-asserts L2 fact against current L0 evidence | Of L2 facts crystallized 90d ago, fraction whose validation predicate still holds. | Not measurable until 90d post-Prague | ≥ 85% | < 70% → promotion gates too loose; tighten thresholds. |
| **L2 fact precision @ 1yr** | Same harness, 1yr lookback | Same metric with 1yr window. | Not measurable until 1yr post-Prague | ≥ 75% | < 60% → fact crystallization fundamentally weak. |
| **ForgetRequest compliance lag** | `memory.forget.requested` ↔ `memory.forget.applied` event pair | p50 / p95 of `applied.timestamp - requested.timestamp` per scope. | p50 ≤ 24h (next-night sweep); p95 ≤ 48h | p50 ≤ 12h; p95 ≤ 36h | p95 > 7d for any scope OR audit shows `requested` with no `applied` → spec-memory §3.6 violated. |
| **Concept-graph activity ratio** | `concept_graph.snapshot` projection | active_concept_count / (active + deprioritized) per scope. | 0.6–0.9 for active cohorts | 0.4–0.7 (more deprioritization is healthy as the graph matures) | Ratio < 0.2 → graph drifted to noise, OR > 0.95 → pruning never fires. |
| **Concept re-promotion rate** | `concept_graph.repromoted` event count | Deprioritized → active touches per month per scope. | 0–5 / month | 5–20 / month | Zero re-promotions over 2 months while query traffic > 0 → re-promotion path broken. |
| **Archive bundle integrity** | `cohort.archive.exported` event with `bundle_sha256` | Re-export the archive bundle; compare sha256. | Stable across re-exports of the same cohort. | Stable. | Sha256 differs across re-exports of identical state → archive serialization non-deterministic. |

Each metric is exposed by `axi memory metrics --scope <id>` (Phase 1; see §9). The default projection emits a JSON line per metric with the day's value.

---

## 4. Outcome metrics — does maturity make agents better?

The category most peer harnesses skip. Compliance + operational metrics tell us *whether* the pipeline runs as designed; outcome metrics tell us whether the pipeline *helps*. Without these, "maturity" is an internal accounting exercise.

| Metric | Setup | Quality measure | Cadence |
|---|---|---|---|
| **A/B with-vs-without L2** | Same eval set; control pipeline retrieves L0 fragments only; treatment pipeline retrieves L0 + L1 patterns + L2 facts. Identical PromptComposer otherwise. See §7. | Rubric-scored answer quality: factual accuracy (0–1), citation correctness (0–1), response length appropriate (0–1). Weighted mean. Rubric judge per §10 open item. | Monthly during Prague; quarterly thereafter. |
| **Regression-eval coverage growth** | Per `spec-rag-knowledge-maturity` §7 closure loop: every L2 fact whose validation fails generates a regression eval. | Count of auto-generated regression evals / month; hit rate (% of regression evals where the targeted fact still validates) on subsequent runs. | Monthly. |
| **Plan-template reuse rate** | Plans that promote to L4 templates per `spec-memory-maturity` §11 are tracked. | (Count of times each L4 template is re-cited as the base of a new plan) / (count of L4 templates). Plus reuse-quality: rubric score of plans derived from a template vs. plans authored fresh. | Quarterly. |
| **Cross-cohort knowledge transfer** | Stage 5b (post-Prague): a concept extracted in cohort A surfaces in cohort B's retrieval (subject to visibility horizon). | Count of cross-cohort cited fragments / month; subjective assessment of relevance via spot review. | Phase 4 metric (post-Stage 5b). Detail intentionally punted; named here so we don't forget. |
| **CHALKE pedagogical correlation** | For a cohort: each weekly assessment cycle, log (a) per-student eval rubric score, (b) the maturity-layer population the coordinator's brief + tutor responses drew from. | Directional correlation (Spearman ρ) between L2+ fragment count cited in tutor responses and student-eval improvement week-over-week. | Quarterly, directional only — not a hypothesis test. |

The first three are committed Phase 1–3 metrics. The fourth and fifth are framed here so they become measurable as soon as their substrate ships.

---

## 5. Longitudinal — the cohort-persistence claim

Cohort persistence is the load-bearing claim from `spec-memory-maturity` §6 + `working/memory-persistence-plan.md`: a cohort archived in 2026 is decodable + projectable by every Axiom release through its declared end-of-life.

### 5.1 Prague cohort archive fixture as release gate

A pinned `cohort-prague-2026-archive.tar.zst` fixture lands in `tests/memory/fixtures/` after the Prague cohort archives (~2026-08). Every subsequent release runs:

1. Decode the bundle.
2. Verify signature against the registered cohort coordinator key.
3. Project the standard surface (`RecentActivityProjection`, `concept_graph.snapshot`, `plan_summaries`).
4. Compare projection output against the recorded baseline (sha256 of canonicalized JSON).

A drift triggers a release block.

### 5.2 Cohort Persistence Index (CPI)

For each live cohort archive in the federation registry: count of consecutive Axiom releases that read it cleanly, starting from archive creation.

```
CPI(cohort_id) = (last_release_that_decoded_cleanly - archive_creation_release) / total_releases_since_creation
```

A CPI of 1.0 means every release since archive creation has decoded the bundle cleanly. CPI < 1.0 means at least one release broke decoding (and either rolled back the change or shipped a migration).

### 5.3 Index update procedure + publication cadence

1. Each release runs the §5.1 decode test against every registered cohort archive.
2. Pass / fail recorded in `docs/working/memory-cohort-persistence-index.md` (created when the first archive lands).
3. Release notes cite the CPI per cohort.
4. Annual public update of the index, published alongside the year's quarterly benchmark publications (§8).

### 5.4 Mermaid — CPI lifecycle

```mermaid
flowchart TD
    classDef create fill:#1a4f3a,color:#e6fff0,stroke:#2f7a5c
    classDef gate fill:#5f3a1a,color:#fff0e6,stroke:#a86f3b
    classDef pub fill:#1f3a5f,color:#e6f0ff,stroke:#3b6fa8
    classDef fail fill:#5f1a1a,color:#ffe6e6,stroke:#a83b3b
    classDef wrap fill:#2a2a2a,color:#f0f0f0,stroke:#5a5a5a

    archive[Cohort archive created<br/>signed bundle + manifest]:::create
    fixture[Fixture pinned in tests/memory/fixtures/]:::create
    every[Every release: decode + project + sha256 compare]:::gate
    pass[Decode clean → CPI ratchets forward]:::gate
    block[Decode fails → release blocked OR migration shipped]:::fail
    notes[Release notes cite per-cohort CPI]:::pub
    annual[Annual CPI publication]:::pub
    summary[Public dashboard: CPI per cohort, per release]:::pub

    archive --> fixture
    fixture --> every
    every --> pass
    every --> block
    pass --> notes
    block --> notes
    notes --> annual
    annual --> summary

    subgraph trend [Lifecycle]
        archive
        fixture
        every
        pass
        block
        notes
        annual
        summary
    end
    class trend wrap
```

---

## 6. Falsification criteria

Five ways the maturity model could be proven ineffective. Each paired with the metric that surfaces the failure and the threshold that triggers a public admission.

| Criterion | Metric that surfaces it | Threshold |
|---|---|---|
| **Memory unbounded growth** | Tier-population trajectory (§3, row 1) | Hot population grows super-linearly with calendar time over a rolling 60-day window. |
| **L2 facts contradict each other** | L2 fact precision @ 90d (§3, row 6) | Drops below 70% → promotion gates are too loose; tighten thresholds. |
| **ForgetRequests don't actually stop derivation** | ForgetRequest compliance lag p95 (§3, row 8) + audit reconciliation | p95 > 7 days OR audit shows any `requested` event without a corresponding `applied` event within 30 days. |
| **Cohort archive un-decodable** | CPI (§5) + maturity_compliance MM3 | Any release fails MM3 → CPI ratchets down → release blocked. |
| **Adding L2+ retrieval hurts answer quality** | A/B with-vs-without L2 (§4, row 1) | Treatment pipeline rubric score < control pipeline rubric score, sustained across two consecutive monthly runs. |

The thresholds are educated guesses, not laws — they are tuned post-Prague (see §10). The discipline is that *they exist before we collect the data*; we don't get to draw the line after seeing the result.

---

## 7. A/B harness design — with-vs-without L2

Brief design for the §4 row-1 A/B harness.

### 7.1 Eval corpus

- **First corpus:** Prague NE-101 question bank (instructor-curated, ~120 questions across the syllabus, scored by a rubric the instructor wrote).
- **Second corpus (post-Prague):** generic agent-eval set drawn from LongMemEval / LoCoMo for cross-cohort calibration.

### 7.2 Two pipelines

| Variant | Retrieval | Composition | LLM |
|---|---|---|---|
| **Control** | L0 fragments only (RecentActivityProjection + RAG retriever) | PromptComposer with `memory_layer=L0` | Same model, same temperature, same seed. |
| **Treatment** | L0 + L1 patterns + L2 facts (full MemoryStack retrieval) | PromptComposer with `memory_layer=L0+L1+L2` | Same model, same temperature, same seed. |

Identical seeds + identical PromptComposer otherwise — the only delta is which maturity layers feed retrieval.

### 7.3 Rubric

Three sub-scores, weighted equally for v0:

- **Factual accuracy** (0–1): does the answer match ground truth?
- **Citation correctness** (0–1): does the answer cite fragments that actually support the claim?
- **Response length appropriate** (0–1): not too terse, not bloated; proxy for "the model knew when to stop."

Weighted mean reported per question; mean over corpus reported as the headline metric.

### 7.4 Schedule

- Monthly during Prague.
- Quarterly thereafter.
- On-demand before any release that touches the L1 / L2 layers.

### 7.5 Mermaid — A/B harness flow

```mermaid
flowchart TD
    classDef corp fill:#1a4f3a,color:#e6fff0,stroke:#2f7a5c
    classDef ctrl fill:#1f3a5f,color:#e6f0ff,stroke:#3b6fa8
    classDef trt fill:#5f3a1a,color:#fff0e6,stroke:#a86f3b
    classDef judge fill:#3a1a5f,color:#f0e6ff,stroke:#6f3ba8
    classDef out fill:#2a2a2a,color:#f0f0f0,stroke:#5a5a5a

    corpus[Eval corpus<br/>NE-101 question bank]:::corp
    control[Control pipeline<br/>L0-only retrieval]:::ctrl
    treatment[Treatment pipeline<br/>L0 + L1 + L2 retrieval]:::trt
    rubric[Rubric judge<br/>see §10 open item]:::judge
    delta[Quality delta<br/>treatment - control]:::out
    record[Record in trend doc<br/>flag if treatment regresses]:::out

    corpus --> control
    corpus --> treatment
    control --> rubric
    treatment --> rubric
    rubric --> delta
    delta --> record
```

---

## 8. Telemetry event schema

The §3 operational metrics depend on TIDY sweep + promotion + forget events emitting structured payloads. All events are themselves L0 fragments per `spec-memory-maturity` §4 (audit trail of every compaction action) and are written through `CompositionService`.

### 8.1 Common envelope

```json
{
  "event_type": "memory.<subdomain>.<action>",
  "timestamp": "2026-04-27T03:14:00Z",
  "scope_id": "scope:cohort:prague-2026",
  "cohort_id": "cohort:prague-2026",
  "accountable_human_id": "@coordinator:prague-2026",
  "schema_version": 1,
  "metrics": { "<metric_name>": "<value>", "..." : "..." }
}
```

`accountable_human_id` is required for any event traceable to a human action (per ADR-035). For autonomous sweep events triggered by the TIDY daemon, the field carries the cohort coordinator's principal — the human accountable for the cohort retention policy.

### 8.2 Defined event types

| `event_type` | Trigger | `metrics` payload (representative) |
|---|---|---|
| `memory.sweep.started` | TIDY begins a sweep cycle | `{ "scope_id", "expected_fragment_count", "policy_profile" }` |
| `memory.sweep.completed` | TIDY finishes a sweep | `{ "duration_ms", "fragments_transitioned", "promotions_count", "tombstones_count", "expiries_applied" }` |
| `memory.promotion.l0_to_l1` | A fragment promotes L0 → L1 | `{ "fragment_id", "cognitive_type", "trigger": "frequency|recency|manual" }` |
| `memory.promotion.l1_to_l2` | L1 → L2 promotion | `{ "fragment_id", "cognitive_type", "source": "eve_crystallization\|plan_step_proof\|concept_cluster_fact", "proof_artifact_ref": "..." }` |
| `memory.forget.requested` | Human invokes `axi me forget` | `{ "request_id", "fragment_query", "requesting_principal" }` |
| `memory.forget.applied` | Sweep cycle applies a previously-requested forget | `{ "request_id", "fragments_marked": <count>, "lag_seconds" }` |
| `memory.classification.expired` | Fragment classification expires on sweep | `{ "fragment_id", "old_classification", "new_classification", "rule_cited" }` |
| `memory.concept.deprioritized` | Concept drops to deprioritized tier | `{ "concept_id", "last_evidence_at" }` |
| `memory.concept.repromoted` | Concept re-promotes via touch | `{ "concept_id", "repromotion_trigger_fragment_id" }` |
| `cohort.archive.exported` | Cohort archive bundle written | `{ "cohort_id", "bundle_sha256", "fragment_count_by_layer", "signed_by": [<principal_ids>] }` |

### 8.3 Example — sweep completed

```json
{
  "event_type": "memory.sweep.completed",
  "timestamp": "2026-04-27T03:14:42Z",
  "scope_id": "scope:cohort:prague-2026",
  "cohort_id": "cohort:prague-2026",
  "accountable_human_id": "@coordinator:prague-2026",
  "schema_version": 1,
  "metrics": {
    "duration_ms": 22418,
    "fragments_transitioned": 184,
    "promotions_count": 12,
    "tombstones_count": 167,
    "expiries_applied": 5
  }
}
```

### 8.4 Example — forget applied

```json
{
  "event_type": "memory.forget.applied",
  "timestamp": "2026-04-27T03:15:01Z",
  "scope_id": "scope:cohort:prague-2026",
  "cohort_id": "cohort:prague-2026",
  "accountable_human_id": "@student:prague-2026:alex",
  "schema_version": 1,
  "metrics": {
    "request_id": "fr_01HXYZ...",
    "fragments_marked": 7,
    "lag_seconds": 21384
  }
}
```

These events are the substrate for `axi memory metrics`; the projection layer aggregates them into the §3 operational rows.

---

## 9. Implementation phasing

Tied to ADR-034 / spec-memory-maturity §14 phasing.

| Phase | What lands here | What this doc captures |
|---|---|---|
| **Phase 0 (now)** | This doc; spec frozen; no code. | Documentation only. |
| **Phase 1 (with PlanPipeline MVP per ADR-034)** | Telemetry events §8 fire from TIDY sweep. `axi memory metrics` projection ships. First three operational metrics live: tier population, sweep cost, sweep delta size. | First values appear in trend doc. |
| **Phase 2 (with AgentPipeline MVP)** | Full operational metric suite (§3). First A/B harness run (§7) on the NE-101 corpus. Maturity-compliance suite §2 wired into CI. | First with-vs-without L2 number recorded. |
| **Phase 3 (Prague summer 2026)** | Live data from Prague cohort. First quarterly publication. CPI begins ticking. | First public publication of operational metrics. |
| **Phase 4 (post-Stage 5b)** | Cross-cohort knowledge transfer metric (§4 row 4). CPI for archived cohorts becomes meaningful. Cohort persistence index dashboard. | Annual CPI publication. |

The forcing function: **no metric in §3 should remain "Phase 1 pending" past 2026-Q3**. If telemetry slips, this doc falls behind, and the maturity claim falls back to confident-sounding language.

---

## 10. Publication cadence + open items

### 10.1 Publication cadence

| Cadence | Output | Audience |
|---|---|---|
| **Daily** | `axi memory metrics --scope <id>` projection (live, per-scope JSON lines + summary table). | Cohort coordinators on-demand; CI as a freshness check. |
| **Weekly** | In-cohort report to coordinators: tier population trend, sweep cost p95, ForgetRequest lag. | Cohort coordinators. |
| **Quarterly** | Public benchmark publication, similar in shape to `memory-benchmarks-trend.md` but for maturity. Includes A/B with-vs-without L2 numbers, regression-eval coverage, plan-template reuse. | Public — readers of the trend docs, peer projects, instructors evaluating the platform. |
| **Annual** | Cohort persistence index update + retention-policy retrospective. | Public + cohort coordinators. |

**Commitment:** if any metric in this doc breaks its threshold, we say so — in the trend doc, in release notes, and to any cohort coordinator depending on the affected behavior. Silence is not an option; the only choices are "metric green" or "metric red with named owner working a fix."

### 10.2 Open items

These do not block this doc — they're flagged as the empirical-tuning surface during Phase 1–3.

- **Rubric judge for A/B answer quality (§7.3).** LLM-as-judge with what model? Same model as the agent-under-test (risk: bias)? A different model (risk: judge drift)? Human review at what sample rate (10%? 25%?)? Decision deferred to first Prague A/B run, where a small human-vs-LLM-judge calibration exercise will inform the choice.
- **Threshold tuning (§6).** All §6 falsification thresholds are educated guesses; tune empirically post-Prague. Specifically: the 70% L2 fact precision @ 90d threshold is the most likely to be wrong — it could be 60% or 80% depending on cognitive type mix.
- **Regulatory floors override default retention.** Per `spec-memory-maturity` §16: FERPA (7y student records), ITAR (5y from declassification) impose minimums that override profile defaults. These floors must surface in `axi memory metrics` as an explicit "regulated retention floor: N years" line per scope, separate from the default retention policy. Schema TBD.
- **Cohort coordinator reporting access.** Who sees what? Coordinators see their cohort's metrics; what visibility do federated peers have into a cohort's retention discipline? Federation registry should expose a public `retention_policy_published` flag per cohort; metric values stay scope-internal unless the coordinator opts to publish.

### 10.3 Mermaid — publication lifecycle

```mermaid
flowchart TD
    classDef live fill:#1a4f3a,color:#e6fff0,stroke:#2f7a5c
    classDef weekly fill:#5f3a1a,color:#fff0e6,stroke:#a86f3b
    classDef quarter fill:#3a1a5f,color:#f0e6ff,stroke:#6f3ba8
    classDef annual fill:#1f3a5f,color:#e6f0ff,stroke:#3b6fa8
    classDef wrap fill:#2a2a2a,color:#f0f0f0,stroke:#5a5a5a

    metrics[axi memory metrics<br/>per-scope live JSON]:::live
    weekly[Weekly coordinator report]:::weekly
    trend[Quarterly public publication<br/>memory-maturity-trend dated entry]:::quarter
    cpi[Annual CPI update]:::annual

    metrics --> weekly
    weekly --> trend
    trend --> cpi

    subgraph cadence [Cadence]
        metrics
        weekly
        trend
        cpi
    end
    class cadence wrap
```

---

## 11. The bottom line

`spec-memory-maturity.md` makes a claim that scales: aggressive memory writes are safe because tiered retention, TIDY sweep, cohort archival, classification expiry, forgetting, and concept-graph pruning bound the system. This doc converts that claim into six release-gate compliance tests, eleven operational metrics, five outcome metrics, one longitudinal index, five falsification criteria, a telemetry schema, an A/B harness, and a publication cadence.

If any of those break, we say so. That commitment is the difference between a maturity discipline and a maturity slogan.

---

_Copyright (c) 2026 The University of Texas at Austin and B-Tree Labs. Apache-2.0 licensed._
