Series lifecycle

Three axes, never mixed

A series returned by the API carries three blocks that answer three different questions, and they must not be confused.

A very well-established series may have stopped collecting; a series that is still emerging may be perfectly alive. The first axis is covered in Recurring series, the third in Split, merge, supersession. This page is about the second.

The five states

Within the lifecycle block, only state, policy_version and calibration are required. state takes one of the following values, and each has a precise meaning.

late and inactive both require that the account was observed: they are never inferred from silence alone. ended is not inferred from silence either, however long: a payment that stops may be a cancellation, a suspension, an expired card or a failed collection, and the API does not guess which. When ended is returned, evidence carries the terminal proof that produced it.

An absence proves nothing without coverage

The lifecycle rests on a simple distinction: "I saw nothing" is not "nothing happened". If your integration stops sending the operations of an account, every subscription on that account will appear to stop. For a missing occurrence to mean anything, Noryo must know that the account was observed, and observed completely.

That is what observation coverage is for. Through POST /transactions/v1/coverage-windows, you declare that every operation on an account over an interval has been supplied (completeness = complete). partial and unknown do not qualify: ten operations in October may be ten out of a hundred. The declaration is recorded as stated, with provenance = caller_asserted: Noryo does not verify a bank's completeness.

The lifecycle block reports what it could verify in observation_coverage:

Until coverage is complete, no missing-occurrence state (late, inactive) is concluded. The consecutive_misses counter only advances under complete coverage; it is absent when nothing is expected, which is not the same ignorance as "we were not looking".

A window, not a date

When an occurrence is expected, expected_next_window gives the interval: from, to, and tolerance_days, the half-width in days. A salary lands around the last working days, a SEPA direct debit around the 5th: an exact instant would be a precision Noryo does not have. The width comes from the anchor type, returned in anchor; widened_to_family_floor indicates whether the tolerance was raised to the floor of the series family.

Two fields are duplicated here so the lifecycle can be read on its own: cadence_strength is the same number as cadence_detail.strength (class calendar_fill), and calendar_anchor the same object as calendar_pattern (class anchor_stability). They are not additional scores, and neither is a probability: see Score semantics. calendar_anchor is { "type": "unknown" } when no anchor was inferred, and it is absent when no occurrence is expected. last_observed_on gives the last day an occurrence was seen.

When the identity has been corrected

After an identity correction (split or merge in superseded_by.reason), the old series_id remains readable, but its lifecycle no longer belongs to it: the verdict now belongs to its successors. The block then returns state = unknown with identity_status = superseded. This field is present only in that case and never takes the value current. It is not economic ignorance, it is a pointer: the full identity state, with superseded_by and supersedes, is read in identity, and the occurrence's move in membership. The Split, merge, supersession page covers both blocks in detail.

Reading the block

A live monthly series, taken from the contract:

{
  "state": "active",
  "reason": "la prochaine echeance n'est pas encore echue",
  "last_observed_on": "2026-09-05",
  "expected_next_window": {
    "from": "2026-10-03",
    "to": "2026-10-07",
    "tolerance_days": 5,
    "anchor": "fixed_day_of_month",
    "widened_to_family_floor": true
  },
  "consecutive_misses": 0,
  "observation_coverage": "complete",
  "cadence_strength": 1,
  "calendar_anchor": {
    "type": "fixed_day_of_month",
    "nominal_day": 5,
    "weekday": null,
    "day_range": [4, 6],
    "weekend_shifts": 0,
    "strength": 0.67,
    "calibration": "non_calibree"
  },
  "policy_version": "cyc_v2",
  "calibration": "non_calibree"
}

The same series after a split, read through its former series_id:

{
  "state": "unknown",
  "reason": "identite corrigee : le cycle de vie appartient desormais aux successeurs",
  "identity_status": "superseded",
  "last_observed_on": "2026-09-05",
  "policy_version": "cyc_v2",
  "calibration": "non_calibree"
}

The full schema:

Acting on each state

A handler dispatches on state without confusing unknown with ended:

const response = await fetch("https://api.noryo.app/transactions/v1/enrichments", {
  method: "POST",
  headers: {
    Authorization: `Bearer ${process.env.NORYO_API_KEY}`,
    "Content-Type": "application/json",
  },
  body: JSON.stringify({
    descriptor: "PRLV SEPA NETFLIX INTERNATIONAL",
    direction: "outgoing",
    occurred_at: "2026-09-05T03:10:00+02:00",
    amount: { value: "13.49", currency: "EUR" },
    account_hint: { iban: "FR7630006000011234567890189" },
  }),
});
const enrichment = await response.json();

for (const series of enrichment.series ?? []) {
  const lifecycle = series.lifecycle ?? {};
  switch (lifecycle.state) {
    case "active":
      break; // nothing to do
    case "late":
    case "inactive":
      break; // the account was observed: the absence is a fact
    case "ended":
      break; // terminal evidence exists: read lifecycle.evidence
    default:
      if (lifecycle.identity_status === "superseded") {
        // follow series.identity.superseded_by
      } else if (lifecycle.observation_coverage === "incomplete") {
        // declare coverage for the account
      } else {
        // read lifecycle.reason
      }
  }
}

Three rules are enough. Never treat unknown as an ending: reason, observation_coverage and identity_status tell you which of the three cases applies. Do not derive your own ended by counting absences: the API does not, for the reasons given above. Finally, compare cadence_strength only between series of the same cadence, and keep policy_version next to any state you store: calibration is always non_calibree.