Home How it works Belief Merging
Memory lifecycle

AI memory should improve over time.

Not pile up forever.

Tenure treats memory as governed state. Repeated beliefs are reinforced, aliases are added, stale versions are superseded, and uncertain merges are left alone.

No blind append

Duplicates become evidence.

When a new belief matches an existing one, Tenure reinforces the existing belief instead of creating a second copy.

No silent overwrite

Changes become lineage.

When a belief changes, older versions are superseded so the system can preserve what changed and why.

No forced certainty

Unclear merges stay separate.

Tenure is conservative by default. If two beliefs might be different, they remain distinct until stronger evidence appears.

The merge path

Every extracted belief enters a lifecycle.

A new belief is not simply dumped into memory. Tenure checks for canonical and alias matches, fuzzy merge candidates, file context, confidence, and explicit update signals before deciding what to do.

01

Find candidates

Tenure looks for existing beliefs by canonical name, aliases, and scoped merge candidates.

02

Compare context

File-specific beliefs stay separate when the same name means different things in different files.

03

Choose action

Insert, reinforce, add aliases, supersede, flag conflict, or skip low-confidence input.

04

Keep lineage

Changes are recorded with session, turn, model, confidence, and prior belief state.

State transitions

Beliefs are reinforced before they are trusted.

Tenure separates weak signals from durable memory. Inferred beliefs need both repeated evidence and time before they can become active, which keeps one long session from accidentally promoting a fragile assumption.

Belief lifecycle
inferred Use Zod for validation in API boundaries. confidence 0.62 · 1 signal
reinforced Use Zod for request and response validation. 5 signals · aliases added
active Use Zod for validation at service boundaries unless a generated schema already exists. promoted after time + evidence
superseded Use Joi for API validation. kept for lineage
What gets merged

The same underlying belief.

Tenure merges beliefs when they express the same fact, preference, decision, entity, or expertise signal with enough confidence.

  • Aliases are carried forward for search continuity.
  • Canonical names are normalized instead of duplicated.
  • Nuance from each source belief is preserved in the merged content.
  • Retired source beliefs point to the new merged belief.
What stays separate

Similar text with different meaning.

Tenure avoids aggressive compaction because false merges are worse than extra memory objects.

  • Beliefs tied to distinct active files can remain separate.
  • Low-confidence beliefs can be skipped instead of inserted.
  • Conflicting content can be flagged for review.
  • Uncertain duplicates are left untouched.

Tenure’s merge rule is intentionally boring: preserve evidence, promote slowly, and never compress uncertainty into false certainty.

Why this matters

The model is the consumer.

Memory is only useful when the model receives the right belief at the right time. Merging is not just cleanup. It controls what future sessions are allowed to assume.

// before compaction
{ canonical_name: "zod_validation", content: "Use Zod for validation." }
{ canonical_name: "api_schema_validation", content: "Use Zod at API boundaries." }

// after conservative merge
{ canonical_name: "zod_api_boundary_validation", content: "Use Zod for validation at API boundaries.", aliases: ["zod_validation", "api_schema_validation"] }
The point

Memory should become clearer as it grows.

Tenure gives teams a memory layer that can accumulate evidence without losing control of provenance, confidence, scope, or lineage.