Define persistent cell identity and lifecycle contract #4

New issue

Open

opened 2026-08-12 20:41:13 +02:00 by michael · 0 comments

michael commented

2026-08-12 20:41:13 +02:00

Owner

Goal

Define a dedicated DAW contract for persistent cell identity and cell lifecycle semantics.

The contract must define what makes a concrete DAW cell the same cell over time, so cell_id can be used consistently by runtime contracts such as daw_error/v1, daw_event/v1, and daw_event_response/v1.

Session rationale

During the daw_i18n/v1 and runtime-contract review, source was clarified to mean the stable cell name/type, while optional cell_id identifies the concrete producing/responding cell.

The runtime contracts deliberately do not define how a cell_id is created, persisted, restored, retired, or replaced. That lifecycle must be defined separately before cell_id can safely become mandatory.

The intended semantic direction from the session is that a concrete cell keeps the same cell_id for its lifetime; reload, restart, or reactivation must not silently turn the same cell into a new identity. A temporary process, operation, invocation, event, or error identifier must not be reused as cell_id.

Scope

Define the minimal contract needed for durable DAW cell identity, including:

when a cell receives its identity;
what makes two runtime appearances the same cell;
stability of cell_id across reload, restart, and reactivation;
persistence and restoration semantics without prescribing an implementation language;
retirement/replacement semantics;
clone/fork semantics where a new cell identity is required;
relationship between cell_id and other identifiers such as source, process identity, operation_id, event IDs, and error IDs;
compatibility with the optional cell_id fields already carried by daw_error/v1, daw_event/v1, and daw_event_response/v1.

Do not fold error, event, i18n, storage implementation, or host-specific persistence policy into this contract beyond what is necessary to define cell identity semantics.

Acceptance criteria

A draft cell identity/lifecycle contract exists in DAW/daw-contracts.
The contract defines the lifetime and stability semantics of cell_id.
Reload/restart/reactivation behavior is explicitly defined.
Retirement/replacement and clone/fork identity behavior are explicitly defined.
cell_id is clearly distinguished from source, process IDs, operation IDs, event IDs, and error IDs.
The contract does not prescribe a programming language or concrete persistence backend.
The relationship to daw_error/v1, daw_event/v1, and daw_event_response/v1 is documented.
The existing runtime contracts can later decide whether cell_id becomes mandatory based on this contract rather than inventing local lifecycle rules.

## Goal Define a dedicated DAW contract for persistent cell identity and cell lifecycle semantics. The contract must define what makes a concrete DAW cell the same cell over time, so `cell_id` can be used consistently by runtime contracts such as `daw_error/v1`, `daw_event/v1`, and `daw_event_response/v1`. ## Session rationale During the `daw_i18n/v1` and runtime-contract review, `source` was clarified to mean the stable cell name/type, while optional `cell_id` identifies the concrete producing/responding cell. The runtime contracts deliberately do not define how a `cell_id` is created, persisted, restored, retired, or replaced. That lifecycle must be defined separately before `cell_id` can safely become mandatory. The intended semantic direction from the session is that a concrete cell keeps the same `cell_id` for its lifetime; reload, restart, or reactivation must not silently turn the same cell into a new identity. A temporary process, operation, invocation, event, or error identifier must not be reused as `cell_id`. ## Scope Define the minimal contract needed for durable DAW cell identity, including: - when a cell receives its identity; - what makes two runtime appearances the same cell; - stability of `cell_id` across reload, restart, and reactivation; - persistence and restoration semantics without prescribing an implementation language; - retirement/replacement semantics; - clone/fork semantics where a new cell identity is required; - relationship between `cell_id` and other identifiers such as `source`, process identity, `operation_id`, event IDs, and error IDs; - compatibility with the optional `cell_id` fields already carried by `daw_error/v1`, `daw_event/v1`, and `daw_event_response/v1`. Do not fold error, event, i18n, storage implementation, or host-specific persistence policy into this contract beyond what is necessary to define cell identity semantics. ## Acceptance criteria - [ ] A draft cell identity/lifecycle contract exists in `DAW/daw-contracts`. - [ ] The contract defines the lifetime and stability semantics of `cell_id`. - [ ] Reload/restart/reactivation behavior is explicitly defined. - [ ] Retirement/replacement and clone/fork identity behavior are explicitly defined. - [ ] `cell_id` is clearly distinguished from `source`, process IDs, operation IDs, event IDs, and error IDs. - [ ] The contract does not prescribe a programming language or concrete persistence backend. - [ ] The relationship to `daw_error/v1`, `daw_event/v1`, and `daw_event_response/v1` is documented. - [ ] The existing runtime contracts can later decide whether `cell_id` becomes mandatory based on this contract rather than inventing local lifecycle rules.

michael added the

coordination/cross-repo

labels